Chapter 4. Identity and access management
The Identity service (keystone) provides authentication and authorization for cloud users in a Red Hat OpenStack Platform environment. You can use the Identity service for direct end-user authentication, or configure it to use external authentication methods to meet your security requirements or to match your current authentication infrastructure.
4.1. Red Hat OpenStack Platform fernet tokens
Fernet is the default token provider that replaces the
UUID token provider. Each fernet token remains valid for up to an hour, by default. This allows a user to perform a series of tasks without needing to reauthenticate.
After you authenticate, the Identity service (keystone):
- Issues an encrypted bearer token known as a fernet token. This token represents your identity.
- Authorizes you you to perform operations based on your role.
4.2. OpenStack Identity service entities
The Red Hat OpenStack Identity service (keystone) recognizes the following entities:
- OpenStack Identity service (keystone) users are the atomic unit of authentication. A user must be assigned a role on a project in order to authenticate.
- OpenStack Identity service groups are a logical grouping of users. A group can be provided access to projects under specific roles. Managing groups instead of users can simplify the management of roles.
- OpenStack Identity service roles define the OpenStack APIs that are accessible to users or groups who are assigned those roles.
- OpenStack Identity service projects are isolated groups of users who have common access to a shared quota of physical resources and the virtual infrastructure built from those physical resources.
- OpenStack Identity service domains are high-level security boundaries for projects, users, and groups. You can use OpenStack Identity domains to centrally manage all keystone-based identity components. Red Hat OpenStack Platform supports multiple domains. You can represent users of different domains by using separate authentication backends.
4.3. Authenticating with keystone
You can adjust the authentication security requirements required by OpenStack Identity service (keystone).
When you deploy Red Hat OpenStack Platform (RHOSP), it is possible to specify password requirements that are more complex than the default passwords that are generated for services. When this occurs, services cannot authenticate, and the deployment fails.
You must initially deploy RHOSP without password complexity requirements. After the deployment completes, add the
KeystonePasswordRegex parameter to your templates, and re-run the deployment.
To harden your environment, implement password complexity requirements that meet the standards of your organization. For information about NIST recommended password complexity requirements, see publication 88-63B, Appendix A.
Table 4.1. Identity service authentication parameters
| || |
Enabling this option requires users to change their password when the user is created, or upon administrative reset.
| || |
The maximum number of days a user can go without authenticating before being considered "inactive" and automatically disabled (locked).
| || |
The number of seconds a user account is locked when the maximum number of failed authentication attempts (as specified by
| || |
The maximum number of times that a user can fail to authenticate before the user account is locked for the number of seconds specified by
| || |
The number of days that a password must be used before the user can change it. This prevents users from changing their passwords immediately in order to wipe out their password history and reuse an old password.
| || |
The number of days for which a password is considered valid before requiring users to change it.
| || |
The regular expression that is used to validate password strength requirements.
| || |
Describe your password regular expression here in language for humans.
| || |
This controls the number of previous user password iterations to keep in history, in order to enforce that newly created passwords are unique.
4.3.1. Using Identity service heat parameters to stop invalid login attempts
Repetitive failed login attempts can be a sign of an attempted brute-force attack. You can use the Identity Service to limit access to accounts after repeated unsuccessful login attempts.
- You have an installed Red Hat OpenStack Platform director environment.
- You are logged into the director as stack.
To configure the maximum number of times that a user can fail to authenticate before the user account is locked, set the value of the
KeystoneLockoutDurationheat parameters in an environment file. In the following example, the
KeystoneLockoutDurationis set to one hour:
parameter_defaults KeystoneLockoutDuration: 3600 KeystoneLockoutFailureAttempts: 3
Include the environment file in your deploy script. When you run your deploy script on a previously deployed environment, it is updated with the additional parameters:
openstack overcloud deploy --templates \ ... -e keystone_config.yaml ...
4.4. Authenticating with external identity providers
You can use an external identity provider (IdP) to authenticate to OpenStack service providers (SP). SPs are the services provided by an OpenStack cloud.
When you use a separate IdP, external authentication credentials are separate from the databases used by other OpenStack services. This separation reduces the risk of a compromise of stored credentials.
Each external IdP has a one-to-one mapping to an OpenStack Identity service (keystone) domain. You can have multiple coexisting domains with Red Hat OpenStack Platform.
External authentication provides a way to use existing credentials to access resources in Red Hat OpenStack Platform without creating additional identities. The credential is maintained by the user’s IdP.
You can use IdPs such as Red Hat Identity Management (IdM), and Microsoft Active Directory Domain Services (AD DS) for identity management. In this configuration, the OpenStack Identity service has read-only access to the LDAP user database. The management of API access based on user or group role is performed by keystone. Roles are assigned to the LDAP accounts by using the OpenStack Identity service.
4.4.1. How LDAP integration works
In the diagram below, keystone uses an encrypted LDAPS connection to connect to an Active Directory Domain Controller. When a user logs in to horizon, keystone receives the supplied user credentials and passes them to Active Directory.