Open Stack

On Mar 30, 2012, at 7:41 AM, Julien Danjou wrote:

> On Fri, Mar 30 2012, Gabriel Hurley wrote:
> 
>> In practice today, Keystone no longer has global roles, and RBAC
>> implementation isn't fully there yet across the ecosystem. So projects have
>> adopted inconsistent means of determining when and how to grant
>> "admin"-level privileges to that user. This isn't something individual
>> projects can decide, though. It has to be agreed upon and consistent.
>> 
>> I don't have a great solution for this problem since it's so very late in
>> the Essex release cycle. However, I'm hoping we can perhaps do *something*
>> other than to simply document that "users with admin-level permissions
>> should only ever be granted admin permissions on a single admin tenant, and
>> no other users should be granted an admin role anywhere."
>> 
>> All that said, I'm deeply concerned about the security implications of
>> real deployments being unaware of the unintended consequences of
>> granting what appears to be a scoped "admin" role.
> 
> Correct me if I'm wrong, but it seems to me that the problem is simply
> that the default policy used in keystone and nova says that "admin is
> anybody with role `admin' on any tenant", as you can see in their
> respective policy.json files.
> 
> I think that this rule should probably be set to something else by
> default, like the user is admin if "it has role admin on a specific
> tenant (like a tenant named `admin')". Tthat would allow to emulate the
> old "global" admin role, just by using a specific tenant.

I think this is a reasonable workaround.  Devstack creates service tenants, so that seems like a good place to put them. Unfortunately that means we have to keep track of an admin tenant id in nova, and it complicates things by having to create the tenant and put the id into a config. Perhaps we could use differently named roles to minimize confusion and keep the config simpler.

system_admin vs tenant_admin or some such