LogoOwlDocs

Vault Policies

Learn to manage secrets and access with Vault policies.

What are Vault Policies (ACL)?

Vault policies, also known as Access Control Lists (ACL), define what actions users and applications can perform within HashiCorp Vault. They help you control access to secrets, manage permissions, and ensure security by specifying who can read, write, or manage specific paths and resources in Vault.

Using Vault Policies

As a developer, Vault policies let you access only the secrets your app needs, keeping your permissions minimal and secure.

Creating Policies

Let's create a policy named read-secrets that grants read-only access to all secrets in the secret KV engine. First, save the following policy definition inside a file (for example, read-secrets.hcl) :

path "secret/*" {
  capabilities = ["read", "list"]
}

The filename does not matter, but the policy must be defined in a file.

Then we can apply the configuration with the Vault CLI :

vault policy write {name_policy} {filename}.hcl

You created your first policy!

Administration

There are no default policies specifically for admin users in Vault. You need to create custom policies that grant the necessary administrative permissions based on your requirements.

Custom Admin Policy

Here is an example of a custom admin policy that grants full access to all paths in Vault:

# Grant access to root thing
path "*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

# Grant access to all first-level paths
path "**/*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

# Grant access to all second-level paths
path "**/**/*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

# Grant access to all third-level paths
path "**/**/**/*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

Default Super Admin Policy

By default, the only true "super admin" in Vault is the root policy, which is automatically created when you initialize Vault. The root policy grants unrestricted access to all operations and paths within Vault. It should be used with extreme caution and only for initial setup or emergency situations, as it bypasses all access controls.

For day-to-day administration, it is recommended to create custom admin policies (like the example above) that grant only the necessary permissions, rather than relying on the root policy.

Standard User Policy

A standard user policy grants limited access to specific secrets, following the principle of least privilege.

Policy for a Web Application

The following policy grants a user read-only access to the webserver secret in the secret KV engine :

path "secret/data/webserver" {
  # Allows the user to read the secret data for the webserver.
  capabilities = ["read"]
}

path "secret/metadata/webserver" {
  # Allows the user to list the secrets at the webserver path.
  capabilities = ["list"]
}

Granting Access to a Single KV Secret

You can create a policy that allows access to all secrets inside a specific KV engine. For example, to grant read-only access to all secrets in the databased KV engine :

# Define the policy name
path "database/*" {
  capabilities = ["read", "list"]
}

# Allow access to the metadata of all secrets in the database
path "database/metadata/*" {
  capabilities = ["read", "list"]
}

Modifying Policies

To update an existing policy, simply edit the policy file with your changes and reapply it using the Vault CLI :

vault policy write {name_policy} {filename}.hcl

Deleting Policies

To remove a policy from Vault, use the following command with the Vault CLI :

vault policy delete {policy_name}

Vault Policy Capabilities

Vault policies use capabilities to define what actions are allowed on specific paths. Here are the standard capabilities you can assign :

CapabilityHTTP Verb(s)Description
createPOST/PUTCreate data at the path.
readGETRead data at the path.
updatePOST/PUTChange data at the path.
patchPATCHPartially update data at the path.
deleteDELETEDelete data at the path.
listLISTList values at the path.
sudoN/AAccess root-protected paths.
denyN/AAlways deny access.
subscribeN/ASubscribe to events at the path.
recoverN/ARecover data from a snapshot.

You can combine these capabilities as needed in your policy definitions to control access precisely.