»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/":

$ vault secrets enable aws
Success! Enabled 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 ssh

$ vault secrets enable -path=ssh-prod ssh

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

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

$ 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

$ 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.