On 02/02/2016 10:47 PM, Morgan Fainberg wrote:
On Feb 2, 2016 19:38, "Yee, Guang" <guang....@hpe.com
<mailto:guang....@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:henryna...@mac.com
<mailto:henryna...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev