Reseller Use Case
OpenStack needs to grow support for hierarchical ownership of objects.
This enables the management of subsets of users and projects in a way that is
much more comfortable for private clouds, besides giving to public cloud
providers the option of reselling a piece of their cloud.
Use Case 1:
- Alex - Cloud Owner
- Martha - Owner of ProductionIT
- Joe - Development Manager from WidgetMaster
- Sam - Development Manager from SuperDevShop
Alex is a owner of a cloud and Martha provides IT services to multiple
enterprise clients using resources that she bought from Alex. She would like to
offer cloud services to Joe at WidgetMaster, and Sam at SuperDevShop. Joe and
Sam have multiple QA and Development teams with many users. They need the
ability to create users, groups, projects, and quotas as well as the ability to
list and delete resources across their enterprises. Martha needs to be able to
set the quotas for both WidgetMaster and SuperDevShop. She also needs to ensure
that Joe and Sam cannot see or manipulate anything owned by each other.
Implement support to allow users/groups to be owned at more than just by a top
level domain. To achieve this, the domains construct will be merged with the
projects ones, since we already have a project’s hierarchy, this merge will
allow the possibility to have also a domain hierarchy to distribute users and
groups not just in a global entity. With this implementation, we’ll cover the
Reseller use case, where one will be able to resell both a project and a
project that behaves like a domain, where one can create users and groups.
We will take following steps in order to enable such feature:
- A new field will be added to the project table to represent if that project
has the domain feature (is_domain flag).
- An sql migration will take the following steps:
- ** Create, for each entry in the domain table, an entry in the project table
- where the domain’s id becomes project_id in the project table with
the is_domain flag set to true
- ** Initialize the parent_id as for any other projects that do not have
- parent_id set to match their domain_id
- ** Ceate a USER-PROJECT and a GROUP-PROJECT role assignment for each
- USER-DOMAIN/GROUP-DOMAIN existing
** Delete all domain assignments.
** Drop the domain table
- We are going to add the parent_id query parameter for both GET v3/domains
and v3/projects APIs. If it is not specified, these requests should return
only a list of root domains or projects.
It is also important to note the following rules/restrictions:
- A project with the “is_domain” flag set to “true” can only be either a root
project or a child project to a project who also have the “is_domain” flag
set to “true”. Moreover, the “is_domain” flag is immutable.
- Regarding role assignments management, it will be possible to use the
inherited role assignments to manage the grants between user/groups and the
project hierarchy. For example, following the use case described in the
previous session: by default, Martha or Alex can neither see nor manipulate
the resources owned by Sam and Joe, unless she either explicitly has a role
assignment in their domains or has an inherited role assignment in
ProductionIT. In the same way Joe and Sam can not see anything owned by
Martha unless she gives them a role on her domain.
- Note that today we can use the current role assignments mechanism to grant
roles in the hierarchy for users and groups, for a better usability to manage
the access control for the users and groups, we recommend the use of
inherited roles assignments implementation, so you can grant a role to a
user/group in a project/domain and inherit this assignment along the subtree.
In addition, there is a spec
related to domain roles, that can improve this role management in
Hierarchical Multitenancy. It is important to observe that the current
implementation of inherited role assignments consider only projects, role
assignments won’t be inherited in a domain hierarchy.
- Creating a new non-root domain will be possible via both domains and
projects APIs: POST v3/domains (create domain passing a parent_id from an
existing domain) and POST v3/projects with the is_domain flag enabled and
passing a parent_id from an existing domain.
- In this version, we will not allow to update a project to behave as a domain.
Other End User Impact
Python-keystoneclient must support creating projects that behave as a domain.
Other Deployer Impact
- When a user requests a domain scoped token, Keystone will send a dual scoped
token for domain and project.
Raildo Mascena <raildo>
Andrey Brito <abrito>
Henrique Truta <henriquetruta>
Rodrigo Duarte Sousa <rodrigodsousa>
- “Domain is a project”: Create a is_domain flag in the Project table to
represent a domain;
- Implement the parent_id query param for the list domains and list
projects v3 API calls;
- Migrate the current domain construct to the project table;
- When a domain scoped token is requested for a project with the is_domain
flag active, a dual scoped token will be provided, referencing the project
which holds that domain - we will have a single entry in the role
assignments table with a USER_PROJECT or GROUP_PROJECT type.
Note that we can have more than one domain or project with the same name
so if one wants to request a token passing the entity name, would be
necessary to pass the full namespace of that entity, for example considering
the following hierarchy:
To request a token for B, child of C (not the child of A), the token request
would need to have the full hierarchy information.
The character ‘/’ won’t be allowed to be part of a domain or project name, if
an entity already has this character in its name, this specific entity won’t
be allowed to be part of a hierarchy. The name would need to be updated in
order to remove the ‘/’.
- Create a constraint to ensure that the parent of a domain will always be
another domain (in other words: ensure that we won’t a create a domain under
- Make the is_domain property immutable once it is enabled.
The Identity API v3 Documentation must be updated according to these changes.