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
