Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160418/cb4c6479/attachment.html>