Vault
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=s3cr3t Success! Data written to: kv/my-secretRead arbitrary data:
$ vault kv get kv/my-secret Key Value --- ----- my-value s3cr3tList the keys:
$ vault kv list kv/ Keys ---- my-secretDelete a key:
$ vault kv delete kv/my-secret Success! 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 } EOFWrite data using the
examplepolicy:$ 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=s3cr3t
Success! 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-secret
Key Value
--- -----
my-value s3cr3t
ttl 30m
API
The KV secrets engine has a full HTTP API. Please see the KV secrets engine API for more details.
Terraform
You can manage KV v1 secret resources programmatically with the Vault Terraform provider. Refer to the Terraform Registry documentation for more details: