Open Stack

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 <shardy at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev