Open Stack

On 06/19/2015 01:08 AM, Osanai, Hisashi wrote:
> Adam,
>
> Thank you for the information RBAC Policy Basics.
>
> Thursday, June 18, 2015 1:47 AM, Adam Young wrote:
>> However, we have found a need to have a global override.  This is a way a cloud admin that can go into any API anywhere and fix things.
>> This means that Glance, Neutron, Nova, and Keystone should be able to share a policy file.
> What situations does a shared policy file require?
>
> For example, there are policy files for Nova and Cinder and they have same targets such as
> "context_is_admin", "admin_or_owner" and "default".

A lot of these internal rules most likely should  be removed.  They do 
conflict, with differenet interpretations between the proejcts. They are 
also confusing two different things:  scope and role./  I think we 
should make it a point to keep them separate.


>
> (1) load both policy.json files on a server process then the targets will be overridden by 2nd loaded policy.json.
>      A cloud admin changes the 2nd policy.json only.

Actually, we should specify when uploading whether it is an override or 
not.  If it is not an over rider, we would only pick up these "new" 
rules that are not covered by existing ones.

I suspect that managing the stack of policy files this wayi s going to 
be much like a git repo.

> (2) A cloud admin changes the targets in different policy.json files at one time.
>
> Did you mention about case(2)?
>
> Nova:   https://github.com/openstack/nova/blob/master/etc/nova/policy.json
> Cinder: https://github.com/openstack/cinder/blob/master/etc/cinder/policy.json
>
> "context_is_admin": "role:admin",
> "admin_or_owner":  "is_admin:True or project_id:%(project_id)s",
> "default": "rule:admin_or_owner",
I think we will need service specific defaults, although I could see the 
case for the default everywhere being "if not specified, match the 
project, and require the admin role."  But matching the project is going 
too be tricky.  Nova has it in teh URL for the resources, but I don;t 
think mnost of the other projects do...even if they do, it only takes 
one sensitive operation without project_id in the URL to break the pattern.


>
> BTW, I sent the following email in this list. I think I found right person who
> can answer my question? :-)
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-May/063915.html
> - HTTP_X_SERVICE_ROLES handling in _checks.py

I've missed there there was another  push for "Service specif roles" out 
there.  We've been trying to make the concpet slighly more general by 
saying that we were going to namespace roles, and that a Service would 
be one potential namwspacing.  Henry Nash had proposed Domain Specific 
roles, in case you were wondering what else would need to be namespaced.

https://review.openstack.org/#/c/133855/






>
> Thanks in advance,
> Hisashi Osanai
>
> __________________________________________________________________________
> 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