The Identity component Keystone
This content is part # of # in the series: Discover OpenStack
This content is part of the series:Discover OpenStack
Stay tuned for additional content in this series.
This article describes OpenStack Identity, which offers a common means of authentication for all the other OpenStack projects.
Every multiuser service needs some mechanism to manage who can access the application and which actions each person can perform. A private cloud is no exception and OpenStack has streamlined these functions into a separate project called Keystone.
Keystone is the project name for OpenStack Identity, a service that provides token, policy, and catalog functions via an OpenStack application programming interface (API). As is the case with other OpenStack projects, Keystone represents an abstraction layer. It doesn't actually implement any user-management functions; rather, it provides plug-in interfaces so that organizations can leverage their current authentication services or choose from a variety of identity management systems that are on the market.
Keystone integrates the OpenStack functions for authentication, policy management, and catalog services, including registering all tenants and users, authenticating users and granting tokens for authorization, creating policies that span all users and services, and managing a catalog of service endpoints. The core object of an identity-management system is the user — a digital representation of a person, system, or service using OpenStack services. Users are often assigned to containers called tenants, which isolate resources and identity objects. A tenant can represent a customer, account, or any organizational unit.
Authentication is the process of establishing who a user is. Keystone confirms that any incoming functional call originates from the user who claims to be making the request. It performs this validation by testing a set of claims which take the form of credentials. The distinguishing feature of credential data is that it should only be accessible to the user who owns the data. It can consist of data only the user knows (user name and password or key), something the user physically possesses (a hardware token), or something the user "is" (biometric data like an iris scan or fingerprint).
After OpenStack Identity has confirmed the user's identity, it provides the user with a token that corroborates that identity and can be used for subsequent resource requests. Each token includes a scope that lists the resources to which it apples. The token is valid only for a finite duration and can be revoked if there is a need to remove a particular user's access.
Security policies are enforced with a rule-based authorization engine. After a user has been authenticated, the next step is to determine the level of authorization. Keystone encapsulates a set of rights and privileges with a notion called a role. The tokens that the identity service issues include a list of roles that the authenticated user can assume. It is then up to the resource service to match the set of user roles with the requested set of resource operations and either grant or deny access.
One additional service of Keystone is the service catalog used for end point discovery. This catalog provides a listing of available services along with their API end points. An end point is a network-accessible address, such as a URL, from which a user can consume a service. All of the OpenStack services, including OpenStack Compute (Nova) and OpenStack Object Storage (Swift) supply end points to Keystone through which users can request resources and perform operations.
Architecturally, Keystone is simple. It processes all the API requests, providing Identity, Token, Catalog, and Policy services. It is organized as a group of front-end services exposed via the API network:
- The Identity service validates authentication credentials and supplies any associated metadata.
- The Token service verifies and administers tokens used for authenticating requests after a user's credentials have been verified.
- The Catalog service provides a service registry that can be used for end point discovery.
- The Policy service exposes a rule-based authorization engine.
Each Keystone function supports back-end plug-ins for integration into heterogeneous environments and to expose diverse functionality. Some of the more common back ends include:
- Key Value Store. An interface supporting primary key lookups, such as an in-memory dictionary.
- Memcached. Distributed memory caching system
- Structured Query Language (SQL). Uses SQLAlchemy (a Python SQL toolkit and Object Relational Mapper) to store data persistently
- Pluggable Authentication Module (PAM). Uses the local system's PAM service to authenticate
- Lightweight Directory Access Protocol (LDAP). Connects via the LDAP to a back-end directory, such as Active Directory®, to authenticate users and obtain role information
Setting it up
The actual installation instructions vary greatly between distributions and OpenStack releases. Generally, they are available as part of the distribution. Nonetheless, the same basic tasks must be completed. This section gives you an idea of what's involved.
OpenStack relies on a 64-bit x86 architecture; otherwise, it's designed for commodity hardware, so the minimal system requirements are modest. It is possible to run the entire suite of OpenStack projects on a single system with 8GB of RAM. For slightly larger installations, it's possible to co-locate the Keystone service with other projects, such as the Nova controller. However, for highly scalable implementations, it's better to use a dedicated system for identity management. A good starting point for a simple system is a quad-core CPU with 32GB of RAM and two Gbit network adapters.
The installation instructions depend on the distribution and, more
specifically, on the package-management utility you select. In many cases,
it's necessary to declare the repository. So, for example, in the case of
Zypper, you announce to
# zypper ar -f http://download.opensuse.org/repositories/Cloud:/OpenStack:/Grizzly/SLE_11_SP3/Cloud:OpenStack:Grizzly.repo
You then install the required Keystone packages and the package-management utility should automatically install any dependencies. The full installation procedure depends on the desired configuration and the exact release of OpenStack in question. Be sure to look at the installation guide for authoritative instructions. For the purpose of illustration, below are the primary commands for Debian (for example, Ubuntu), Red Hat (Red Hat Enterprise Linux®, CentOS, Fedora), and openSUSE:
- Debian. To install Keystone on a Debian-based system
such as Ubuntu, use the following command:
sudo apt-get install keystone sudo apt-get install python-keystone sudo apt-get install python-keystoneclient
- Red Hat. On Red Hat systems, the commands are:
sudo yum install openstack-keystone sudo yum install python-keystone sudo yum install python-keystoneclient
- openSUSE. Use the following commands:
sudo zypper install openstack-keystone sudo zypper install python-keystoneclient
The primary Keystone configuration file is keystone.conf which resides in
/etc/keystone/. It identifies all the authentication plug-ins specified in
methods. Lists all the authentication plug-in names
<plugin name>. Specify the class for each of the authentication methods
[auth] methods = password,token,oauth1 password = keystone.auth.plugins.password.Password token = keystone.auth.plugins.token.Token oauth1 = keystone.auth.plugins.oauth1.OAuth
No standard mechanism exists for the plug-in to register its own configuration options, but it is common for it to have its own section in the configuration file.
Many organizations are moving toward Public Key Infrastructure because it is a highly scalable, standards-based technology. One of its benefits is that it allows delegated trust which is vital for identity federation but also means that it is necessary to demonstrate authenticity through a tamper-proof link to a recognized and trusted certification authority (CA).
In practice, this means that the public key must be signed with a
CA-certified X.509 certificate. For a purely internal implementation, it's
possible to use
keystone-manage to generate a self-signed
certificate, but in a federated environment, a certificate from an
external CA may be required.
Installing a certificate issued by an external CA involves:
- Requesting a signing certificate from the external CA
- Converting both the certificate and the private key to Privacy Enhanced Email (PEM) format
- Installing the external signing certificate by copying the .pem files to the certificate directory
Identity management is a supporting function that serves a less tangible purpose than most of the other OpenStack projects. It should be seen as an enabler that simplifies service discovery and provides a unified means of enforcing security policies.
It is perhaps easiest to visualize its use by dividing it into two parts. Administrative functions in Keystone define users and projects and assign the appropriate authorization. When the environment has been configured, the projects and applications can interface with Keystone to perform queries and verify access controls.
Let's start with the first part, which is easier to follow because it's mapped to the Horizon dashboard. An administrator can create projects and users. The users can be assigned roles and aggregated into groups to simplify management.
- The first step is typically to create a project. Log in to OpenStack
Dashboard as an administrator. In the navigation pane, beneath
Identify Panel, click Projects > Create
Figure 1. Create a new project
- You don't need anything other than the name and description at this
point. You also need at least one user. Beneath Identity Panel, click
Users > Create User.
Figure 2. Create a user
- Edit the project. Beneath Identity Panel, click
Projects > Edit Project.
Figure 3. Edit the project
- In the Edit Project window, on the Project Members tab, you can edit
the project members and change their roles.
Figure 4. Edit the project members and their roles
- You can also use the Quota tab to specify limits for the project. This
is particularly useful in a multitenant environment to ensure that one
project doesn't use excessive resources and starve other critical
services running on the same infrastructure.
Figure 5. Specify limits for the project
The second part of the scenario is the authentication of services at execution time. Consider, for example, an application that uses OpenStack Swift for object storage. Regardless of whether it is running as part of an OpenStack compute instance, it must be able to authenticate which means that it needs access to valid credentials.
The application first needs to connect to the authentication service and supply its credentials. It then receives an authentication token that it can pass to OpenStack Object Storage for all container and object operations. In some cases, the application may not be preconfigured with all the connection parameters. It can obtain these parameters from Keystone, as well. For example, it can query Keystone to discover which projects it can access and request the URL of the service it requires.
User management is not difficult as long as you stick to the Horizon user interface. It hides the internal processes as well as any necessary integration with other user repositories, such as Active Directory, or any LDAP directory.
- Read more OpenStack articles in this series.
- Check out the OpenStack documentation.
- Keep up with OpenStack on Twitter.
- Read about IBM's open cloud architecture.
- Try SoftLayer cloud server free for one month.
- Try OpenStack for yourself.