Open Stack

On 02/02/2016 10:47 PM, Morgan Fainberg wrote:
>
>
> On Feb 2, 2016 19:38, "Yee, Guang" <guang.yee at hpe.com 
> <mailto:guang.yee at hpe.com>> 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?
> >
>
> Subtle differences. Local groups would be locked to a specific scope / 
> group of scopes. And Domain Specific Role (dont use the 
> initialism/acronym overloaded), would be global that could be assinged 
> to many various scopes.
>

So long as local groups are considered in addition to Domain specific 
roles, and not as a replacement.  We can do local groups today, by 
allowing users from, say a Federated backend, to be enrolled into a 
group defined in a separate domain.

> E.g. local group would be role x, Y, z on domain q.
>
> Domain specific role would be "role a, which is role x, y, z", and 
> works like any other role for user/project(ordomain) combination.
>
> The local groups we have all the code to do today.
>
> --M
> >
> >
> >
> >
> > Guang
> >
> >
> >
> >
> >
> > From: Henry Nash [mailto:henrynash9 at mac.com 
> <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.
> >
> >
> >
> > 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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> __________________________________________________________________________
> 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/20160203/3f5cf752/attachment.html>