KV secrets engine - version 1
The kv
secrets engine is used to store arbitrary secrets within the
configured physical storage for Vault.
Writing to a key in the kv
backend will replace the old value; sub-fields are
not merged together.
Key names must always be strings. If you write non-string values directly via the CLI, they will be converted into strings. However, you can preserve non-string values by writing the key/value pairs to Vault from a JSON file or using the HTTP API.
This secrets engine honors the distinction between the create
and update
capabilities inside ACL policies.
Note: Path and key names are not obfuscated or encrypted; only the values set on keys are. You should not store sensitive information as part of a secret's path.
Setup
To enable a version 1 kv store:
Usage
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials. The kv
secrets engine
allows for writing keys with arbitrary values.
Write arbitrary data:
Read arbitrary data:
List the keys:
Delete a key:
You can also use Vault's password policy feature to generate arbitrary values.
Write a password policy:
Write data using the
example
policy:Read the generated data:
TTLs
Unlike other secrets engines, the KV secrets engine does not enforce TTLs
for expiration. Instead, the lease_duration
is a hint for how often consumers
should check back for a new value.
If provided a key of ttl
, the KV secrets engine will utilize this value
as the lease duration:
Even with a ttl
set, the secrets engine never removes data on its own. The
ttl
key is merely advisory.
When reading a value with a ttl
, both the ttl
key and the refresh interval
will reflect the value:
Tutorial
Refer to the Static Secrets: Key/Value Secrets Engine tutorial to learn how to set up a uniform workflow to securely store sensitive information.
API
The KV secrets engine has a full HTTP API. Please see the KV secrets engine API for more details.