C
L
O
S
E

X

Cloud&Heat Technologies GmbH
Zeitenströmung – Halle 15
Königsbrücker Straße 96
01099 Dresden
Germany

+49 351 479 367 00

Please confirm you have read and understood our Privacy Policy.

Blog

Domains in OpenStack

9.03.2017 - by Stephan Vanecek

 

Domains in OpenStack is an abstract structure used to segregate administrative units inside a cloud environment. Domains functionality is a part of Identity service (Keystone) API V3 since Grizzly release.

Keystone is an identity service that provides authentication in OpenStack. The identity service has two main purposes — the first one is to set permissions and keep track of the activity of the particular users and the second one is to expose a service catalog of OpenStack services. Domains help with handling the first mentioned. Referring to domains, there are a few Keystone terms that should to be defined:

  • Domain: The role of domains is to create boundaries for management of Keystone entities. One’s cloud infrastructure can be divided into multiple domains. Domain is a container enabling an exclusive division of one’s cloud infrastructure in terms of access rights. Because of the exclusivity, they are independent of one another.
  • Project: Project (also called tenant in the past) is the fundamental unit for definition and ownership of the resources. It is a container used to group and isolate resources from one another. Projects logically divide the domains into smaller distinct units. Since the Identity API V3.4, the projects can have a hierarchical tree structure. In other words, it is possible to create a structure with child and parent projects. Since API V3.6, it is also possible to set a project to act as a domain (by setting the attribute is_domain to true). In fact, this means that domains can be understood as a specific type of projects. However, a project can be a domain only if its parent is also a domain.
  • User: The user is an individual that operates the resources he is given access to. Every user is owned by a domain/project. Therefore, a user is bound within a particular domain and can only access resources of domains and projects in given subtree.
  • Role: A role defines the right for the specific user to perform a particular API request. Roles map users and groups to projects or domains. In other words, roles specify, which users have the rights to perform which actions. As well as names of domains, roles are unique throughout the whole infrastructure. We can grant roles to users and groups in a project/domain. The roles are further inherited in the project’s/domain’s subtree.
  • Group: A group is a logical aggregation of users. It also belongs to a particular domain/project and is used to relate users that are supposed to have the same access rights. Its purpose is to make the administration easier and more transparent. Instead of mapping the same roles to multiple users, one can create a group and define the role for the whole group.

The main purpose of domains is increasing the modularity of the infrastructure in terms of allowing and restricting the access to the resources and creating distinct divisions between diverse environments. Domains and projects have a tree structure with domains on top and projects at the bottom. Within a domain, one can create users and projects, and grant roles. Having clarified the characteristics of domains, let’s explain a use case called “Reseller”.

Reseller model

The reseller model targets a need to create more levels of ownership which allow granting access to the infrastructure. The typical reseller model story includes an OpenStack infrastructure provider having a customer. The customer does not facilitate the whole computing capacity or simply has a marketing strategy of subletting parts of the infrastructure to other clients. For this strategy to work, the sublet infrastructure must feature the same qualities as the original one. Moreover, the clients must have no information about the infrastructure of other clients and must be assured that no other client can access their infrastructure. Being able to alter the resources of another customer is not acceptable.

This approach benefits from the characteristics of domains. With domains, the coexistence of multiple different entities subletting other customer’s resources is possible. One is able to resell a domain where creation of users and groups is enable. Since users and projects are bound within its parent domain/project, a customer managing his own domain is isolated there so that he cannot be affected by or affect other entities. Allowing the administrative infrastructure to be divided multi-tenant silos which are required for reselling.

The reseller modell allows service providers to diversify their offerings, this in turn helps them to enter a wider variety of market segments.

Conclusion

Domains help us to incorporate multiple layers of resource access and ownership in OpenStack. Therefore, the administrators are enabled to set up the infrastructure according to their needs. Domains contribute to this process by providing an isolated administrative environment with own users and projects that is independent from other domains.