Skip to content
Latchkey

vault read: Usage, Options & Common CI Errors

Read from any Vault path - including dynamic secrets engines.

vault read fetches data from a Vault path. Unlike kv get (which is KV-aware), read is the general command for dynamic engines that mint credentials on demand - database, AWS, PKI, and more.

What it does

vault read <path> issues a GET to the given API path and prints the response. For dynamic engines it triggers credential generation: vault read database/creds/<role> returns a fresh, leased username/password; vault read aws/creds/<role> returns temporary AWS keys. The returned lease is revoked automatically at TTL.

Common usage

Terminal
# Read dynamic database credentials
vault read database/creds/readonly

# Extract one field for a CI step
AWS_KEY=$(vault read -field=access_key aws/creds/deploy)

# JSON for parsing, including the lease id
vault read -format=json pki/issue/web common_name=app.example.com

Common error in CI: no handler for route / permission denied

read fails with "No value found at <path>" / "no handler for route" (wrong path or engine not mounted) or "permission denied" (policy gap). Fix: confirm the engine is mounted (vault secrets list) and the role exists, use the exact API path (read uses raw paths, not the KV convenience path), and grant the token read on that path. For dynamic creds, ensure the lease TTL outlasts your job, or renew the lease - short TTLs that expire mid-build cause downstream auth failures.

Key options

OptionPurpose
<path>API path to read
-field=KEYPrint only one field
-format=jsonStructured output
field=valuePass parameters (e.g. for pki/issue)

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →