open-vault/website/source/docs/secrets/kv/kv-v1.html.md
Brian Kassouf a8b8ca136e
KV: Update 'versioned' naming to 'v2' (#4293)
* Update 'versioned' naming to 'v2'

* Make sure options are set

* Fix description of auth flag

* Review feedback
2018-04-09 09:39:32 -07:00

2.8 KiB

layout page_title sidebar_current description
docs KV - Secrets Engines docs-secrets-kv-v1 The KV secrets engine can store arbitrary secrets.

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.

  1. Write arbitrary data:

    $ vault kv put kv/my-secret my-value=s3cr3t
    Success! Data written to: kv/my-secret
    
  2. Read arbitrary data:

    $ vault kv get kv/my-secret
    Key                 Value
    ---                 -----
    refresh_interval    768h
    my-value            s3cr3t
    
  3. List the keys:

    $ vault kv list kv/my-secret
    Keys
    ----
    my-secret
    
  4. Delete a key:

    $ vault kv delete kv/my-secret
    Success! Data deleted (if it existed) at: kv/my-secret
    

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. This is commonly displayed as refresh_interval instead of lease_duration to clarify this in output.

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 will 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
---                 -----
refresh_interval    30m
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.