In this lesson, we’ll dive into Vault’s authorization model and learn how to define fine-grained access controls using policies. Vault policies, written in HCL, dictate which operations a user or machine can perform on specific secret paths. Every Vault token attaches to one or more policies, and access is always scoped by path.Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
Vault Policies and Paths
Imagine you have credential data for MongoDB and MySQL stored under a KV v2 secrets engine mounted atcrds. You want:
- Full CRUD (create, read, update) access to
crds/data/mongodb - Read-only access to
crds/data/mysql
| Path | Capabilities | Description |
|---|---|---|
crds/data/mongodb | create, read, update | Manage MongoDB credentials |
crds/data/mysql | read | Read-only access to MySQL secrets |
Vault policies are defined in HCL and loaded from local files. Capabilities include
create, read, update, delete, among others.1. Create the app Policy
Create a file at /home/vault/app-policy.hcl:
2. Enable KV v2 and Apply the Policy
Use your root token to enable the KV engine and load the policy:app policy:
Avoid using the root token for routine operations. Instead, generate scoped tokens for applications and users.
3. Generate a Token Bound to the app Policy
Create a new token that attaches only the app policy. Store it in the VAULT_TOKEN environment variable:
4. Test Policy Enforcement
-
Allowed Operation
Read MongoDB credentials: -
Denied Operation
Attempt to write MySQL credentials (not permitted by theapppolicy):You will see a 403 permission denied error:
app policy correctly restricts write access to the MySQL path.
Next Steps
After defining and testing policies, integrate them with an authentication method:- Kubernetes Auth
- AppRole Auth
- LDAP Auth