usage: keystone-manage [bootstrap|credential_migrate|credential_rotate|credential_setup|db_sync|db_version|doctor|domain_config_upload|fernet_rotate|fernet_setup|create_jws_keypair|mapping_populate|mapping_purge|mapping_engine|project_setup|receipt_rotate|receipt_setup|reset_last_active|saml_idp_metadata|token_rotate|token_setup|trust_flush|user_setup] options: -h, --help show this help message and exit --config-dir DIR Path to a config directory to pull `*.conf` files from. This file set is sorted, so as to provide a predictable parse order if individual options are over-ridden. The set is parsed after the file(s) specified via previous --config-file, arguments hence over-ridden options in the directory take precedence. This option must be set from the command-line. --config-file PATH Path to a config file to use. Multiple config files can be specified, with values in later files taking precedence. Defaults to None. This option must be set from the command-line. --debug, -d If set to true, the logging level will be set to DEBUG instead of the default INFO level. --log-config-append, --log-config, --log_config PATH The name of a logging configuration file. This file is appended to any existing logging configuration files. For details about logging configuration files, see the Python logging module documentation. Note that when logging configuration files are used then all logging configuration is set in the configuration file and other logging configuration options are ignored (for example, log-date-format). --log-date-format DATE_FORMAT Defines the format string for %(asctime)s in log records. Default: None . This option is ignored if log_config_append is set. --log-dir, --logdir LOG_DIR (Optional) The base directory used for relative log_file paths. This option is ignored if log_config_append is set. --log-file, --logfile PATH (Optional) Name of log file to send logging output to. If no default is set, logging will go to stderr as defined by use_stderr. This option is ignored if log_config_append is set. --nodebug The inverse of --debug --nouse-journal The inverse of --use-journal --nouse-json The inverse of --use-json --nouse-syslog The inverse of --use-syslog --shell_completion SHELL_COMPLETION Display a shell completion script Allowed values: bash, zsh --syslog-log-facility SYSLOG_LOG_FACILITY Syslog facility to receive log lines. This option is ignored if log_config_append is set. --use-journal Enable journald for logging. If running in a systemd environment you may wish to enable journal support. Doing so will use the journal native protocol which includes structured metadata in addition to log messages.This option is ignored if log_config_append is set. --use-json Use JSON formatting for logging. This option is ignored if log_config_append is set. --use-syslog Use syslog for logging. Existing syslog format is DEPRECATED and will be changed later to honor RFC5424. This option is ignored if log_config_append is set. --version show program's version number and exit Commands: {bootstrap,credential_migrate,credential_rotate,credential_setup,db_sync,db_version,doctor,domain_config_upload,fernet_rotate,fernet_setup,create_jws_keypair,mapping_populate,mapping_purge,mapping_engine,project_setup,receipt_rotate,receipt_setup,reset_last_active,saml_idp_metadata,token_rotate,token_setup,trust_flush,user_setup} Available commands bootstrap Perform the basic bootstrap process. credential_migrate Provides the ability to encrypt credentials using a new primary key. This assumes that there is already a credential key repository in place and that the database backend has been upgraded to at least the Newton schema. If the credential repository doesn't exist yet, you can use ``keystone- manage credential_setup`` to create one. credential_rotate Rotate Fernet encryption keys for credential encryption. This assumes you have already run `keystone-manage credential_setup`. A new primary key is placed into rotation only if all credentials are encrypted with the current primary key. If any credentials are encrypted with a secondary key the rotation will abort. This protects against removing a key that is still required to decrypt credentials. Once a key is removed from the repository, it is impossible to recover the original data without restoring from a backup external to keystone (more on backups below). To make sure all credentials are encrypted with the latest primary key, please see the `keystone-manage credential_migrate` command. Since the maximum number of keys in the credential repository is 3, once all credentials are encrypted with the latest primary key we can safely introduce a new primary key. All credentials will still be decryptable since they are all encrypted with the only secondary key in the repository. It is imperitive to understand the importance of backing up keys used to encrypt credentials. In the event keys are overrotated, applying a key repository from backup can help recover otherwise useless credentials. Persisting snapshots of the key repository in secure and encrypted source control, or a dedicated key management system are good examples of encryption key backups. The `keystone-manage credential_rotate` and `keystone-manage credential_migrate` commands are intended to be done in sequence. After performing a rotation, a migration must be done before performing another rotation. This ensures we don't over-rotate encryption keys. credential_setup Setup a Fernet key repository for credential encryption. The purpose of this command is very similar to `keystone-manage fernet_setup` only the keys included in this repository are for encrypting and decrypting credential secrets instead of token payloads. Keys can be rotated using `keystone-manage credential_rotate`. db_sync Sync the database. db_version Print the current migration version of the database. doctor Diagnose common problems with keystone deployments. domain_config_upload Upload the domain specific configuration files to the database. fernet_rotate Rotate Fernet encryption keys. This assumes you have already run keystone- manage fernet_setup. A new primary key is placed into rotation, which is used for new tokens. The old primary key is demoted to secondary, which can then still be used for validating tokens. Excess secondary keys (beyond [fernet_tokens] max_active_keys) are revoked. Revoked keys are permanently deleted. A new staged key will be created and used to validate tokens. The next time key rotation takes place, the staged key will be put into rotation as the primary key. Rotating keys too frequently, or with [fernet_tokens] max_active_keys set too low, will cause tokens to become invalid prior to their expiration. fernet_setup Setup key repositories for Fernet tokens and auth receipts. This also creates a primary key used for both creating and validating Fernet tokens and auth receipts. To improve security, you should rotate your keys (using keystone-manage fernet_rotate, for example). create_jws_keypair Create a key pair for signing and validating JWS tokens. This command creates a public and private key pair to use for signing and validating JWS token signatures. The key pair is written to the directory where the command is invoked. mapping_populate Pre-populate entries from domain-specific backends. Running this command is not required. It should only be run right after the LDAP was configured, when many new users were added, or when "mapping_purge" is run. This command will take a while to run. It is perfectly fine for it to run more than several minutes. mapping_purge Purge the mapping table. mapping_engine Execute mapping engine locally. project_setup Create project with specified UUID. receipt_rotate Rotate auth receipts encryption keys. This assumes you have already run keystone-manage receipt_setup. A new primary key is placed into rotation, which is used for new receipts. The old primary key is demoted to secondary, which can then still be used for validating receipts. Excess secondary keys (beyond [receipt] max_active_keys) are revoked. Revoked keys are permanently deleted. A new staged key will be created and used to validate receipts. The next time key rotation takes place, the staged key will be put into rotation as the primary key. Rotating keys too frequently, or with [receipt] max_active_keys set too low, will cause receipts to become invalid prior to their expiration. receipt_setup Setup a key repository for auth receipts. This also creates a primary key used for both creating and validating receipts. To improve security, you should rotate your keys (using keystone-manage receipt_rotate, for example). reset_last_active Reset null values for all users to current time. saml_idp_metadata Generate Identity Provider metadata. token_rotate Rotate token encryption keys. This assumes you have already run keystone- manage token_setup. A new primary key is placed into rotation, which is used for new tokens. The old primary key is demoted to secondary, which can then still be used for validating tokens. Excess secondary keys (beyond [token] max_active_keys) are revoked. Revoked keys are permanently deleted. A new staged key will be created and used to validate tokens. The next time key rotation takes place, the staged key will be put into rotation as the primary key. Rotating keys too frequently, or with [token] max_active_keys set too low, will cause tokens to become invalid prior to their expiration. token_setup Setup a key repository for tokens. This also creates a primary key used for both creating and validating tokens. To improve security, you should rotate your keys (using keystone-manage token_rotate, for example). trust_flush Flush expired and non-expired soft deleted trusts from the backend. user_setup Create user with specified UUID.