Open Stack

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.

We could make this happen in Devstack.  The same is true of Puppet, 
OSAD, and Fuel.  There would be a lag and the downstream mechanisms 
would eventually pick it up, multiple releases down the road.
I went through this logic back when I started proposing the Dynamic 
Policy approach.  If OpenStack managed policy deployment via an 
inte4rnal mechanism, then adding things like the admin_project_id 
becomes trivial.


While I think Dynamic Policy provides a lot of value, I concede that it 
is overkill for just substituting in a single value.  The real reason I 
am backing off Dynamic Policy for the moment is that we need to better 
understand what part of policy should be dynamic and what part should be 
static;  we are just getting that clean now.


There is an additional dimension to the admin_project_id issue that 
several developers want solved.  In larger deployments, different users 
should have administrative capabilities on different endpoints.  
Sometimes this is segregated by service (storage admins vs network 
admins) and sometimes by region.

Having a special project clearly communicates the intention of RBAC.  
But even clearer would be to have the role assignment explicitly on the 
catalog item itself.  Which of the following statements would you think 
is clearer?


1) Assign Joe the admin role on the project designated to administer 
endpoint 0816.
2) 1) Assign Joe the admin role on endpoint 0816.

I think you will agree that it is the latter.  Making this happen would 
not be too difficult on the Keystone side, and would require fairly 
simple changes on the policy enforcement of the remote projects.  We've 
already discussed "endpoint binding of tokens" where an endpoint needs 
to know its own ID.  Having a new "scope" in a token that is endpoint_id 
would be fairly easy to execute.


One project, though, it that all of the client tooling would need to 
change.  Horizon, openstackclient, and keystoneauth would need to handle 
"endpoint" as the scope.  This includes third party integrations, which 
we do not control.


All of these constraints drive toward a solution where we link the admin 
project to the existing endpoint ids.

Make the catalog a separate domain.
Make regions, services, and endpoints projects
Use the rules of Hierarchical Multitenancy to manage the role 
assignments for a project.

On the enforcing side, endpoints *must* know their own ID.  They would 
have checks that assert token.project_id = self.endpoint_id.

This is the "least magic" approach.  It reuses existing abstractions 
without radically altering them.  The chance of a collision between an 
existing project_id and and endpoint_id is vanishingly small\, and could 
be addressed by modifying one or the other accordingly. The biggest 
effort would be in updating  the policy files, but this seems to be 
within the capability of  cross project efforts.


We will be discussing this at the Cross Project session at the summit  
on Global Admin

https://mitakadesignsummit.sched.org/event/51c8f2ea29aa0b63f85e424b0acf9741

Please read this, process it, and be ready to help come to a proper 
conclusion of this bug.


References:
"admin"-ness not properly scoped
https://bugs.launchpad.net/keystone/+bug/968696
Original Dynamic Policy Post 
https://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
Current Dynamic Policy Wiki https://wiki.openstack.org/wiki/DynamicPolicies
Endpoint_ID from URL https://review.openstack.org/#/c/199844/
Catalog Scoped Roles https://review.openstack.org/#/c/228477/