Please note: Mirantis has realigned its portfolio and renamed several products. These include Docker Enterprise Container Cloud (now Mirantis Container Cloud), Docker Enterprise/UCP (now Mirantis Kubernetes Engine), Docker Engine - Enterprise (now Mirantis Container Runtime), and Docker Trusted Registry (now Mirantis Secure Registry).

Mirantis Training Blog: What are OpenStack Keystone Domains?

Welcome to Mirantis Training’s monthly Q&A section. Here our instructors field questions about all aspects of OpenStack, and every month we’ll be sharing some of those answers with you here on the blog. If you have a question that you would like a Mirantis technical instructor to answer, feel free to post your comments in the section below. We will do our best to cover your question in next month’s post.

What are OpenStack Domains?

Domains in Keystone are abstract resources that were introduced in version 3 of the Keystone API. A domain is a collection of users and projects that exist within the OpenStack environment. To understand what this really means, it is crucial to understand how things work without domains.

Traditionally, the resource mapping could be summed up by saying that “a user has a role in a project”. The user is typically an individual that is communicating with the cloud services, submitting requests to provision and destroy infrastructure. A role is an arbitrary bit of metadata that is used to influence that user’s authority within the environment. The project is a container used to group and isolate resources from one another. With the original mapping model, when the admin role was applied to a user, the user would become a cloud administrator, rather than just a project administrator, as intended.

With domains, the resource mapping can be summed up by saying that a “domain is made up of users and projects, wherein users can have roles at the project and domain level.” With this model, it is now possible to have an admin user for an entire domain, allowing that user to manage resources such as users and projects for that particular domain, but a user might also have a role applied just for a particular project, which behaves much like it did in the previous model.

Some of the benefits to using domains are:

  • More fine grained Role Based Access Control (RBAC) capabilities
  • Creating cloud administrators with the ability to delegate tasks to users
  • Support for overlapping resource names such as usernames
  • The ability for separate organizations to leverage different backends. For example, one can be SQL based, while another can be LDAP based

How Do You Use OpenStack Keystone Domains?

In the Liberty release of OpenStack, the python-keystoneclient package was formally deprecated in favor of the unified python-openstackclient, which is capable of performing API operations to leverage domains.

You can create a domain:
$ openstack domain create <name>

You can list domains:
$ openstack domain list

Once your domains are created, you can create a user in an existing domain:
$ openstack user create –domain <name> –email <email> –password <pass> <username>

You can also create a project in a domain:
$ openstack project create –domain <name> –description <desc> <project_name>

To control access, you can assign a role to a user in a project:
$ openstack role add –project-domain <name> –project <project_name> –user <username>

Finally, you can delete a domain and all resources belonging to it:
$ openstack domain set –disable <name>
$ openstack domain delete <name>


Keystone domains provide OpenStack deployers with increased flexibility when dividing their environment into logical partitions that will be used by members of different departments of an organization or completely different organizations altogether. The resulting granularity in the authorization model provides a great mix of self-service capabilities while still ensuring isolation between users and their projects.

If you have additional questions about OpenStack, take a look at the OpenStack courses that Mirantis Training offers.


What's New in Kubernetes 1.18