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:
Let's understand identity-related concepts that are used in Keystone.
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.
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
As shown in the figure, users can be a part of one or more projects.
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:
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.
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.