Keystone, OpenStack’s identity service, catalogs all its services. It provides the ability to authenticate and manage user accounts, regions, domains, projects, and role information for the cloud environment. If you are familiar with the Microsoft Windows Server environment, you can think of Keystone as the “Active Directory analog” for your OpenStack cloud. Usually, Keystone is the first component to be installed when starting an OpenStack cloud. Keystone supports multiple forms of authentication, including login name and password, token-based credentials, Amazon Web Services, REST API logins, and many others.
A service is an OpenStack cloud component listed in the Keystone catalog. These services include Nova, Neutron, Glance, and Keystone. Service provides one or more endpoints through which users can access the service’s API.
- An endpoint is a URL from which the service is available. Service can have three endpoints: internal, public, and administration. They can have different subsets of API calls. An endpoint can look like this: https://controller.my-domain.com:8776/v3. Here, the service listens to incoming calls on port 8776, and the API is version 3. Common port numbers for OpenStack services are shown in Table 4-1. You can get a list of the endpoints for your OpenStack installation by executing the openstack catalog list command.Table 4-1
Common Port Numbers for OpenStack Services
Network Port Number
OpenStack Service
5000
Keystone’s public API endpoint port
35357
Keystone’s admin API endpoint port (can share 5000)
8776
Cinder block storage services
9292
Glance image services
8774
8778
Nova compute services
placement services
8080 and 6001–6003
Swift object storage services
9696
Neutron networking services
8042
8041
aodh telemetry alarming services
time series DB as a service
8004
Heat orchestration services
A project represents the base unit of ownership in OpenStack. Networks, VMs, users, roles, and so forth belong to a particular project. An special project “admin” exists for administrative operations in OpenStack. The second utility project is the “services” project.
A domain represents a collection of projects, groups, and users that defines administrative boundaries for managing OpenStack identity entities. In an initial OpenStack deployment, the only existing domain is the default domain.
A region separates the OpenStack environment with dedicated API endpoints but with a common Keystone service. In an initial OpenStack deployment, the only existing region is RegionOne.
A token is issued by Keystone service, then passed to API requests and used by OpenStack to verify that the client is authorized to run the requested operation. The token is issued for a limited time and, if necessary, may be withdrawn prior to the expiration. To get the user token, the user must either provide a name and password or the name and the key to access the API (API key). The token also contains a list of roles that defines the roles available to the user.
A user is an individual API consumer. Users can be associated with roles, projects, or both. In an initial OpenStack deployment, the only existing user account is admin, which is assigned to the admin role in the default domain’s admin project. The PackStack installation tool can create demo users with demo projects as well.
A role is a specific set of operations associated with a user. A role includes a set of rights and privileges.
From an architectural point of view, Keystone is the simplest service in the cloud. As for many other OpenStack services, the identity service uses the MariaDB/MySQL database. Alternatively, storing information in the LDAP (Lightweight Directory Access Protocol) server or Microsoft Active Directory is possible. Starting from the Mitaka release, Keystone uses the Apache web server as the front end, so you no longer need to start openstack-keystone.service. Prior to the Mitaka release, Keystone worked under the built-in Eventlet Python service by default.
In modern documents, the OpenStack community prefers to use the word project. In older documents, you can still find the word tenant. Keep in mind that project and tenant are synonymous.
Main Configuration Options for /etc/keystone/keystone.conf
Example of Config Options | Description |
---|---|
[DEFAULT] admin_token = ee224e8... | A “shared secret” that can be used to bootstrap and debug Keystone (This “token” does not represent a user.) |
[DEFAULT] debug = True | Sets logging level to DEBUG instead of default INFO level in a journal |
[DEFAULT] log_dir = /var/log/keystone | The base directory used for log files |
[database] connection = mysql://keystone_admin:password@ 192.168.122.10/keystone | The SQLAlchemy connection string to connect to the database |
[token] expiration = 3600 [ssl] Enable=False | Token validity timeframe (in seconds) (default–1 hour) Defines use of SSL connection |
Managing Keystone Catalog Services and Endpoints
You must repeat the command with two additional endpoints: internal and admin.
The command’s syntax changed in the Mitaka release. Do not be confused if you find examples where a single command created all three endpoints.
Managing/Creating Domains, Projects, Users, and Roles
If you skip the --domain option, the user is created at the default domain. If more than one project exists with the name apress, the command fails. You must add the --domain option to specify the domain.
The admin role is global, not per project, so granting a user the admin role in any project gives the user administrative rights across the whole environment.
As you can see, to create a region or domain in the identity service, you need an admin role. You get an HTTP 403 error code if the current policy doesn’t allow the command to be performed.
After creating a new user, you may want to create a new keystonerc file for it. You may use the keystonerc_admin file as a template. In this case, you need to change the OS_PROJECT_NAME, OS_USERNAME, and OS_PASSWORD variables.
Managing and Verifying the Operation of the Identity Service
Keystone supports the three access tokens: PKI tokens (deprecated), UUID, and Fernet tokens. The first two are non-persistent, lightweight, and reduce the operational overhead required to run a cloud. Fernet tokens don’t need to have the Memcached daemon run.
When debugging, you may want to check the logins using /var/log/httpd/keystone_* and /var/log/keystone/keystone.log.
Summary
This chapter discussed Keystone’s architecture and main components. You learned how to manage catalog services, endpoints, users, and domains.
The next chapter delves into image management.
Review Questions
- 1.Which of the following adds user apressuser with a member role to the only Apress project?
- A.
openstack role add --project apress --user apressuser _member_
- B.
openstack role add --project apress --user apressuser member
- C.
openstack role add --project apress --user _member_ apressuser
- D.
openstack role add --project apress --user member apressuser
- 2.Which system service should be started for proper Keystone functioning?
- A.
httpd
- B.
keystone-admin
- C.
memcached
- D.
keystone
- 3.How do you define a new role in the OpenStack cloud? (Choose all that are applicable.)
- A.
Enter the openstack role create newrole command.
- B.
Restart the httpd service.
- C.
Create a new keystonerc file.
- D.
Add a definition to the policy.json file.
- 4.How do you separate two or more cloud instances but manage them with one Keystone instance?
- A.
Use the Domains feature.
- B.
Use the Regions feature.
- C.
Use availability zones.
- D.
Each cloud instance should use its own Keystone instance feature.
- 5.Which HTTP error code do you get if the Keystone token has expired?
- A.
ERROR 404
- B.
ERROR 403
- C.
ERROR 401
- D.
All of them
Answers
- 1.
A
- 2.
D
- 3.
A
- 4.
A
- 5.
C