Uploaded October 2025 | Updated September 2026, 3 weeks ago
HashiCorp Vault policies control authorization by attaching path-based capabilities to tokens.
Vault policies enforce a deny-by-default model, granting access only to explicitly defined paths and capabilities. Policies are written in HCL and are path-based; with KV v2, policies must target secret/data/{path} because Vault injects “data” in the API path. The workflow shown: enable a KV v2 secrets engine, write a simple read-only policy for a path, and attach that policy to a token—because access in Vault is mediated through tokens, not directly on secrets.
In the terminal demo, a token with a read-only policy can read the specified secret but cannot list secrets or write/delete. The video also covers using wildcards (like “*”) to allow reading multiple paths under a prefix, creating tokens bound to that wildcard policy, and verifying behavior both via CLI and the UI: read works when you know the path; listing, creating engines, writing, deleting, or viewing metadata are denied due to capabilities. The key takeaway is to be precise with paths and capabilities (e.g., read, list, delete) and to avoid using the root token outside setup; associate least-privilege policies to tokens for applications and users.
GitHub Repo github.com/QAInsights/learn-vault-series
Get Perplexity Pro for 1 month free pplx.ai/catchyplay47461
00:00 Intro and last video recap
01:11 Vault policy basics (deny‑by‑default, HCL, path‑based)
02:21 Policy structure: path + capabilities (read, list, etc.)
03:03 Attach policy to tokens (not secrets)
03:49 Enable KV v2 and write sample secret
04:26 Default policies (root, default) and listing
04:45 Read‑only policy for KV v2 (secret/data/…)
05:33 Write policy and create token with policy
06:17 Test: read allowed, list denied
07:11 Root vs read‑only; write new secret, re‑test
08:25 Wildcards in policies (*) and @file update
09:21 Create secret under wildcard and read with token
10:06 UI demo: can read by path, cannot list/enable/delete
11:24 Capabilities recap and policy specificity
HashiCorp Vault policies control authorization by attaching path-based capabilities to tokens.
Vault policies enforce a deny-by-default model, granting access only to explicitly defined paths and capabilities. Policies are written in HCL and are path-based; with KV v2, policies must target secret/data/{path} because Vault injects “data” in the API path. The workflow shown: enable a KV v2 secrets engine, write a simple read-only policy for a path, and attach that policy to a token—because access in Vault is mediated through tokens, not directly on secrets.
In the terminal demo, a token with a read-only policy can read the specified secret but cannot list secrets or write/delete. The video also covers using wildcards (like “*”) to allow reading multiple paths under a prefix, creating tokens bound to that wildcard policy, and verifying behavior both via CLI and the UI: read works when you know the path; listing, creating engines, writing, deleting, or viewing metadata are denied due to capabilities. The key takeaway is to be precise with paths and capabilities (e.g., read, list, delete) and to avoid using the root token outside setup; associate least-privilege policies to tokens for applications and users.
GitHub Repo github.com/QAInsights/learn-vault-series
Get Perplexity Pro for 1 month free pplx.ai/catchyplay47461
00:00 Intro and last video recap
01:11 Vault policy basics (deny‑by‑default, HCL, path‑based)
02:21 Policy structure: path + capabilities (read, list, etc.)
03:03 Attach policy to tokens (not secrets)
03:49 Enable KV v2 and write sample secret
04:26 Default policies (root, default) and listing
04:45 Read‑only policy for KV v2 (secret/data/…)
05:33 Write policy and create token with policy
06:17 Test: read allowed, list denied
07:11 Root vs read‑only; write new secret, re‑test
08:25 Wildcards in policies (*) and @file update
09:21 Create secret under wildcard and read with token
10:06 UI demo: can read by path, cannot list/enable/delete
11:24 Capabilities recap and policy specificity
