Identity, Authentication, and Access Management in OpenStack

Introduction

Identity, Authentication, and Access Management Capabilities of Keystone

Cloud environments at the Infrastructure-as-a-Service layer (IaaS) provide users access to key resources such as virtual machine instances, large amounts of block and object storage, and network bandwidth. A critical feature of any cloud environment is how it provides secure, controlled access to these valuable resources. In OpenStack environments, the Keystone service is responsible for providing secure controlled access to all of the cloud’s resources. Keystone has proven itself to be a vital component for a secure cloud. As shown in Figure P-1, 90% to 95% of OpenStack users report that they utilize Keystone in their deployments.

Figure P-1. Percentage of deployments using Keystone and other OpenStack services (source)

In order to understand how Keystone provides secure and controlled access to OpenStack Cloud resources we need to examine Keystone’s fundamental capabilities for providing Identity, Authentication, and Access Management. The following sections provide short overviews of these core Keystone capabilities.

Identity

Identity refers to the identification of who is trying to access cloud resources. In OpenStack Keystone, identity is typically represented as a user. In simple deployments, the identity of a user can be stored in Keystone’s own database. In production or enterprise environments, an external Identity Provider is commonly used. An example of this is IBM’s Tivoli Federated Identity Manager. Keystone should be able to retrieve the user’s identity information from these external Identity Providers.

Authentication

Authentication is the process of validating a user’s identity. In many cases, authentication is initially performed by a user performing a login with their user identity and a password. In a very rudimentary OpenStack environment, Keystone is capable of performing all the authentication steps itself. This is not recommended for production or enterprise environments. For real environments where passwords need to be properly protected and managed, Keystone is pluggable such that it easily integrates with an existing hardened production authentication service, such as LDAP or Active Directory.

While a user identity is typically initially authenticated with a password, it is very common as part of this initial authentication to create a token for subsequent authentications. This reduces the amount of visibility and exposure of the password which needs to be kept hidden and protected as much as possible. Tokens also have a limited lifespan and expire so that their usefulness is limited if they are stolen. OpenStack relies heavily on tokens for authentication and other purposes—and Keystone is the one and only OpenStack service that can issue them. Currently, Keystone uses a form of token called a bearer token. This means that whomever has obtained ownership of the token, whether it be properly or improperly (i.e., stolen), is capable of using the token to authenticate and access resources. As a result, when using Keystone it is very important to protect tokens and their contents.

Access Management (Authorization)

Once a user identity has been authenticated and a token has been created and allocated, things start to get interesting. This is because we now have enough foundation in place to start performing Access Management. Access Management, also referred to as Authorization, is the process of determining what resources a user is permitted to access. Cloud environments such as OpenStack provide users with access to large amounts of resources. For example, there needs to be a mechanism for determining which users are allowed to create new instances of a particular virtual machine, which users are allowed to attach or delete a volume of block storage, which users are allowed to create virtual networks, etc. In OpenStack, Keystone maps Users to Projects or Domains by associating a Role for the User for that Project or Domain. Other OpenStack subprojects such as Nova, Cinder, and Neutron examine the User’s Project and Role associations and evaluate this information using a policy engine. The policy engine examines this information (particularly the Role value) and makes a determination about what actions the user is allowed to perform.

Keystone’s Primary Benefits

While Keystone is mostly focused on providing Identity, Authentication, and Access Management it does provide a large number of benefits for an OpenStack environment. Key benefits include the following:

• Single Authentication and Access Management interface for other OpenStack services. Keystone handles the complex tasks of integrating with external Authentication systems and also provides uniform Access Management for all the other OpenStack services, such as Nova, Glance, Cinder, Neutron, etc., and thus Keystone isolates all the other services from knowing how to talk to different identity and authorization providers.

• Keystone provides a registry of containers (“Projects”) that other OpenStack services can use to segregate resources (e.g., servers, images, etc.).

• Keystone provides a registry of Domains that are used to define separate namespaces for users, groups, and projects to allow segregation between customers.

• A registry of Roles that will be used for authorization between Keystone and the policy files of each of the OpenStack services.

• An assignment store allowing users and groups to be assigned roles on projects and domains.

• A catalog storing OpenStack services, endpoints, and regions, allowing clients to discover the service or endpoint they need.

The rest of the book is organized as follows. In Chapter 1, we provide an overview of Keystone’s fundamental constructs. Chapter 2 provides the reader with an instructional tutorial for interacting with Keystone to invoke its core operational capabilities. In Chapter 3 we provide extensive coverage of the variety of token formats supported by Keystone and highlight the advantages and disadvantages of each format as well describing how each can be configured and utilized. Chapter 4 provides in-depth coverage of how to integrate Keystone with an LDAP Identity Provider. Chapter 5 describes Keystone’s approach to federation and illustrates how to integrate Keystone with a federated identity provider. Finally, in Chapter 6 we conclude with a discussion of areas for future improvement of Keystone.