Hierarchical administrative boundary

Registered by Arvind Tiwari

We need to support domain hierarchy to establish Hierarchical administrative boundary. This is needed to support Reseller or "virtual cloud on a physical cloud", as details below

### Requirement ###

Service provider (GlobalSvcInc) sells its services to multiple customers over 3rd party cloud establishments (CloudProviderInc).
GlobalSvcInc wanted have virtual cloud on CloudProviderInc's cloud infrastructure, so that it appears that GlobalSvcInc has its own cloud deployments.

More Req
1. Ability to spin up multiple Service providers like GlobalSvcInc.
2. Service provider (GlobalSvcInc) should be able to fully administer/control its customer without depending on CloudProviderInc.
3. Cross domain access for leaf domains, access across domains should be restricted.

### Solution ###

In a nutshell, We need ability to setup hierarchical administrative boundaries within a cloud deployment, so that multiple service providers (like GlobalSvcInc) can be created and have administrative privilege across multiple domains which falls under their administrative boundary.

(Solution for Req#1) Keystone has concept of domains which is nothing but a notion of an administrative boundary where admin of one domain is allowed to manage resources within a specific domain but not across domains, provided correct policy is in place. This is already in place so there will be no change needed to support Req #1.

(Solution for Req#2)
We can extend the notion of domains further to define a root (parent/super) domain and leaf (child/sub) domains, one set of root and leaf domains will define a hierarchical administrative boundary. Glue between root and leafs will be different roles, that way "GlobalSvcInc" can become "NovaAdmin" (or any other role) in leaf domains.

Service provider (GlobalSvcInc) administrator has to scope his/her security token to a particular child domain to acquire administrative roles. Malicious and unauthorized access will be prevented by Keystone RBAC policy enforcement.

Blueprint information

Arvind Tiwari
Needs approval
Arvind Tiwari
Series goal:
Milestone target:
Completed by
Steve Martinelli

Related branches



(morganfainberg): This will have more information once the HM topic at the kilo summit has been discussed.
We have tecowg requirements for MNO to MVNO hierarchy besides subscriber as User within MVNO as another layer of tree. Am aadding that under telcowg for reference.

(atiwari) Adding some related links

(stevemar) please use the new keystone-spec repo for all new features


Work Items

This blueprint contains Public information 
Everyone can see this information.