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

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:
This path breaks down as: 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.
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:
Use this snippet to ensure only authorized operators can perform high-privilege Vault operations.

​
Further Reading

Watch Video