Skip to main content
Vault implements path-based access control. A policy is a set of rules, where each rule associates:
  1. A target path pattern
  2. A list of capabilities (permissions) for that path
You can combine multiple rules within a single policy to enforce the principle of least privilege.

​
Policy Template

path "<path-pattern>" {
  capabilities = ["<permission1>", "<permission2>", ...]
}

path "<another-path>" {
  capabilities = ["<permissionA>", "<permissionB>", ...]
}
Path patterns support wildcards (*, ?) and must match the Vault mount and engine.
For details, see the Vault Policy Rules documentation.

​
Common Capabilities

CapabilityDescription
createWrite new data or secret
readRetrieve existing data or secret
updateModify existing data or secret
deleteRemove data or secret
listEnumerate keys or names under a path
sudoAllow operations on behalf of another user

​
Concrete Example

Below is a policy that combines KV secrets, policy administration, and dynamic AWS credentials: 
path "kv/data/apps/jenkins" {
  capabilities = ["read", "update", "delete"]
}

path "sys/policies/*" {
  capabilities = ["create", "update", "list", "delete"]
}

path "aws/creds/web-app" {
  capabilities = ["read"]
}

​
Rule Breakdown

  • kv/data/apps/jenkins
    Grants read, update, and delete permissions on the Jenkins application data in the KV Secrets Engine.
  • sys/policies/*
    Allows managing all policies (* wildcard) with create, update, list, and delete.
  • aws/creds/web-app
    Permits read access to dynamic AWS credentials from the web-app role in the AWS Secrets Engine.
Overly broad path patterns (e.g., *) can expose more resources than intended. Always validate wildcard usage to avoid privilege escalation.
By composing targeted rules, Vault policies help you grant only the permissions required for each team or application, adhering to security best practices.

Watch Video