open-vault/website/source/docs/secrets/kv/kv-v1.html.md

112 lines
2.8 KiB
Markdown
Raw Normal View History

---
layout: "docs"
page_title: "KV - Secrets Engines"
New Docs Website (#5535) * conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
2018-10-19 15:40:11 +00:00
sidebar_title: "K/V Version 1"
sidebar_current: "docs-secrets-kv-v1"
description: |-
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:
```text
$ vault kv put kv/my-secret my-value=s3cr3t
Success! Data written to: kv/my-secret
```
1. Read arbitrary data:
```text
$ vault kv get kv/my-secret
Key Value
--- -----
refresh_interval 768h
my-value s3cr3t
```
1. List the keys:
```text
$ vault kv list kv/
Keys
----
my-secret
```
1. 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:
```text
$ 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:
```text
$ 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](/api/secret/kv/kv-v1.html) for more
details.