Chapter 2. Authentication and Authorization Using Keystone

Most of the OpenStack components have a basic in-built authentication mechanism, which is adequate for them to function on their own. However, when they have to come together, Keystone forms the bridge, a common platform for authentication and authorization.

Keystone was launched in the Essex release and has been deemed a core component of the OpenStack deployment ever since. In this chapter, we will understand in some detail the following:

  • The Keystone architecture and the subsystems
  • Installing the prerequisite common components
  • Installing Keystone
  • Initial configuration
  • Basic troubleshooting

Note

Please be advised that this will be installed and configured on the controller node.

The entire installation and configuration of common components and the core Keystone service takes between 60-90 minutes.

Identity concepts in Keystone

Let's understand identity-related concepts that are used in Keystone.

User

User represents a person or a service with a set of credentials such as a user name, password, or username and an API key. A user needs to be a member of at least one project, but can be a part of multiple projects.

Project (or tenant)

A group of users in OpenStack is called a project or a tenant. Both of these terms are used interchangeably and mean the same thing. Please be advised that tenant is the new terminology, and the term project has seeped in from the initial days when Keystone was not available. The policies and quotas are all applied at the project or the tenant level

Project (or tenant)

As shown in the figure, users can be a part of one or more projects.

Role

The role determines what the user is allowed to do. This is controlled by the policy subsystem of the Keystone service. The roles are defined in the policy.json file located at /etc/keystone/policy.json.

By default, there are only two roles that come with OpenStack:

  • admin
  • member

As the name implies, the admin role has all the privileges and a member comes with limited privileges. In a general deployment, these two are enough with most users being members.

Tip

Roles are associated with the users, and hence a user associated with an admin role is granted privileges across all the projects that the user is assigned to. Hence, please use the admin role carefully.

In order to assign a user to multiple projects, we will need to create a role and add it to the user project pair. We will see this in the later part of the book.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset