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 > On 10 Nov 2015, at 09:50, Steven Hardy <sha...@redhat.com> 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: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev