• HashiCorp Developer

  • HashiCorp Cloud Platform
  • Terraform
  • Packer
  • Consul
  • Vault
  • Boundary
  • Nomad
  • Waypoint
  • Vagrant
Vault
  • Install
  • Tutorials
  • Documentation
  • API
  • Integrations
  • Try Cloud(opens in new tab)
  • Sign up
Vault Home

Documentation

Skip to main content
  • Documentation
  • What is Vault?
  • Use Cases

  • Browser Support
  • Installing Vault

    • Overview
    • Active Directory
    • AliCloud
    • AWS
    • Azure
    • Consul
    • Cubbyhole
    • Google Cloud
    • Google Cloud KMS
      • Overview
      • K/V Version 1
      • K/V Version 2
    • KMIP
      ENTERPRISEENTERPRISE
    • Kubernetes
    • MongoDB Atlas
    • Nomad
    • LDAP
    • RabbitMQ
    • Terraform Cloud
    • TOTP
    • Venafi (Certificates)
  • Vault Integration Program
  • Vault Interoperability Matrix
  • Troubleshoot






  • Glossary


  • Resources

  • Tutorial Library
  • Certifications
  • Community Forum
    (opens in new tab)
  • Support
    (opens in new tab)
  • GitHub
    (opens in new tab)
  1. Developer
  2. Vault
  3. Documentation
  4. Secrets Engines
  5. Key/Value
  6. K/V Version 1
  • Vault
  • v1.11.x
  • v1.10.x
  • v1.9.x
  • v1.8.x
  • v1.7.x
  • v1.6.x
  • v1.5.x
  • v1.4.x

»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
    ---                 -----
    my-value            s3cr3t
    
  3. List the keys:

    $ vault kv list kv/
    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.

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

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.

Edit this page on GitHub

On this page

  1. KV Secrets Engine - Version 1
  2. Setup
  3. Usage
  4. TTLs
  5. Tutorial
  6. API
Give Feedback(opens in new tab)
  • Certifications
  • System Status
  • Terms of Use
  • Security
  • Privacy
  • Trademark Policy
  • Trade Controls
  • Give Feedback(opens in new tab)