Open Stack

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