Vault KV v1: Static Secret Management with a Simple Key/Value Engine

KV v1 is a simple key/value secret engine with no versioning or metadata. It focuses on read, write, and delete, and is well suited for initial bootstrap secrets and storing small configuration values.

In modern Vault deployments, KV v2 is typically the default, so to use v1 you must explicitly pass -version=1 at enable time. This difference and the path layout come up often on the exam.

KV v1 Overview and Design Principles

KV v1 is a static secret store that saves keys and values as-is under a specified mount. It keeps no version history or deletion history, and operations are essentially just PUT, GET, LIST, and DELETE. There are no leases or automatic expiration as with dynamic credentials.

Simplicity is the biggest advantage, making it a fit for app bootstrap API keys, webhook tokens, and small configuration values. Even though KV v2 tends to be the default today, when version management is unnecessary or low priority, v1 is lighter to operate and keeps policies and path design simpler.

• Aimed at static secrets. No leases or automatic rotation
• No versioning. Deletes are immediate and irreversible
• Paths are <mount>/<path> (e.g., secret/app)
• LIST requires the explicit list capability
• Response Wrapping is available as a protocol feature (engine-agnostic)

KV v1 logical flow (authorize → store)

Enabling and Basic Operations (CLI and HTTP)

To use KV v1, pass -version=1 at mount time. From there you simply PUT/GET/LIST/DELETE against mount/path. Values are a simple key=value map, and the CLI can handle multiple k=v pairs at once.

LIST requires the dedicated HTTP method (LIST) and the policy capability=list. Deletion is immediate; there is no soft delete, undelete, or destroy operation as in v2.

• Enable: vault secrets enable -version=1 kv
• Write: vault kv put <mount>/<path> k=v ...
• Read: vault kv get <mount>/<path>
• List: vault kv list <mount>/<prefix>
• Delete: vault kv delete <mount>/<path> (irreversible)

Minimal CLI and HTTP API workflow

# kv v1 を secret/ にマウント
vault secrets enable -path=secret -version=1 kv

# 書き込み（複数キー）
vault kv put secret/app api_key=s3cr3t env=prod

# 読み取り
vault kv get secret/app

# 一覧（末尾スラッシュに注意）
vault kv list secret/

# 削除（即時・不可逆）
vault kv delete secret/app

# HTTP API（書き込み）
curl \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -X PUT \
  -d '{"api_key":"s3cr3t","env":"prod"}' \
  "$VAULT_ADDR/v1/secret/app"

# HTTP API（読み取り）
curl -H "X-Vault-Token: $VAULT_TOKEN" "$VAULT_ADDR/v1/secret/app"

KV v1 vs v2 (Exam-Focused Comparison Table)

The Associate exam frequently asks about the differences between v1 and v2. In particular, lock in the path layouts (v1 is <mount>/<path>; v2 uses data/ and metadata/) and the presence or absence of delete/undelete and CAS.

The CLI auto-detects the mount version in many situations, but policy path expressions and HTTP API endpoints are clearly different.

• v1 is simple, with no versioning and immediate delete
• v2 supports versioning, CAS, and soft delete/undelete
• Policy path expressions are the biggest pitfall

Policy Design and Least Privilege (Do Not Forget LIST)

Vault is deny-by-default. With KV v1, grant read, write (create/update), delete, and list with least privilege. In particular, vault kv list will fail unless LIST is explicitly granted.

For v1, the path is <mount>/* (e.g., secret/*). Do not confuse this with v2's data/metadata paths. Carving prefixes by team or app makes it easier to scale in the future.

• Default deny → explicitly grant least-privilege capabilities
• LIST is a dedicated capability, separate from read
• Split path granularity by app/environment (e.g., secret/prod/appA/*)
• Separate write-only and read-only tokens

Sample ACL policy for KV v1 (HCL)

path "secret/appA/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# 読み取り専用の例
path "secret/appA/*" {
  capabilities = ["read", "list"]
}

# ルート一覧のみ（インベントリ用途）
path "secret/" {
  capabilities = ["list"]
}

Operational Best Practices and Pitfalls

Because KV v1 has no versioning, accidental deletes and overwrites hit you directly. Make the change flow explicit and put reviews and backups in place (for example, periodic exports stored encrypted) to stay safe.

Organize key naming with prefixes and structure them hierarchically by environment, app, and purpose. Large binaries or data that needs frequent updates are a poor fit; consider an external store or KV v2 in those cases. Always enable audit devices so you have a record of who read which path.

• Deletes are irreversible → require pre-review and export mechanisms
• Separate paths by environment and app (e.g., prod/stg/dev)
• Avoid large data; keep values to the minimum required
• Minimize exposure during handoff via Response Wrapping and short-lived tokens
• Re-check whether v2 requirements (history/undelete/CAS) really do not apply

Associate Exam Prep Checklist

Differences in commands and paths and the use of policy capabilities are frequently tested. In particular, v1 vs v2 paths, whether LIST is granted, and delete behavior are easy to miss.

• Enable: vault secrets enable -version=1 kv (use -path for a custom mount)
• v1 API: /v1/<mount>/<path>; LIST is against /prefix
• v1 has no versioning, CAS, or soft delete
• Example v1 policy path: path "secret/*"
• Without the LIST capability, kv list fails
• Delete is immediate and unrecoverable → watch for exam trick questions

Check Your Understanding

Frequently Asked Questions