Open Stack

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 <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
>>
>
> __________________________________________________________________________
> 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