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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
