/usr/bin/keystone-manage

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.