Open Stack

On 02/02/2016 10:37 PM, Yee, Guang wrote:
>
> I presume there’s a spec coming for this “seductive approach”? Not 
> sure if I get all of it. From what’s been described here, 
> conceptually, isn’t “local groups”, DSRs, or role groups the same thing?
>
> Guang
>
> *From:*Henry Nash [mailto:henrynash9 at mac.com]
> *Sent:* Monday, February 01, 2016 3:50 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [keystone] Domain Specific Roles vs Local 
> Groups
>
> Hi
>
> During the recent keystone midcycle, it was suggested than an 
> alternative domain specific roles (see spec: 
> https://github.com/openstack/keystone-specs/blob/master/specs/mitaka/domain-specific-roles.rst and 
> code patches starting at: https://review.openstack.org/#/c/261846/) 
> might be to somehow re-use the group concept. This was actually 
> something we had discussed in previous proposals for this 
> functionality. As I mentioned during the last day, while this is a 
> seductive approach, it doesn’t actually scale well (or in fact provide 
> the right abstraction). The best way to illustrate this is with an 
> example:
>
> Let’s say a customer is being hosted by a cloud provider. The customer 
> has their own domain containing their own users and groups, to keep 
> them segregated from other customers. The cloud provider, wanting to 
> attract as many different types of customer as possible, has created a 
> set of fine-grained global roles tied to APIs via the policy files. 
> The domain admin of the customer wants to create a collection of 10 
> such fine-grained roles that represent some function that is 
> meaningful to their setup (perhaps it’s job that allows you to monitor 
> resources and fix a subset of problems).
>
> With domain specific roles (DSR) , the domain admin creates a DSR 
> (which is just a role with a domain_id attribute), and then adds the 
> 10 global policy roles required using the implied roles API. They can 
> then assign this DSR to all the projects they need to, probably as a 
> group assignment (where the groups could be local, federated or LDAP). 
> One assignment per project is required, so if there were, over time, 
> 100 projects, then that’s 100 assignments. Further, if they want to 
> add another global role (maybe to allow access to a new API) to that 
> DSR, then it’s a single API call to do it.
>
> The proposal to use groups instead would work something like this: We 
> would support a concept of “local groups” in keystone, that would be 
> independent of whatever groups the identity backend was mapped to. In 
> order to represent the DSR, a local group would be created (perhaps 
> with the name of the functional job members of the group could carry 
> out). User who could carry out this function would be added to this 
> group (presumably we might also have to support “remote” groups being 
> members of such local groups, a concept we don’t really support today, 
> but not too much of a stretch). This group would then need to be 
> assigned to each project in turn, but for each of the 10 global roles 
> that this “DSR equivalent” provided in turn (so an immediate increase 
> by a factor of N API calls, where N is the number of roles per DSR) - 
> so 1000 assignments in our example. If the domain admin wanted to add 
> a new role to (or remove a role from) the “DSR”, they would have to do 
> another assignment to each project that this “DSR” was being used (100 
> new assignments in our example).  Again, I would suggest, much less 
> convenient.
>

Let me see if I can say the same thing clearer:

Groups will only map to a single set of users to projects.  If you have 
two or more distince sets of users, and you want to map them to two 
distinct sets of projects, groups won't help.  You will end up having to 
duplicate the structure of the role assignments for each group.


DSRs are essentially templates of role assignments.  If you want to make 
it so users of your cloud get only operations on VMs, read on glance, 
and that is it, you create a domain specific role which points only to 
those system defined roles, and you use that.


You can't do it with groups alone.

> Given the above, I believe the current DSR proposal does provide the 
> right abstraction and scalability, and we should continue to review 
> and merge it as planned. Obviously this is still dependant on Implied 
> Roles (either in its current form, or a modified version). Alternative 
> code of doing a one-level-only inference part of DSRs does exist (from 
> an earlier attempt), but I don’t think we want to do that if we are 
> going to have any kind of implied roles.
>
> Henry
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160202/8dfdf078/attachment.html>