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

Tim Hinrichs tim at styra.com
Tue Apr 19 16:30:31 UTC 2016


Hi Yuki,

Sounds good.  The Congress team will be at Austin next week at the summit.
Most of the team will be at most of the events that you find by searching
for "Congress".  Let us know if you want to meet face-to-face to discuss
further.

https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=congress

Tim


On Mon, Apr 18, 2016 at 6:31 PM Yuki Nisiwaki <uckey.1067 at gmail.com> wrote:

> Hi Tim,
>
> Thanks.
> Your information is very useful for me.
>
> >I know someone was doing what you are proposing to implement a
> sophisticated notion of quotas for Nova
> I'll read later and make use of it as sample program.
>
>
> >though there's been talk of a more dynamic policy.json in the past
> I didn't know there's been talk of a more dynamic policy.json.
> So I tried to search "dinamic policy.json" and
> I found the keystone blueprint (
> https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery
> ).
> And this dynamical policy blueprint might  adopt the pluggable policy
> backend.
> So I thought we can consider to use congress as this backend.
>
> I'll consider how to implement authorization system with above information
> as well.
>
>
> >One thing to think about is what kind of performance and availability
> needs you have.  Making Congress say Yes or No to every API call puts it on
> the critical path.
> Your point is very useful for me.
> Surely, I have to consider the performance problem.
>
>
> > longer term we could look into more exotic options, such as the cloud
> admin managing policy via Congress, and Congress distributing that policy
> to the services that need it.  Think of this as a mini-Congress running on
> each service.  This way, instead of each service contacting Congress on
> every API call, the service could make the Yes/No decision itself.
> This future plan is very interesting. I think this architecture is also
> useful other than this time use-case.
>
>
> Thanks your information,
> and I'll put these information in order by myself, and consider how to
> achieve it.
> I'm interested in Congress project, so I'll watch the activity of Congress.
>
> Best regards.
>
> Yuki
>
>
>
> 2016-04-19 7:35 GMT+09:00 Tim Hinrichs <tim at styra.com>:
>
>> Hi Yuki,
>>
>> That description was very helpful.  In short, policy.json doesn't work
>> because the person setting policy is not permitted to change policy.json
>> (which happens in part because policy.json has no API for controlling it).
>>
>> In that case, using Congress makes sense.  I know someone was doing what
>> you are proposing to implement a sophisticated notion of quotas for Nova.
>> As far as I know, Congress is the best option for your use case today
>>  (though there's been talk of a more dynamic policy.json in the past).  You
>> can find the plugin for Nova in the repo.
>>
>> https://github.com/openstack/congress/tree/master/contrib/nova
>>
>> One thing to think about is what kind of performance and availability
>> needs you have.  Making Congress say Yes or No to every API call puts it on
>> the critical path.  How many requests per second do you expect?  If each
>> one of those requests needs to talk to Congress, is the latency/throughput
>> of a round-trip to another service going to be a problem?  What happens if
>> the network is partitioned and the other services cannot reach Congress for
>> some period of time?  Can you deny or allow all access until the network
>> reconnects?
>>
>> The Congress team is getting close to finishing a new architecture aimed
>> at high-availability and high-throughput, so we'd love to hear more details
>> about what you think you need.
>>
>> Also, longer term we could look into more exotic options, such as the
>> cloud admin managing policy via Congress, and Congress distributing that
>> policy to the services that need it.  Think of this as a mini-Congress
>> running on each service.  This way, instead of each service contacting
>> Congress on every API call, the service could make the Yes/No decision
>> itself, and Congress would update each mini-Congress as needed.  That would
>> give you low-latency and high-availability, even in the presence of network
>> disconnections.
>>
>> Tim
>>
>>
>> On Sat, Apr 16, 2016 at 9:41 AM Yuki Nisiwaki <uckey.1067 at gmail.com>
>> wrote:
>>
>>> 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
>>> >
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
> __________________________________________________________________________
> 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/20160419/4e9d0ab3/attachment.html>


More information about the OpenStack-dev mailing list