Open Stack

Excerpts from Adam Young's message of 2015-10-19 22:53:14 +0900:
> While I tend to play up  bug 968696 for dramatic effect, the reality is 
> we have a logical contradiction on what we mean by 'admin' when talking 
> about RBAC.
> 
> In early iterations of OpenStack, roles were global.  This is reflected 
> in many of the Policy checks that only look for the global role.  
> However, prior to the Keystone-Light rewrite, role assignments became 
> scoped to tenants.  This shows up in the Keystone git history.  As this 
> pattern got established, some people wrote policy checks that assert:
> 
>       role==admin and tenant_id=resource.tenant_id
> 
> This contradicts the global-ness of the admin roles.  If I assign
> ('joeuser', 'admin','mytenant') I've just granted them the ability to 
> perform all of the admin operations.
> 
> Thus, today we have a situation where, unless the user rewrites the 
> default policy, they have to only assign the role  admins to users that 
> are trusted to be admins on the whole deployment.
> 
> We have a few choices.
> 
> 1.  Remove Admin from the scoping for projects. Admin is a special role 
> reserved only for system admins.  Replace project scoped admins with 
> 'manager' or some other comparable role.  This is actually the easiest 
> solution.
> 
> 2.  Create a special project for administrative actions.  Cloud admin 
> users are assigned to this project. Communicate that project Id to the 
> remote systems.  This is what the policy.v3cloudsample.json file 
> (http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json) 
> recommends.
> 
> However, 2 is really not practical without some significant 
> engineering.  For a new deployment, it would require the following steps.
> 1) Every single policy file would have to be "templatized"
> 2) Then deployment mechanism would have to create the admin project, get 
> the id for it, and string replace it in the policy file.

I'm glad we're hashing the details of this out, because I've always
found policy file maintenance daunting because of the weird juxtaposition
between careful role assignment, and the user-0 super user access that
'admin' grants.

Can I ask one thing though, can we use a domain name + project _name_
and not the ID?

Using ids in config files means that you cannot configure a service
until after Keystone has been initialized and loaded with data. Of
course this is totally doable, but it puts a huge burden on the config
layer.

However, using logical names means that the physical, random ID that gets
assigned is irrelevant to the configuration step, and thus one can have
a much easier to understand configuration process with static options.

My understanding is that domain+project is a unique ID in Keystone, so
is there any reason not to use that?