Introduction – OpenStack Identity

The OpenStack Identity service, known as Keystone , provides services for authenticating and managing user accounts and role information for our OpenStack cloud environment.

It is a crucial service that underpins the authentication and verification between all of our OpenStack cloud services and is the first service that needs to be installed within an OpenStack environment. The OpenStack Identity service authenticates users and projects by sending a validated authorization token between all OpenStack services. This token is passed to the other services, such as Storage and Compute, to grant user access to specific functionalities. Therefore, configuration of the OpenStack Identity service must be completed first before using any of the other services. Setting up of the Identity service involves the creation of appropriate roles for users and services, projects, the user accounts, and the service API endpoints that make up our cloud infrastructure. Since we are using Ansible for deploying our environment (refer to Chapter 1, Installing OpenStack with Ansible for more details), all the basic configuration is done for us in the Ansible playbooks.

In Keystone, we have the concepts of domains, projects, roles, users, and user groups. A Keystone domain (not to be confused with a DNS domain) is a high level OpenStack Identity resource that contains projects, users, and groups. A project has resources such as users, images, and instances, as well as networks in it that can be restricted only to that particular project, unless explicitly shared with others. A user can belong to one or more projects and is able to switch between them to gain access to those resources. Users within a project can have various roles assigned. Users can be organized into user groups and the groups can have roles assigned to them. In the most basic scenario, a user can be assigned either the role of admin or just be a member. When a user has admin privileges within a project, the admin is able to utilize features that can affect the project (such as modifying external networks), whereas a normal user is assigned the member role. This member role is generally assigned to perform user-related roles, such as spinning up instances, creating volumes, and creating isolated, project-specific networks.