Open Stack

On 10/26/2012 07:17 PM, Henry Nash wrote:
> So to pick up on a couple of the areas of contention:
>
> a) Roles.  I agree that role names must stay globally unique.  One way 
> of thinking about this is that it is not actually keystone that is 
> creating the "role name space" it is the other services (Nova etc.) by 
> specifying roles in their policy files.  Until those services support 
> domain specific segmentation, then role names stay global.
>
> b) Will multi-domains make it more complicated in terms of 
> authorisation - e.g. will the users have to input a Domain Name into 
> Horizon the whole time?  The first thing I would say is that if the 
> cloud administrator has create multiple domains, then the keystone API 
> should indeed require the domain specification.  However, that should 
> not mean it should be laborious for a Horizon user.  In the case where 
> a Cloud Provider has created domains to encapsulate each of their 
> customers - then if they want to let those customer use horizon as the 
> UI, then I would think they want to be able to give each customer a 
> unique URL which will point to a Horizon that "knows which domain to 
> go to".
Yes, I think that this is the solution.  It will involve HTTPD virtual 
hosts, and horizon can then get an additional config parameter 
"keystone_domain" as part of the wsgi config.


>  Maybe the url contains the Domain Name or ID in the path, and Horizon 
> pulls this out of its own url (assuming that's possible) and hence the 
> user is never given an option to chose a domain.  A Cloud Admin would 
> use a "non domain qualified url" to get to Horizon (basically as it is 
> now) and hence be able to see the different domains.  Likewise, in the 
> case of where the Cloud Provider has not chosen to create any 
> individual domains (and is just running the cloud in the default 
> domain), then the  "non domain qualified url" would be used to a 
> Horizon that only showed one, default domain and hence no choice is 
> required.
>
>
> Henry
>
> On 26 Oct 2012, at 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
>>
>> 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
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121026/a0c5b65c/attachment.html>