secrets

The secrets command groups subcommands for interacting with Vault's secrets engines. Each secrets engine behaves differently. Please see the documentation for more information.

Some secrets engines persist data, some act as data pass-through, and some generate dynamic credentials. The secrets engine will likely require configuration after it is mounted. For details on the specific configuration options, please see the secrets engine documentation.

Examples

Enable a secrets engine:

$ vault secrets enable database
Success! Enabled the database secrets engine at: database/

List all secrets engines:

$ vault secrets list
Path          Type         Description
----          ----         -----------
cubbyhole/    cubbyhole    per-token private secret storage
database/     database     n/a
secret/       kv           key/value secret storage
sys/          system       system endpoints used for control, policy and debugging

Move a secrets engine to a new path:

$ vault secrets move database/ db-prod/
Success! Moved secrets engine database/ to: db-prod/

Tune a secrets engine:

$ vault secrets tune -max-lease-ttl=30m db-prod/
Success! Tuned the secrets engine at: db-prod/

Disable a secrets engine:

$ vault secrets disable db-prod/
Success! Disabled the secrets engine (if it existed) at: db-prod/

Usage

Usage: vault secrets <subcommand> [options] [args]

  # ...

Subcommands:
    disable    Disable a secrets engine
    enable     Enable a secrets engine
    list       List enabled secrets engines
    move       Move a secrets engine to a new path
    tune       Tune a secrets engine configuration

For more information, examples, and usage about a subcommand, click on the name of the subcommand in the sidebar.

secrets disable

The secrets disable command disables an secrets engine at a given PATH. The argument corresponds to the enabled PATH of the engine, not the TYPE! All secrets created by this engine are revoked and its Vault data is removed.

When a secrets engine is disabled, all secrets generated via the secrets engine are immediately revoked. Care should be taken when disabling a secret mount with a large number of secrets, as it can cause a high load on the system during revocation time.

Examples

Disable the secrets engine enabled at aws/:

$ vault secrets disable aws/

Usage

There are no flags beyond the standard set of flags included on all commands.

Force disable

Because secrets disable revokes secrets associated with this mount, possible errors can prevent the secrets engine from being disabled if the revocation fails.

The best way to resolve this is to figure out the underlying issue and then disable the secrets engine once the underlying issue is resolved. Often, this can be as simple as increasing the timeout (in the event of timeout errors).

For recovery situations where the secret was manually removed from the secrets backing service, one can force a secrets engine disable in Vault by performing a prefix force revoke on the mount prefix, followed by a secrets disable when that completes. If the underlying secrets were not manually cleaned up, this method might result in dangling credentials. This is meant for extreme circumstances.

secrets enable

The secrets enable command enables an secrets engine at a given path. If an secrets engine already exists at the given path, an error is returned. After the secrets engine is enabled, it usually needs configuration. The configuration varies by secrets engine.

By default, secrets engines are enabled at the path corresponding to their TYPE, but users can customize the path using the -path option.

Examples

Enable the AWS secrets engine at "aws/":

$ vault secrets enable aws
Success! Enabled the aws secrets engine at: aws/

Enable the SSH secrets engine at ssh-prod/:

$ vault secrets enable -path=ssh-prod ss

Enable the database secrets engine with an explicit maximum TTL of 30m:

$ vault secrets enable -max-lease-ttl=30m database

Enable a custom plugin (after it is registered in the plugin registry):

$ vault secrets enable -path=my-secrets my-plugin

For more information on the specific configuration options and paths, please see the secrets engine documentation.

Usage

The following flags are available in addition to the standard set of flags included on all commands.

