Open Stack

On 26/10/2012 17:31, heckj wrote:
> Bringing conversation for domains in Keystone to the broader mailing lists.
>
>
> On Oct 26, 2012, at 5:18 AM, Dolph Mathews <dolph.mathews at gmail.com
> <mailto:dolph.mathews at gmail.com>> wrote:
>> I think this discussion would be great for both mailing lists.
>>
>> -Dolph
>>
>>
>> On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash <henry.nash at mac.com
>> <mailto:henry.nash at mac.com>> wrote:
>>
>>     Hi
>>
>>     <Not sure where best to have this discussion - here, as a comment
>>     to the v3api doc, or elsewhere - appreciate some guidance and will
>>     transfer this to the right place>
>>
>>     At the Summit we started a discussion on whether things like user
>>     name, tenant name etc. should be globally unique or unique within
>>     a domain.  I'd like to widen that discussion to try and a) agree a
>>     direction, b) agree some changes to our current spec. Here's my
>>     view as an opening gambit:
>>
>>     - When a Keystone instance is first started, there is only one,
>>     default, Domain.  The Cloud Provider does not need to create any
>>     new domains, all projects can exist in this default domain, as
>>     will the users etc.  There is one, global, name space.  Clients
>>     using the v2 API will work just fine.
>>
>>
>> +1
>
> Very much what we were thinking for the initial implemenation and
> rollout to make it backwards "compatible" with the V2 (non-domain) core API
>
>>     - If the Cloud Provider wants to provide their customers with
>>     regions they can administer themselves and be self-contained, then
>>     they create a Domain for each customer.  It should be possible for
>>     users/roles to be scoped to a Domain so that (effectively)
>>     administrative duties can be delegated to some users in that
>>     Domain.  So far so good - all this can be done with the v3 API.
>>
>>
>> Not clear on if you're referring to endpoint regions, or just
>> describing domain isolation?
>
> I believe you're describing the key use cases behind the domains
> mechanism to begin with - user and project partitioning to allow for
> administration of those to be clearly "owned" and managed appropriately.
>
>
>>     - We still have work to do to make sure items in other OS projects
>>     that reference tenants (e.g. Images) can take a Domain or Project
>>     ID, but we'll get to that soon enough
>>
>>
>> Everything will continue to work with projects, but once middleware
>> starts providing a DOMAIN_ID and DOMAIN_NAME to the underlying
>> service, it'll be up to them to take advantage of it. Images per
>> domain is an excellent example use case.
>
>>     - However, Cloud Providers want to start enabling enterprise
>>     customers to run more and more of the workloads in OpenStack
>>     clouds - over and above, the smaller sized companies that are
>>     doing this today.  For this to work, the encapsulation of a Domain
>>     need, I think, to be able to be stricter - and this is where the
>>     name space comes into play.  I think we need to allow for a Domain
>>     to have its own namespace (i.e. users, roles, projects etc.) as an
>>     option.  I see this as a first step to allowing each Domain to
>>     have its own AuthZ/N service (.e.g external ldap owned and hosted
>>     by the customer who will be using the Domain)
>>
>>     Implementation:
>>
>>     - A simplistic version would just allow a flag to specified on
>>     Domain creation that said whether this a "private" or "shared"
>>     Domain.  Shared would use the current global name space (and
>>     probably be the default for compatibility reasons).
>>
>>
>> I like the direction of this -- need to digest implications :)
>
> I like the idea conceptually - but let's be clear on the implications to
> the end users:
>
> Where we're starting is preserving a global name space for project names
> and user names. Allowing a mix of segregated and global name spaces
> imposes a burden of additional data being needed to uniquely place
> authentication and authorization.
>
> We've been keeping to 2 key pieces of info (username, password) to get
> authenticated - and then (via CLI or Horizon dashboard) you can choose
> from a list of protential projects and carry on. In most practical
> circumstances, any user working primarily from the CLI is already
> providing 3-4 pieces of information:
>
> * username
> * password
> * tenant name
> * auth_url

