Hi

As most of you know, we have approved a spec 
(https://review.openstack.org/#/c/129397/) to split the assignments component 
up into two pieces, and the code (divided up into a series of patches) is 
currently in review (https://review.openstack.org/#/c/130954/). While most 
aspects of the split appear to have agreement, there is one aspect that has 
been questioned - and that is the whether "roles' should be in the "resource" 
component, as proposed?

First, let's recap the goals here:

1) The current "assignment" component is really what's left after we split off 
users/groups into "identity" some releases ago.  "Assignments" is pretty 
complicated and messy - and we need a better structure (as an example, just 
doing the split allowed me to find 5 bugs in our current implementation - and I 
wouldn't be surprised if there are more).  This is made more urgent by the fact 
that we are about to land some big new changes in this area, e.g. hierarchical 
projects and a re-implemntation (for performance) of list_role_assignments.

2) While Keystone may have started off as a service where we "store all the 
users, credentials & permissions" needed to access other OpenStack services, we 
more and more see Keystone as a wrapper for existing corporate authentication 
and authorisation mechanisms - and it's job is really to provided a common 
mechanism and language for these to be consumed across OpenStack services.  To 
do this well, we must make sure that the keystone components are split along 
sensible lines...so that they can individually wrap these corporate 
directories/services.  The classic case of this was are previous split off of 
Identity...and this new proposal takes this a step further.

3) As more and more broad OpenStack powered clouds are created, we must makes 
sure that our Keystone implementation is as flexible as possible. We already 
plan to support new abstractions for things like cloud providers enabling 
resellers to do business within one OpenStack cloud (by providing hierarchical 
multi-tenancy, domain-roles etc.). Our current assignments model is a) slightly 
unusual in that all roles are global and every assignment has 
actor-target-role, and b) cannot easily be substituted for alternate assignment 
models (even for the whole of an OpenStack installation, let alone on a domain 
by domain basis)

The proposal for splitting the assignment component is trying to provide a 
better basis for the above.  It separates the storing and CRUD operations of 
domain/projects/roles into a "resource" component, while leaving the pure 
assignment model in "assignment".  The rationale for this is that the resource 
component defines the entities that the rest of the OpenStack services (and 
their policy engines) understand...while assignment is a pure mapper between 
these entities. The details of these mappings are never exposed outside of 
Keystone, except for the generation of contents of a token.  This would allow 
new assignment models to be introduced that, as long as they support the api to 
"list what role_ids are mapped to project_id X for user_id Y", then the rest of 
OpenStack would never know anything had changed.

So to (finally) get the the point of this post...where should the role 
definitions live? The proposal is that these live in "resource", because:

a) They represent the definition of how Keystone and the other services define 
permission - and this should be independent of whatever assignment model we 
choose
b) We may well chose (in the future) to morph what we currently means as a 
role...into what they really are, which is a capability.  Once we have 
domain-specifc roles (groups), which map to "global roles", then we may well 
end up, more often than not, with a role representing a single API capability.  
"Roles" might even be "created" simply by a service registering its 
capabilities with Keystone.  Again, this should be independent of any 
assignment model.
c) By placing roles in the resource component, we allow much greater 
flexibility....for example we could have different domains having different 
assignment models (e.g. one RABC, one ABAC, one HenrysWeirdAccessControl 
(HWAC). Obviously this would be aimed at a different type of cloud than one 
that has multiple layers of domain inheritance - but that's part of the goal of 
OpenStack, to allow different models to be supported.

I am absolutely open to arguments that roles should remain with 
"assignments"...but right now the above feels the better solution. I've put 
this topic on the agenda for today's Keystone IRC meeting.

Henry

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to