-audit-non-hmac-request-keys (string: "") - Key that will not be HMAC'd by audit devices in the request data object. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key. An example of this is provided in the tune section.
-audit-non-hmac-response-keys (string: "") - Key that will not be HMAC'd by audit devices in the response data object. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key.
-default-lease-ttl (duration: "") - The default lease TTL for this secrets engine. If unspecified, this defaults to the Vault server's globally configured default lease TTL.
-description (string: "") - Human-friendly description for the purpose of this engine.
-force-no-cache (bool: false) - Force the secrets engine to disable caching. If unspecified, this defaults to the Vault server's globally configured cache settings. This does not affect caching of the underlying encrypted data storage.
-local (bool: false) - Mark the secrets engine as local-only. Local engines are not replicated or removed by replication.
-max-lease-ttl (duration: "") The maximum lease TTL for this secrets engine. If unspecified, this defaults to the Vault server's globally configured maximum lease TTL.
-path (string: "") Place where the secrets engine will be accessible. This must be unique cross all secrets engines. This defaults to the "type" of the secrets engine.
Case-sensitive: The path where you enable secrets engines is case-sensitive. For example, the KV secrets engine enabled at kv/ and KV/ are treated as two distinct instances of KV secrets engine.
-passthrough-request-headers (string: "") - request header values that will be sent to the secrets engine. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key.
-allowed-response-headers (string: "") - response header values that the secrets engine will be allowed to set. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key.
-allowed-managed-keys (string: "") - Managed key name(s) that the mount in question is allowed to access. Note that multiple keys may be specified either by providing the key names as a comma separated string or by providing this option multiple times, each time with 1 key.
-plugin-version (string: "") - Configures the semantic version of the plugin to use. If unspecified, implies the built-in or any matching unversioned plugin that may have been registered.

secrets list

The secrets list command lists the enabled secrets engines on the Vault server. This command also outputs information about the enabled path including configured TTLs and human-friendly descriptions. A TTL of "system" indicates that the system default is in use.

Deprecation status column

All built-in secrets engines have an associated Deprecation Status. This status will be reflected in the Deprecation Status column, seen below. All secrets engines which are not provided by built-in plugins will show a Deprecation Status of "n/a".

Version columns

The -detailed view displays some version information for each mount.

The Version field indicates the configured version for the plugin. Empty, or "n/a", indicates the built-in or any matching unversioned plugin that may have been registered.

Running Version indicates the actual plugin version running, which may differ from Version if the plugin hasn't been reloaded since the configured version was updated using the secrets tune command. Finally, the Running SHA256 field indicates the SHA256 sum of the running plugin's binary. This may be different from the SHA256 registered in the catalog if the plugin hasn't been reloaded since the plugin version was overwritten in the catalog.

Examples

List all enabled secrets engines:

$ vault secrets list
Path          Type         Accessor              Description
----          ----         --------              -----------
cubbyhole/    cubbyhole    cubbyhole_548b4dc5    per-token private secret storage
secret/       kv           identity_aa00c06d     key/value secret storage
sys/          system       system_547412e3       system endpoints used for control, policy and debugging

List all enabled secrets engines with detailed output:

$ vault secrets list -detailed
Path           Plugin        Accessor               Default TTL    Max TTL    Force No Cache    Replication    Seal Wrap    External Entropy Access    Options    Description                                                UUID                                  Version    Running Version          Running SHA256    Deprecation Status
----           ------        --------               -----------    -------    --------------    -----------    ---------    -----------------------    -------    -----------                                                ----                                  -------    ---------------          --------------    ------------------
cubbyhole/     cubbyhole     cubbyhole_b16d1bc0     n/a            n/a        false             local          false        false                      map[]      per-token private secret storage                           8c64d56b-9d46-d667-1155-a8c1a83a5d01  n/a        v1.12.0+builtin.vault    n/a               n/a
identity/      identity      identity_3d67c936      system         system     false             replicated     false        false                      map[]      identity store                                             5aa1e59c-33b5-9dec-05d6-c80c9a800557  n/a        v1.12.0+builtin.vault    n/a               n/a
postgresql/    postgresql    postgresql_f0a54308    system         system     false             replicated     false        false                      map[]      n/a                                                        8cdc1d2d-0713-eaa6-17e3-49790a60650b  n/a        v1.12.0+builtin.vault    n/a               deprecated
sys/           system        system_c86bd362        n/a            n/a        false             replicated     true         false                      map[]      system endpoints used for control, policy and debugging    e3193999-0875-d38d-3458-21d9f2762c80  n/a        v1.12.0+builtin.vault    n/a               n/a

