Bringing conversation for domains in Keystone to the broader mailing lists.
On Oct 26, 2012, at 5:18 AM, Dolph Mathews <dolph.math...@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.n...@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 > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
