[openstack-dev] [Congress]Authorization mechanisms for each user

Yuki Nisiwaki uckey.1067 at gmail.com
Sat Apr 16 16:38:51 UTC 2016


Hi Masahito, Tim.

Thanks for your messages.

>> btw, I added [Congress] prefix in the subject.
Firstly thanks for your point, I'm beginner openstacker. So this
information is very useful.

Move to main topic.

>So as Masahito mentioned, if you provide more details about your use case
>(in particular what kinds of information you need for making authorization
>decisions),

I supposed that we use OpenStack as Public Cloud which have multiple
tenants.
So The cloud administrator on OpenStack who have the admin role in OpenStack
and The deployer who is in charge of creating OpenStack environment and
providing service are not same.
So we desire some mechanism to enable the admin on OpenStack in tenant (or
domain) to specify which service(or function) can the user to use.

>the usual way to authorize API calls in OpenStack is
>through policy.json.  If I remember right, you can make a decision about
>whether an API call is permitted using (i) all the values in the API call
>and (ii) the Keystone role of the user making the request.  I'm not sure if
>you can also use the actual userID of the person making the request or not,
>but as soon as you get to 10 users, you'll end up grouping individual users
>into roles anyway.

Surely, The policy.json have potential to cover above our needs.
But as I mentioned before, the deployer and administrator of OpenStack
isn't same.
And the deployer want to restrict the admin from login to the server which
start up api processes.
So the admin on OpenStack can't login to the servers of working api process.

But it can't definitely realized by policy.json.
If we prepare the api server that works changing policy.json  and  provide
the users.
But I think this solution isn't very good.
There are many reason of making this solution bad.
first reason is to make the rule of policy.json complex.
second reason is that policy file is distributed in many server and many
directory.


The reasons I'm interested in congress are followings.
 - Congress can centrally manage policy rule.
 - Congress can change policy or add policy via API.
So honestly I don't concern about dynamical policy (e.g. depending on the
policy, which network is connected to) in our use-case.


if you'll allow a slight digression,
If we integrate authorization mechanism to actual environment,
we will prepare the translator from authorization specific policy to
datalog and
we don't expose the congress in order to improve usability in the user
perspective.

Can this mail give the image of what I want to do to you?

Yuki
------------------------
>Hi Yuki,
>
>As Masahito mentioned, the usual way to authorize API calls in OpenStack is
>through policy.json.  If I remember right, you can make a decision about
>whether an API call is permitted using (i) all the values in the API call
>and (ii) the Keystone role of the user making the request.  I'm not sure if
>you can also use the actual userID of the person making the request or not,
>but as soon as you get to 10 users, you'll end up grouping individual users
>into roles anyway.
>
>That said, Congress would be valuable for authorization decisions IF those
>decisions require information other than (i) values in the API call and
>(ii) the role of the user making the request.  For example, if you wanted
>to stop someone from deleting a Neutron network whenever there is a Nova VM
>attached to that network with status ACTIVE, then policy.json isn't
>adequate, and Congress makes sense.
>
>So as Masahito mentioned, if you provide more details about your use case
>(in particular what kinds of information you need for making authorization
>decisions), we can help you pick the right tool.
>
>Tim
>
>
>
>
>On Fri, Apr 15, 2016 at 1:06 AM Masahito MUROI <muroi.masahito at
lab.ntt.co.jp>
>wrote:
>
>> Hi Yuki,
>>
>> This sounds interesting. AFAIK, there is no similar use-case you
mentioned.
>>
>> On 2016/04/15 10:13, Yuki Nisiwaki wrote:
>> > Hi openstacker working on congress.
>> >
>> > I want to implement the authorization mechanisms for each user, not
role
>> > base.
>> > For example, User A can change security group, But User B can’t change
>> > security group like IAM feature of AWS.
>> >
>> > In order to achieve it,
>> > I’m considering whether can I utilize Congress feature.
>> > I am thinking somehow that I can achieve it by following step.
>> > 1. create policy for each user with datalog in congress
>> > 2. prepare the wsgi filter for each project that works confirming
>> > authorization of each user to Congress.
>> Could you clarify your usecase? I think it can be done by roles and
>> modifying policy.json. If you assume A and B are under some conditions,
>> what kind of condition do you want to use?
>>
>> btw, I added [Congress] prefix in the subject.
>>
>> >
>> > I think this use-case is very popular and there is someone who think
>> > same thing.
>> > But There is no information about it in any website (blog, presentation
>> > in summit).
>> > So why is there anyone who achieve it?
>> > or does this approach have anxious point?
>> > If you are interested in this approach or think same thing, I want to
>> > know it.
>> >
>> >
>> > Best regards
>> >
>> > Yuki Nishiwaki
>> > NTT Communitions
>> > Technology development
>> > Cloud Core Technology Unit
>> >
>> >
>> >
>>
__________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> best regards,
>> Masahito
>>
>>
>> --
>> 室井 雅仁(Masahito MUROI)
>> Software Innovation Center, NTT
>> Tel: +81-422-59-4539
>>
>>
>>
>>
__________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at
lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160415/6e977044/attachment.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160417/034e6dea/attachment.html>


More information about the OpenStack-dev mailing list