The keystone charm’s
password-security-compliance configuration option sets
[security_compliance] section of Keystone’s configuration file. The
value of this option is a YAML dictionary that includes support for the
following keys (value formats and units are also included).
change_password_upon_first_use: <boolean> disable_user_account_days_inactive: <int> (days) lockout_duration: <int> (seconds) lockout_failure_attempts: <int> minimum_password_age: <int> (days) password_expires_days: <int> (days) password_regex: <string> password_regex_description: <string> unique_last_password_count: <int>
The upstream document Security compliance and PCI-DSS should be consulted before setting any of these options.
The configuration is typically contained within a file, say
password-security-compliance: change_password_upon_first_use: True lockout_duration: 1800 lockout_failure_attempts: 3 ...
It is applied in the usual way:
juju config keystone --file config.yaml
The charm will protect service accounts (accounts requested by other units that are in the service domain) against being forced to change their password. Operators should also ensure that any other accounts are protected as per the above referenced note.
Operators should also ensure that any non-service accounts are protected as per the upstream document.
The charm will enter a blocked state if the value of charm option
password-security-compliance is not in valid YAML format and/or the
individual service options do not conform to the proper value formats.
Over time OpenStack has come to support two Keystone token formats: UUID and Fernet.
Fernet tokens were added to address the issue of size observed with PKI and PKIZ tokens in addition to continuing the Keystone behaviour of persisting tokens to a common database cluster (like UUID tokens). For more information see this Fernet FAQ.
Starting with OpenStack Rocky, only the Fernet format for authentication tokens is supported. This is documented on the Upgrade: Queens to Rocky page.
Theory of operation¶
Keystone generates Fernet keys, which in turn are used to generate/encrypt and decode/decrypt Fernet tokens.
There are three key types, and each is associated with a naming scheme that is applied to the directories in which they are found. Directory names are based on integers:
- primary key
integer: the highest one
number of keys: one
- staged key
will become the next primary key
can decode tokens
number of keys: one
- secondary key
integer: any other number
was previously a primary key
can decode tokens
number of keys: one or more
Each key type must be present at all times. This means Keystone uses a minimum of three keys.
Key rotation refers to the process by which two keys assume a different type, one key gets created, and typically one key gets removed:
staged → primary
primary → secondary
the staged is created
a secondary is removed
A key will get removed if the total number of keys surpasses the specified maximum allowed (more on this later).
This process takes place on the master keystone unit and takes into account three aspects:
maximum number of active keys
These are related according to this formula:
In the keystone charm, token expiration and the maximum number of active keys
are specified, respectively, with the
token-expiration and the
fernet-max-active-keys configuration options.
For example, given that an administrator desires a token expiration of 1 hour (3600 seconds) and a rotation frequency of 15 minutes (900 seconds), the maximum number of active keys must be six:
The above two options can then be set accordingly:
token-expiration: 3600 fernet-max-active-keys: 6
From the point of view of rotation frequency:
Since the denominator must lead to a positive real number for rotation
frequency the value of
fernet-max-active-keys must be at least three, and
this constraint is enforced by the charm.
To increase rotation frequency either decrease
token-expiration. To decrease rotation frequency, do the opposite.
The most notable effect of increasing rotation frequency is the reduction in key lifetime (secondary keys get removed more often).
These are the default values for these keystone charm options and the resulting default rotation frequency:
token-expiration: 3600 sec (1 hour)
rotation frequency: 3600 sec (1 hour)
Token validation breakage¶
Token validation breakage is a situation in which a decoding key is no longer available to validate an unexpired token. This can be caused by a rotation frequency that has been set too high (a very short key lifetime) or by keys failing to synchronise (from the master keystone unit to the other units) prior to the succeeding rotation. Incremental changes to rotation frequency is therefore advised.