Open Stack

Hi

So yes, I am expecting that some services to have to become "domain aware".  Here's the problem:

In Folsom and before, the concept of a tenant/organization and the collection of items related to a work being run on openstack were merged together in one container (called tenant).  In Grizzly we are enabling a separation (if required) for this into a Domain (that is a container that can represent the organization being hosted within an openstack implementation) and a set of projects that represent the work being done and will come and go with the lifecycle of the applications/work involved).  Such a distinction is a must for any kind of enterprise.  Further, there will be aspects of the openstack implmentation that a cloud provdier will want to manipualte a the group level - e.g. setting a quota for, as well as assigning some logical part of the infrastructure to, an organization (i.e. domain).  In addition, an organization may want some object to be domain-wide, e.g. some standard images that all their projects can use.  An example desired  entity relationship might look like this:


I appreciate that we have not yet agreed the items in red, but it appears logical to me that we will need them.  The question is how would we provide authorization backbone for this?  One option is domain scoping would not apply to children of sub-containers like projects (i.e. getting a token to a domain does NOT authorize you to manipulate the projects).  So projects would not be returned in this case....and a project-scoped token would have to be obtained later to work  on a project.  Clearly some more discussion required here.  In fact, conceptually you might say that some of the project CRUD in Keystone should be done with a domain scoped token...but I know that we don't use this model in keystone). 

Our challenge is to balance the above model, with the current one where a cloud provider wanting to host individuals or SMEs by not using domains (except one big common domain) and each "customer" just gets a project to work in.  Do we want to continue to recommend this as a model - or actually, is the recommended model always to create a domain with minimally one project in it?  While that is conceptually nice, maybe too much overhead.

Henry
On 29 Nov 2012, at 13:59, Dolph Mathews wrote:

> Are you expecting other services to accept a token "scoped to a domain" as having authorization to perform operations on a specific tenant in that domain?
> 
> If so, this either forces every service to become aware of keystone domains (and look up their containing tenants), or for keystone to return a potentially massive list of tenants as part of the token (making PKI tokens enormous).
> 
> If not, it seems like a mechanism to provide in conjunction with role grants across domains, in order to produce/exchange tokens for more narrowly scoped tokens... but as a user, I'd be confused when the auth_token middleware rejected such a broadly scoped token.
> 
> 
> -Dolph
> 
> 
> On Thu, Nov 29, 2012 at 2:21 AM, Henry Nash <henryn at linux.vnet.ibm.com> wrote:
> Hi
> 
> One of the requests from the summit was for allowing the scoping of a token to multiple projects, and this is being worked on for Grizzly.  However, I would like us to re-visit (or maybe just re-clarify) this requirement - whilst also considering the option of scoping to a domain (see blueprint at : https://blueprints.launchpad.net/keystone/+spec/domain-scoping).
> 
> Now the whole point of scoping to anything, is to make it possible (and in some cases easier) to execute operations on the granularity that you have "scoped to". It seems to me that now we have a domain as the logical container for users and projects, clearly one of the common usages will be operations that want to look at all the projects (or some aspect of projects) in a domain - hence the idea of scoping to a domain.  This would provide a somewhat simpler, both request & response, than an appropriately scoped token than an arbitrary list of projects (where you end up returning a nested set of projects and their domains in the response, for example).  Further, if we had this, would we really need the ability to scope to multiple projects from different domains (which is technically the request on the table right now)?  Remember, scoping is defining the access rights - just allowing a suitable granularity of scope for upcoming operations - so you only really need a complex scope if the you have some operation that needs to carried out across that complex set of objects.  Are there such a set of operations that people have in mind?
> 
> I raise this so that we just look at whether there is some simplification to the expansion of ability to scoping, before we go too far.
> 
> Henry
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> 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/20121204/65caab3d/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenStack_Enterprise_Entity_Relationships.pdf
Type: application/pdf
Size: 68206 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121204/65caab3d/attachment-0001.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121204/65caab3d/attachment-0003.html>