Vault Associate: Create Vault Policies

Policies are deny-by-default

A Vault policy is an HCL (or JSON) document of path stanzas. Anything not granted is denied. Each stanza lists capabilities drawn from create, read, update, delete, list, patch, sudo, and deny.

path "secret/data/app/*" {
  capabilities = ["read", "list"]
}

Policies attach to tokens and identities, never directly to users. The default policy is attached automatically to every token. Write with vault policy write app-read app-read.hcl; inspect with vault policy read app-read.

Path matching

* is a glob that matches trailing characters and is only valid at the end of a path; + matches exactly one path segment. So secret/data/app/* covers everything under app/, while secret/data/+/config matches one level down. Paths are API paths, which is why KV v2 needs secret/data/... for reads and secret/metadata/... for list.

Traps

• deny always wins, and a deny on / cannot be overridden.
• Capabilities are additive across every policy on a token; you cannot subtract with a second policy.
• Editing a policy affects tokens already holding it immediately - no re-login needed.
• Listing keys requires list, not read.
• sudo is reserved for a small set of root-protected endpoints.

Rule of thumb: grant the narrowest path with the fewest capabilities, then confirm with vault token capabilities <token> <path> before shipping.