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 rely on hierarchical paths to control access. Everything in Vault is organized by path, reinforcing the core concepts of Vault’s architecture and pathing model. By understanding how paths work, you can craft precise policies that grant only the permissions your applications and operators need.

​
Common Vault Paths

PathTypeDescription
sys/policySystemManage policies
auth/ldap/groups/developersAuth methodLDAP group binding for “developers”
database/roles/prod-dbSecrets engineRole definition for a production database
sys/rekeySystem-criticalRe-encrypt data keys during rekey operations
Paths prefixed with sys/ map to Vault’s internal systems. For example, sys/rekey is used to rotate and re-encrypt data encryption keys.

​
Understanding a Secrets Engine Path

When you enable the KV (Key-Value) secrets engine v2 at the mount point secrets/, all data operations use the data/ prefix. For instance, storing Ansible credentials under a nested hierarchy might look like this: 
secrets/data/platform/aws/tools/ansible
This path breaks down as:
SegmentDescription
secrets/KV-v2 mount point
data/Data API prefix for KV-v2
platform/aws/tools/ansibleCustom, application-specific hierarchy
Each segment after data/ can contain key/value pairs. Always reference the complete path when reading, writing, or deleting secrets.
The image explains the structure of a path used in a secrets management system, highlighting different segments for mounting, required elements, higher-level paths, and key/value storage.

​
Root-Protected Paths

Certain Vault endpoints are root-protected and require either a root token or sudo capabilities to access. These paths control critical cluster operations.
PathAction
sys/rotateRotate the master encryption key
sys/sealManually seal (lock) the Vault
sys/step-downForce the current leader to step down
Root-protected paths expose powerful operations. Grant sudo only to trusted administrators.
The image is a slide titled "Vault Policies - Path," explaining root-protected paths in Vault, requiring a root token or sudo capability, with examples like creating an orphan token and rotating the encryption key. It features a lock icon and a cartoon character.
To grant sudo capabilities on these critical paths, include the following in your HCL policy: 
path "sys/rotate" {
  capabilities = ["sudo"]
}

path "sys/seal" {
  capabilities = ["sudo"]
}

path "sys/step-down" {
  capabilities = ["sudo"]
}
Use this snippet to ensure only authorized operators can perform high-privilege Vault operations.

​
Further Reading

Watch Video