Open Stack

Is this targeted for Grizzly or ?

Endre.

2012/11/20 Henry Nash <henryn at linux.vnet.ibm.com>

> So to try and take the discussion further, I think, we are really down to
> 2 options - either implement the current "user groups" proposal
> more-or-less as is or re-structure this to look more like what role mapping
> will be in any federation implementation.  Here's a brief
> comparison/analysis
>
> - In general, a cloud service will define the various roles that it
> supports in its own native terminology.  In openstack today this is done
> within the policy.json files of each service.  Note that it is the service
> that defines the roles and how granular they are (e.g. you COULD define a
> role for calling each api, or you could cluster this together into some
> smaller subset of roles, as most services tend to - it's up to the
> service/endpoint).
> - This gives us clear problems in two user scenarios
> a) A cloud provider runs an openstack installation to host a cloud that
> has many large enterprises as customers.  For large customers with many
> users & projects it will often become impractical to assign each user
> specific roles on projects.  Rather they will want a away of "grouping"
> users together and assigning the role to that group of users to a project.
>  Note that grouping will be customer specific and cannot be defined by the
> cloud provider (since they don't know what groups make sense for any given
> customer, nor do they want to). For a more detailed example, see the
> blueprint: https://blueprints.launchpad.net/keystone/+spec/user-groups.
> b) For a user that visits many different clouds, how is it that the cloud
> providers can co-operate so that they agree on some standards for roles and
> authentication so that the user does not have to create all these
> separately with each cloud provider?  This is the core of the federation
> proposal - how the to enable cloud providers, customers, users and 3rd
> parties to agree on who will confirm identity and map roles that make sense
> to the customer and/or external standards into specific roles that the
> various service providers have defined.
>
> The two proposal have grown up in an attempt to find solutions to a) and
> b).  The question is whether it is more appropriate to:
>
> 1) Extend the federation model to (effectively) include mapping between
> the customers-specifc roles created in a domain and the roles various cloud
> services within a non-federated openstack, or
> 2) Implemented a more specific, and more common, solution ("groups of
> users") for intra-openstack mapping and keep the federation mapping for its
> original design to engage across 3rd parties and multiple clouds
> (inter-openstack)
>
> The added complication, is that we ideally want something we can do within
> Grizzly, i.e. that does not involve significant changes to the already
> implemented v3 Keystone APIs.  The full federation implementation is a
> Medium term goal, so if we took that option, we would need to implement the
> intra-openstack bit first, ahead of the full work.
>
> My personal preference, putting my cards on the table, is to go for the
> simpler, groups-of-users approach - since it is a common solution to this
> issue (in use by other products today), is a relatively simple extension to
> the current v3 API - and allows federation to concentrate on what it is
> designed to do.  Of course, as we know, you can adapt s/w to do (almost)
> anything, but this, to me, seems the best course.
>
> Again, interested in other people's views.
>
> Henry
> On 17 Nov 2012, at 21:28, Henry Nash wrote:
>
> > Hi
> >
> > Expanding a discussion regarding:
> https://blueprints.launchpad.net/keystone/+spec/user-groups
> >
> > Thanks to Guang Yee and David Chadwick for their detailed comments.  I
> think right now there
> > are no outstanding questions in terms of the actual proposal in of
> > itself - other than the interesting point of view from David that in
> > fact you could achieve the same affect by using the role mapping
> > concept from the federation proposal.  I'll try and summarize David's
> > point:
> >
> > "For federation, in order to be able to effectively use/chose from
> > many external Identity Providers and Attribute Authorities, there
> > must be mapping between the attributes/roles that the cloud service
> > itself understands and those defined by those external authorities.
> > [This is proposed to be a function of the Openstack Gateway in the
> > current federation proposal].  One could therefore imagine extending
> > this to where this could also be used to map the customer defined
> > roles (e.g. Teacher, Pupil) to roles that were exposed by the Gateway
> > for the cloud service required."
> >
> > So I think we need to discuss how best to move forward.  In my mind
> > there are a few options:
> >
> > 1) Just bundle this requirement up with federation.
> >
> > 2) Implement a role mapping capability that is broadly api compatible
> > with what we will do with federation.  In this we would take the
> > first steps at re-deinfing the terminology (i.e. what's a cloud
> > service attribute and what's a locally-defined role), provide a
> > mapping capability, start to evolve the appropriate Ui etc.
> >
> > 3) Just implement the groups concept as defined.  In the long run
> > maybe this is replaced (or made redundant) by role mapping, but only
> > if we chose to drive the federation mapping into non-federated
> > configurations of openstack.
> >
> > My concerns are: a) Federation is a really important capability we
> > need and will get delivered in the future.  Given its scope, however,
> > pretty sure this is not a Grizzly item - and maybe even longer? b) We
> > will always have this balancing act of what features we put in a
> > "self-contained" (i.e. non-federated) openstack implementation - and
> > I feel the basic assignment (using today's keystone terms) of roles
> > to groups of users is imperative for large enterprise use (it is
> > certainly what we have found in other products)
> >
> > However, I'd been keen to this group's view of these options.  I do
> > believe that grouping or mapping is an important capability we need
> > to add - and really want to find a way of getting this into Grizzly
> > in some shape or form.
> >
> > David's comments to the above:
> >
> > Hi Henry
> >
> > Thanks for your summary, which is fine.
> >
> > Given that federation will be implemented in the medium term, there is
> nothing to stop components of it being implemented now. For example, Kristy
> has just shown me how the directory function needed for federation can be
> implemented using an enhanced services catalog with the existing interface,
> and she will distribute the design for this on Monday for you guys to
> comment upon.
> >
> > I would therefore support implementing the mapping function now to
> support current use cases (option 2 below) then it can subsequently be used
> by federation when the latter is integrated. I dont think the API for
> attribute/role mapping will be that difficult to define. The tricky thing
> is to get the access controls right, so that each organisational
> administrator is only allowed to map his organisational roles/attributes
> into the cloud service roles that the cloud administrator has granted him
> access to (we call this the administrative scope of the organisational
> administrator). For example, there may be an admin role defined for a cloud
> service, which has super-user privileges that the cloud administrator uses,
> but he does not want the organisational administrators to have access to
> this. So when they perform role mapping they would not be allowed to map
> their staff or programmer role, say, into the admin role.
> >
> > The first step could be to have a design blueprint for mapping that we
> all contribute to. If you are happy to proceed on this basis, maybe Henry,
> or Kristy and myself, can start on this next week
> >
> > regards
> >
> > David
> >
> >
> >
> >
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20121120/dc8a09df/attachment.html>