Skip to main content
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.

​
Vault Policies and Paths

Imagine you have credential data for MongoDB and MySQL stored under a KV v2 secrets engine mounted at crds. You want:
  • Full CRUD (create, read, update) access to crds/data/mongodb
  • Read-only access to crds/data/mysql
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:
You should see:
Inspect the rules in the 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:
All subsequent Vault CLI commands will automatically use this token.

​
4. Test Policy Enforcement

  1. Allowed Operation
    Read MongoDB credentials:
  2. Denied Operation
    Attempt to write MySQL credentials (not permitted by the app policy):
    You will see a 403 permission denied error:
This confirms that the 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
These methods use roles to assign policies to authenticated entities, enabling seamless integration with external identity systems.

Watch Video