In fact these are all name/value pairs, so they can all be regarded as 
attribute names and values (or types and values in LDAP terminology).

The attribute names/types have to be globally unique. I think you have 
implicitly mandated this in Keystone by defining the names yourself, and 
by not allowing other names to be used. I presume that currently it 
would not be meaningful to pass a value of
* age
via the CLI. But it should be, since one might have an authz policy that 
bases its decision on the age of the user.

So how about considering a more generic interface where any attribute 
name and value can be passed, and the authz service will use these to 
see if they fit the policy or not.

regards

David

>
> to access and use the cloud.
>
> By allowing domains to be their own namespaces, we're adding another
> element that will be absolutely required to identify the person
> authenticating:
>   * domain name
>
> implying a cascade of changes to the user experience all the way down
> through horizon.
>
>
>>     - A more flexible approach would be to allow the specification of
>>     where the various sub-services of Keystone (e.g. AuthN/Z, Service
>>     Catalogue, Resources (i.e Users, Projects)) are hosted.  The
>>     defaults would all point back to the default domain (i.e. are
>>     global and shared), but instead could be specified as "self" (I.e.
>>     the new Domain), or, in the future, some other external location,
>>     e.g. for a remote ldap.
>>     - As an aside, this multi-name space model could also allow the
>>     Cloud Provider their own name space, separate from their customers
>>     - i.e. they will have a need to create admins who can just create
>>     domains and on-board customers into those domains.  These users &
>>     roles could exist in the default domain, while all the customers'
>>     users/roles exist solely within their own domains.
>>     - One potential problem I do see is with roles.  Today, the role
>>     name is, if I understand it correctly, a kind of shared secret
>>     between, other services and Keystone - e.g. it is the actual name
>>     of a given role, say "ProjectAdmin" , that must match in, say, the
>>     Nova policy file and the role assignment in Keystone (please
>>     correct me if I have this wrong).
>>
>>
>> You're 100% correct.
>>
>>     How would that work if the role names were not unique across Domains?
>>
>>
>> Not that we would want admins to ever see Role ID's, or edit policy
>> files with role ID's, but they provide a potential solution.
>
> The different role names would need to be accounted for in the policy
> files the way they're set up today - the enforcement there is all at the
> service level. There's no current provision for evaluating policy
> differently based on domain. While that's possible, it sounds like a
> tremendous cascade of additional complication, as the policy, and roles,
> are all set up and managed by deployers.
>
> I think this might be an interesting addition in the future, but want to
> keep the initial implementation and roll-out of the policy mechanisms
> and domains consistent and simple for a first roll-out iteration.
>
>>     What is the desired functionality for a Cloud Provider wanting to
>>     give their enterprise customers this level of flexibility - will
>>     they have dedicated Nova endpoints anyway?  Sounds too rigid.
>>      This might tie into another bp we are working on at IBM in terms
>>     of using Availability zones to allow Cloud Providers to divide up
>>     their compute resources in a more flexible way.
>>     - Finally, I wanted to raise the subject of whether we should make
>>     it a goal to remain compatible with the v2 API /once the cloud
>>     provider starts creating additional domains/.
>>
>>
>> Joe and I briefly discussed this at the summit. As a migration to v3,
>> we'd obviously be creating the default domain and mapping all existing
>> users/projectse/etc to it. I'd be fine if the v2 implementation ONLY
>> interacted with resources in that default domain; i.e. if you want to
>> use domains, upgrade to a v3 client.
>>
>>     As stated above, if just the default domain is being used, then
>>     fine.  And while I agree that, technically, the v2 API should
>>     still work with the above if all the other domains point back to
>>     the default domain for their sub-services - it feels overly
>>     flexible (and maybe wrong conceptually) to support v2 semantics
>>     across a multi-domain installation.
>>
>>
>> +1
>>
>>
>>     Interested in everyone else's view.
>>
>>     Henry
>>
>>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>