Usage

The following flags are available in addition to the standard set of flags included on all commands.

Output options

-format (string: "table") - Print the output in the given format. Valid formats are "table", "json", or "yaml". This can also be specified via the VAULT_FORMAT environment variable.

Command options

-detailed (bool: false) - Print detailed information such as configuration and replication status about each secrets engine.

secrets move

The secrets move command moves an existing secrets engine to a new path. Any leases from the old secrets engine are revoked, but all configuration associated with the engine is preserved. The command can be issued for a move within or across namespaces, using namespace prefixes in the arguments.

The command will trigger a remount operation and uses the returned migration ID to poll the status of the operation until a terminal state of success or failure is reached.

Moving an existing secrets engine will revoke any leases from the old engine.

Examples

Move the existing secrets engine at ns1/secret/ to ns2/kv/:

$ vault secrets move ns1/secret/ ns2/kv/

Usage

There are no flags beyond the standard set of flags included on all commands.

secrets tune

The secrets tune command tunes the configuration options for the secrets engine at the given PATH. The argument corresponds to the PATH where the secrets engine is enabled, not the type.

Examples

Before tuning the secret mount, view the current configuration of the mount enabled at "pki/":

$ vault read sys/mounts/pki/tune
Key                             Value
---                             -----
default_lease_ttl               12h
description                     Example PKI mount
force_no_cache                  false
max_lease_ttl                   24h

Tune the default lease, exclude common_name and serial_number from being HMAC'd in the audit log for the PKI secrets engine:

$ vault secrets tune -default-lease-ttl=18h -audit-non-hmac-request-keys=common_name -audit-non-hmac-response-keys=serial_number pki/
Success! Tuned the secrets engine at: pki/

$ vault read sys/mounts/pki/tune
Key                             Value
---                             -----
audit_non_hmac_request_keys     [common_name]
audit_non_hmac_response_keys    [serial_number]
default_lease_ttl               18h
description                     Example PKI mount
force_no_cache                  false
max_lease_ttl                   24h

Specify multiple audit non-hmac request keys:

$ vault secrets tune -audit-non-hmac-request-keys=common_name -audit-non-hmac-request-keys=ttl pki/

Usage

The following flags are available in addition to the standard set of flags included on all commands.

-allowed-response-headers (string: "") - response header values that the secrets engine will be allowed to set. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key.
-audit-non-hmac-request-keys (string: "") - Key that will not be HMAC'd by audit devices in the request data object. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key.
-audit-non-hmac-response-keys (string: "") - Key that will not be HMAC'd by audit devices in the response data object. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key.
-default-lease-ttl (duration: "") - The default lease TTL for this secrets engine. If unspecified, this defaults to the Vault server's globally configured default lease TTL, or a previously configured value for the secrets engine. Uses duration format strings.
-description (string: "") - Specifies the description of the mount. This overrides the current stored value, if any.
-listing-visibility (string: "") - The flag to toggle whether to show the mount in the UI-specific listing endpoint. Valid values are "unauth" or "hidden". Passing empty string leaves the current setting unchanged.
-max-lease-ttl (duration: "") - The maximum lease TTL for this secrets engine. If unspecified, this defaults to the Vault server's globally configured maximum lease TTL, or a previously configured value for the secrets engine. This value is allowed to override the server's global max TTL; it can be longer or shorter. Uses duration format strings.
-passthrough-request-headers (string: "") - request header values that will be sent to the secrets engine. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key.
-allowed-managed-keys (string: "") - Managed key name(s) that the mount in question is allowed to access. Note that multiple keys may be specified either by providing the key names as a comma separated string or by providing this option multiple times, each time with 1 key.
-plugin-version (string: "") - Configures the semantic version of the plugin to use. The new version will not start running until the mount is reloaded.

Previousread Nextserver

Last updated 7 months ago