# 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: ```shell-session $ vault secrets enable database Success! Enabled the database secrets engine at: database/ ``` List all secrets engines: ```shell-session $ 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: ```shell-session $ vault secrets move database/ db-prod/ Success! Moved secrets engine database/ to: db-prod/ ``` Tune a secrets engine: ```shell-session $ vault secrets tune -max-lease-ttl=30m db-prod/ Success! Tuned the secrets engine at: db-prod/ ``` Disable a secrets engine: ```shell-session $ vault secrets disable db-prod/ Success! Disabled the secrets engine (if it existed) at: db-prod/ ``` ### Usage ``` Usage: vault secrets [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/: ```shell-session $ 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. 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 the AWS secrets engine at "aws/": ```shell-session $ vault secrets enable aws Success! Enabled the aws secrets engine at: aws/ ``` Enable the SSH secrets engine at ssh-prod/: ```shell-session $ vault secrets enable -path=ssh-prod ss ``` Enable the database secrets engine with an explicit maximum TTL of 30m: ```shell-session $ vault secrets enable -max-lease-ttl=30m database ``` Enable a custom plugin (after it is registered in the plugin registry): ```shell-session $ 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: ```shell-session $ 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: ```shell-session $ 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/: ```shell-session $ 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/": ```shell-session $ 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: ```shell-session $ 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: ```shell-session $ 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.enclaive.cloud/vault/cli/secrets.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.