vault kv get: Usage, Options & Common CI Errors

Read a secret from Vault’s key/value engine.

vault kv get retrieves a secret stored in the KV secrets engine. In CI you fetch one field for injection into a build step, authenticating via a token or an auth method first.

What it does

vault kv get <path> reads the secret at a KV path and prints its keys and metadata. With -field it prints a single value (no formatting, ideal for shell capture); with -format=json it emits structured output for jq. KV v2 paths include the mount but not the literal "data/" segment - the CLI handles that.

Common usage

# Read a whole secret
vault kv get secret/myapp/config

# Extract one field for a CI variable (no quotes)
DB_PASS=$(vault kv get -field=password secret/myapp/db)

# JSON output for parsing
vault kv get -format=json secret/myapp/config | jq -r '.data.data.api_key'

Common error in CI: permission denied / not authenticated

kv get fails with "Error making API request ... Code: 403. permission denied" or "missing client token". The runner has no token or a policy that does not allow the path. Fix: authenticate first (set VAULT_TOKEN, or vault login via AppRole/JWT/OIDC) and set VAULT_ADDR; ensure the token’s policy grants read on the exact path (for KV v2 the policy path is <mount>/data/<path>, not the CLI path). Prefer short-lived AppRole or CI OIDC tokens over long-lived ones.

Key options

Related guides