Skip to main content

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 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
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.
For detailed syntax and examples, see the official Vault Policy Syntax documentation.
Vault Policies operate under three fundamental rules:
FeatureDescription
Deny by DefaultAny access not explicitly granted is automatically denied.
Explicit DenyYou may override allow rules by explicitly denying specific paths or capabilities.
CumulativeA 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 NameDescriptionModifiableAttached To
rootGrants unrestricted access to all Vault paths and actions.NoAll root tokens
defaultAllows basic token operations (lookup, renew, revoke).YesAll 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.
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