On 11/10/2015 05:08 AM, Henry Nash wrote:
Steve,
Currently, your best option is to use something similar to the
policy.v3cloudsample.json, where you basically “bless” a project (or domain) as
being the “cloud admin project/domain”. Having a role on that gives you
super-powers. The only trouble with this right now is that you have to paste
the ID of your blessed project/domain into the policy file (you only have to do
that once, of course) - basically you replace the “admin_domain_id” with the ID
of your blessed project/domain.
What we are considering for Mitaka is make this a bit more friendly, so you
don’t have to modify the policy file - rather you define your “blessed project”
in your config file, and tokens that are issue on this blessed project will
have an extra attribute (e.g. “is_admin_project”), which your policy file can
check for.
Henry is using a bitof the British tendency toward understatement here.
Let me make this more explicit:
We are going to add a value to the Keystone token validation response
that will indicate that the proejct is an admin project. Use that.
Don't develop something for Mitaka that does not use that.
The spec is here
https://review.openstack.org/#/c/242232/
And, as you can see, Henry and I are working on getting it tight enough
to stand the test of time.
There is a sample implementation underway here:
https://review.openstack.org/240719
Henry
On 10 Nov 2015, at 09:50, Steven Hardy <[email protected]> wrote:
Hi all,
Seeking some guidance (particularly from the keystone folks) ref this bug:
https://bugs.launchpad.net/heat/+bug/1466694
tl;dr - Heat has historically been careful to make almost all requests
scoped to exactly one project. Being aware of the long-standing bug
#968696, we've deliberately avoided using any global "is admin" flag
derived from the admin role.
However, we're now being told this is operator hostile, and that we should
provide an option for policy.json to enable global admin, because other
projects do it.
What is the best-practice solution to this requirement?
I'm assuming (to avoid being added to bug #968696) that we must not enable
global admin by default, but is it acceptable to support optional custom
policy.json which defeats the default tenant scoping for a requst?
For example, in policy.v3cloudsample.json[1] there are several options in
terms of "admin-ness", including admin_required which appears to be the
traditional global-admin based on the admin role.
It's quite confusing, are there any docs around best-practices for policy
authors and/or what patterns services are supposed to support wrt policy?
I'm wondering if we should we be doing something like this in our default
policy.json[2]?
"admin_required": "role:admin",
"cloud_admin": "rule:admin_required and domain_id:admin_domain_id",
"owner" : "user_id:%(user_id)s or user_id:%(target.token.user_id)s",
"stacks:delete": "rule:owner or rule:cloud_admin"
I'm not yet quite clear where admin_domain_id is specified?
Any guidance or thoughts would be much appreciated - I'm keen to resolve
this pain-point for operators, but not in a way that undermines the
OpenStack-wide desire to move away from global-admin by default.
Thanks!
Steve
[1]
https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json
[2] https://github.com/openstack/heat/blob/master/etc/heat/policy.json
__________________________________________________________________________
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
