Re: [openstack-dev] [Keystone] Splitting up the assignment component
On 11/26/2014 09:52 AM, David Chadwick wrote: I tend to agree with Morgan. There are resources and there are users. And there is something in the middle that says which users can access which resources. It might be an ACL, a RBAC role, or a set of ABAC attributes, or something else (such as a MAC policy). So to my mind this middle bit, whilst being connected to both resources and users, is separate from both of them. So we should not artificially put it with just one of them. FYI, the roles in RBAC are part of the policy specification. You define the roles, their hierarchical relationships, then assign both users and resources (privileges actually) to them. So roles could be part of the policy specification, except that the policy is distributed, so in which part of the distributed policy would you put it? Would it be in the specification of roles to actions, or in the attribute mappings, or in the user to attribute assignments? I'd say that for this split we leave roles in assignment, but that when we get to the "store policy rules in a database" spec we move them to policy. https://review.openstack.org/#/c/133814 as using Hierarchical rules to generate policy implies that the whole thing is in a unified, choherent structure. https://review.openstack.org/#/c/125704/7 regards David On 25/11/2014 16:42, Morgan Fainberg wrote: On Nov 25, 2014, at 4:25 AM, Henry Nash wrote: 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 w
Re: [openstack-dev] [Keystone] Splitting up the assignment component
I tend to agree with Morgan. There are resources and there are users. And there is something in the middle that says which users can access which resources. It might be an ACL, a RBAC role, or a set of ABAC attributes, or something else (such as a MAC policy). So to my mind this middle bit, whilst being connected to both resources and users, is separate from both of them. So we should not artificially put it with just one of them. FYI, the roles in RBAC are part of the policy specification. You define the roles, their hierarchical relationships, then assign both users and resources (privileges actually) to them. So roles could be part of the policy specification, except that the policy is distributed, so in which part of the distributed policy would you put it? Would it be in the specification of roles to actions, or in the attribute mappings, or in the user to attribute assignments? regards David On 25/11/2014 16:42, Morgan Fainberg wrote: > >> On Nov 25, 2014, at 4:25 AM, Henry Nash wrote: >> >> 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
Re: [openstack-dev] [Keystone] Splitting up the assignment component
> On Nov 25, 2014, at 4:25 AM, Henry Nash wrote: > > 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. I think there is some dissonance in storing the roles in resource. The assignment backend is what controls how the actor is connected with the scope. If you’re keeping the role within the resource backend you’re now needing to have yet another way of correlating the data from the resource side (2 elements) to the identity (user/group) side. The assignment backend is connecting the role to the actor and scope (project/domain), it should in some way be responsible for knowing what the role definition is. In the case of a crazy ABAC system, a role would need to be a mapping of attributes on the actor object, that now needs *another* layer of connection (similar to what we have now) to the roles in resource. Logically the roles seem tightly coupled to the assignment backend, not a loosely coupled-and-theoretically-can-be
[openstack-dev] [Keystone] Splitting up the assignment component
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 flexibilityfor 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 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
