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:
$ vault secrets enable -version=1 kv
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:
$ vault kv put kv/my-secret my-value=s3cr3tSuccess! Data written to: kv/my-secret
Read arbitrary data:
$ vault kv get kv/my-secretKey Value--- -----my-value s3cr3t
List the keys:
$ vault kv list kv/Keys----my-secret
Delete a key:
$ vault kv delete kv/my-secretSuccess! Data deleted (if it existed) at: kv/my-secret
You can also use Vault's password policy feature to generate arbitrary values.
Write a password policy:
$ vault write sys/policies/password/example policy=-<<EOF length=20 rule "charset" { charset = "abcdefghij0123456789" min-chars = 1 } rule "charset" { charset = "!@#$%^&*STUVWXYZ" min-chars = 1 } EOF
Write data using the
example
policy:$ vault kv put kv/my-generated-secret \ password=$(vault read -field password sys/policies/password/example/generate)
Read the generated data:
$ vault kv get kv/my-generated-secret====== Data ======Key Value--- -----password ^dajd609Xf8Zhac$dW24
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:
$ vault kv put kv/my-secret ttl=30m my-value=s3cr3tSuccess! Data written to: kv/my-secret
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:
$ vault kv get kv/my-secretKey Value--- -----my-value s3cr3tttl 30m
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.