Vault Associate cheat sheet

Auth methods exchange credentials for a Vault token; the token's policies come from the method's role/config, explicit token policies, and identity mappings.

Token auth is built-in at auth/token and cannot be disabled; every Vault request ultimately authenticates with a token.

AppRole uses role_id plus secret_id for machine authentication; secret_id constraints include TTL, use count, CIDR binding, and one-time use.

Kubernetes auth validates a service-account JWT through the cluster's TokenReview API and binds a role to allowed namespaces and service accounts.

AWS auth supports IAM SigV4 and EC2 instance identity; role binding limits access by account/ARN or instance metadata.

LDAP and userpass validate username/password; LDAP delegates password verification to the directory, while userpass stores password hashes in Vault.

JWT/OIDC auth validates tokens with keys or OIDC discovery and maps bound claims, audience, and issuer to Vault policies.

Each auth method is mounted at auth/; most types can be mounted multiple times for separate configurations.

Auth methods create identity aliases; aliases can be merged into one entity so a user or machine receives entity policies across methods.

Policies are HCL or JSON documents naming API paths and capabilities; capabilities include create, read, update, patch, delete, list, sudo, and deny.

A deny capability in any attached policy overrides allows for that path; otherwise capabilities are unioned across attached policies.

The default policy is attached to tokens unless no_default_policy is set; the root policy grants all permissions and cannot be edited or deleted.

Policy paths use plus (+) to match exactly one path segment and a trailing asterisk (*) to match a suffix wildcard.

Policy paths match API request paths, not CLI shorthand; KV v2 writes target secret/data/, not secret/.

The sudo capability is required for certain privileged operations, including some sys endpoints; root policy includes all capabilities.

Policy changes affect tokens that reference the policy on subsequent requests, without changing the token itself.

vault policy write creates or updates a policy; vault policy read displays it; vault policy delete removes it.

Policy paths are written without a leading slash and are relative to the Vault API root.

Service tokens are persisted, renewable, and revocable; batch tokens are not persisted, not renewable, and have a fixed TTL.

Token TTL is bounded by max_ttl; renewal increments up to max_ttl unless explicit_max_ttl or periodic token behavior applies.

Orphan tokens have no parent; revoking a parent token revokes its child tokens except orphans, which must be revoked separately.

A token accessor permits lookup and revocation without revealing the token value and is used for administration and auditing.

The root token carries the root policy; vault operator generate-root can create a new root token after initialization.

vault token create -policy= -ttl= -renewable= returns client_token and accessor; -orphan creates a parentless token.

Periodic tokens have a period value and can renew indefinitely if renewed before each period expires; they are not bounded by max_ttl.

no_default_policy omits the default policy; the token still receives policies from the auth method and explicit token policies.

Revoking a token revokes its child tokens and leases created by that token, cleaning up credentials issued under its authority.

KV v1 API paths are /; KV v2 reads and writes use /data/, and metadata operations use /metadata/.

vault kv get and vault kv put translate CLI paths for KV v2 automatically; raw API calls must include data/ or metadata/.

KV v2 supports versions, compare-and-swap (cas), soft delete, undelete, and destroy; metadata tracks current and deleted versions.

Dynamic secrets from engines such as database, AWS, and PKI return credentials with lease_id and lease_duration.

Response wrapping returns a single-use wrapping token; vault unwrap exchanges it for the original response.

Cubbyhole is a per-token private key-value store; its contents are deleted when the owning token is revoked or expires.

vault read reads static or dynamic secrets; vault write key=value writes data; vault list lists keys where supported.

Secret access is authorized by policy on the exact API path, including method-specific capabilities.

vault secrets enable -path= mounts an engine; vault secrets disable unmounts it and deletes its data.

vault secrets tune -default-lease-ttl= -max-lease-ttl= changes mount-level lease limits.

KV v2 is enabled with -version=2; it creates data/ and metadata/ subpaths and supports versioning, CAS, and soft delete.

The database engine configures connections and roles; roles define creation statements and credential TTLs.

The PKI engine issues certificates from configured roles; root or intermediate CA material and URLs are configured per mount.

The transit engine performs encryption, decryption, signing, and HMAC without storing plaintext; named keys support rotation.

Many secrets engines can be mounted multiple times at distinct paths, each with independent configuration and data.

vault secrets list shows mount path, type, accessor, and config; vault secrets list -detailed adds tuning fields.

External plugin engines must be registered in the plugin catalog before they can be enabled.

A Vault request passes through the listener/API, core, authentication or token validation, policy check, secrets engine, and storage barrier.

The storage backend persists encrypted data; integrated storage (Raft) is built in and requires a quorum of voting nodes for writes.

HA mode uses one active node and standby nodes; only the active node handles writes, and standbys forward or redirect requests.

The barrier encrypts data at rest; unseal keys or auto-unseal KMS unwrap the master key during startup.

Shamir unsealing requires a threshold of key shares; auto-unseal delegates unsealing to a KMS or HSM configured in a seal stanza.

Audit devices record requests and responses with HMAC of sensitive values; if all enabled audit devices fail, Vault fails closed.

vault operator init initializes storage and returns unseal keys and a root token; vault operator unseal submits unseal shares.

The identity store manages entities, aliases, groups, and entity policies that span multiple auth methods.

Dynamic secrets and service tokens have leases with lease_id, issue_time, expire_time, and renewable status.

vault lease lookup <lease_id> shows lease metadata; vault lease renew extends it within the lease's max_ttl.

vault lease revoke <lease_id> revokes credentials; -prefix revokes all leases under a path prefix.

Revoking a token revokes leases created by that token, so credential cleanup follows token cleanup.

Lease renewal fails when the lease reaches max_ttl; after that the credential must be reissued.

The sys/leases/lookup, sys/leases/renew, and sys/leases/revoke API endpoints perform lease operations.

KV secrets are not leased; leases apply to dynamic secrets and tokens, not static KV values.

vault lease renew -increment= <lease_id> requests a new TTL, and Vault may grant a shorter increment.

TLS listener config uses tls_cert_file and tls_key_file; clients set VAULT_ADDR to https and VAULT_CACERT to trust the CA.

vault status reports seal status, HA mode, and version; vault operator seal seals the active node.

vault operator raft snapshot save backs up integrated storage; vault operator raft snapshot restore restores it.

vault operator rekey changes unseal key shares and threshold; vault operator rotate rotates the encryption key.

Audit devices are enabled with vault audit enable file file_path=...; audit records HMAC request and response data.

vault operator generate-root requires a quorum of unseal keys and outputs an encoded root token; vault token revoke removes a root token.

Auto-unseal uses a seal stanza such as awskms; recovery keys authorize privileged operations instead of unseal keys.

mlock prevents Vault memory from being swapped; disable_mlock=true turns off that protection.