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 :
Capability | HTTP Verb(s) | Description |
---|---|---|
create | POST/PUT | Create data at the path. |
read | GET | Read data at the path. |
update | POST/PUT | Change data at the path. |
patch | PATCH | Partially update data at the path. |
delete | DELETE | Delete data at the path. |
list | LIST | List values at the path. |
sudo | N/A | Access root-protected paths. |
deny | N/A | Always deny access. |
subscribe | N/A | Subscribe to events at the path. |
recover | N/A | Recover data from a snapshot. |
You can combine these capabilities as needed in your policy definitions to control access precisely.