Hierarchical administrative boundary

Abstract:
In large scale OpenStack based cloud deployments, cloud provider (CP) may wants to sell their services in White Label (AKA Reseller or value-added reseller) business model. This is a symbiotic relation as CP sells its services in bulk and Reseller gets appropriate discounts.

In such business model CP setup a "virtual private cloud" (VPS) for each Resellers on its infrastructure or hosting cloud (HC). A reseller acquires special privileges to administer its customers and resources allocated on its customer's disposal.

CP perspective:

 * 1) Cloud provider want to have capabilities to manage multiple Resellers accounts.
 * 2) Ability to spin up multiple reseller accounts on demand.
 * 3) Ability to administer resellers accounts including their direct resources (IAM and NON-IAM).
 * 4) Ability to administer sub-customers (direct customer to resellers) including their resources (IAM and NON-IAM)..

e.g. Cloud Provider Inc. (CPI) has large scale OpenStack based deployment and sells it services in Reseller mode.

Reseller perspective:

 * 1) A reseller want to have it own realm (vpc) over CP's cloud infrastructure and expect re-branding aspects.
 * 2) Ability to spin up multiple accounts on behalf of my customers without interventions from CP.
 * 3) Ability to administer my customers without interventions from CP.
 * 4) Ability to administer my customers resources (IAM and NON-IAM) without interventions from CP.

e.g. Services Provider Inc. (SPI) a service provider which sells its services to multiple customers over 3rd party cloud establishments.

Potential Solution:
Note: The scope of this proposal is low-level, and is focused on the architectural changes limited to Identity management (Keystone) system only.

To solve these problem, We need an ability to setup hierarchical administrative boundaries within a cloud deployment, so that multiple service providers (like SPI) can be created and have administrative privileges across domains which falls under their administrative boundary. In this model CP will be the root of the hierarchical administrative boundary.

Keystone has concept of domains which is nothing but a notion of an administrative boundary. An admin of one domain is allowed to manage resources (Computing and non computing) within a specific domain but not across domains (provided correct policy is in place). This feature is already in place so there will be no change needed.

We can extend the notion of domain further to establish root (parent/super) and leaf (child/sub) domain relationship, one set of root and leaf domains will define a hierarchical administrative boundary. Below diagram depicts a domain hierarchy where the root represents the cloud providers (root administrative boundary) and each levels below represents different hierarchical administrative boundaries.



Keystone provide robust role based access control (RBAC) capabilities where roles are associated with access control rules through policy. Subjects are associated with roles scoped to a domain or projects within a domains. Keystone also support a notion of inherited roles which allows roles (mostly project) to be inherited from owning domain. We need to extend the current role inheritance model so that subject's (identity in keystone) inherited roles (project and/or domain) can be propagated down in the domain hierarchy. Diagram below shows the role inheritance propagation.

Note: Role inheritance propagation will go downwards only but not upwards or side wise.



Cloud provider (or reseller) administrator has to scope his/her security token to a particular child domain (or a project in child domain) to acquire the inherited administrative roles. Malicious and unauthorized access to external resources will be prevented by Keystone RBAC policy enforcement. Diagram below shows how cloud admin can scope token to a project in leaf domain to manage its comuting resource.



Impact:
Most of the changes are scoped to Keystone only, apparently there is no change required to external (Nova, Swift, ....) services.


 * Domain model need to be extended to support notion of domain hierarchy.
 * Role subsystem will be impacted to handle hierarchical inherited roles.
 * Role evaluation subsystem will be impacted to handle hierarchical inherited roles.
 * Auth middle-ware and token validation has to be enhanced.
 * Domain API will be impacted to capture the domain hierarchy.