KodeKloud Notes

Vault Policies are the core mechanism for enforcing authorization in HashiCorp Vault. By defining fine-grained permissions on Vault paths and operations, policies uphold the principle of least privilege. This ensures that diverse clients—DBAs creating dynamic database credentials, Packer builds pulling secrets, reporting applications querying data, CI/CD pipelines provisioning cloud resources, and administrators performing routine tasks—receive only the access they need.

The image is a slide about Vault Policies, explaining their role in permitting or denying access, the use of declarative statements in JSON or HCL, and the importance of the principle of least privilege.

Why Use Vault Policies?

Enforce Role-Based Access Control (RBAC)
Segregate duties across automation tools and human operators
Protect sensitive paths and actions
Minimize blast radius by granting minimal required capabilities

Note

Always follow the principle of least privilege: grant only the permissions necessary for each client.

Vault supports policies authored in JSON or HCL (HashiCorp Configuration Language). HCL is more human-readable and is the community’s preferred choice for most configurations.

Note

For detailed syntax and examples, see the official Vault Policy Syntax documentation.

Vault Policies operate under three fundamental rules:

Feature	Description
Deny by Default	Any access not explicitly granted is automatically denied.
Explicit Deny	You may override allow rules by explicitly denying specific paths or capabilities.
Cumulative	A token can have multiple policies attached; its effective permissions are the union of all.

The image explains Vault policies, highlighting that they are "Deny by Default" and require explicit grants. It also notes that policies are cumulative and attached to tokens, with capabilities being additive.

When a client authenticates, Vault issues a token. Policies attached to that token determine the client’s capabilities. If multiple policies are attached, their permissions merge together.

Vault ships with two built-in policies:

Policy Name	Description	Modifiable	Attached To
`root`	Grants unrestricted access to all Vault paths and actions.	No	All root tokens
`default`	Allows basic token operations (lookup, renew, revoke).	Yes	All non-root tokens

The image describes "Out-of-the-Box Vault Policies," detailing the characteristics of the "root" and "default" policies, including their permissions and modifiability.

Warning

The root policy is implicit and cannot be viewed, modified, or deleted.

To list all available policies in your Vault server:

vault policy list
# Output:
# default
# root

Read the contents of the default policy:

vault policy read default
# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
  capabilities = ["read"]
}

# Allow tokens to renew themselves
path "auth/token/renew-self" {
  capabilities = ["update"]
}

# Allow tokens to revoke themselves
path "auth/token/revoke-self" {
  capabilities = ["update"]
}

# Allow tokens to view their own capabilities
path "sys/capabilities-self" {
  capabilities = ["update"]
}

Attempting to read the root policy returns an error:

vault policy read root
# Error reading policy: No policy named 'root'

Under the hood, the root policy behaves as if it contains:

path "*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

Watch Video

Watch video content