Open Stack

On Feb 2, 2016 19:38, "Yee, Guang" <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.

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]
> 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://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/2f79657d/attachment.html>