Difficulty: beginner
Estimated Time: 5 minutes

Policies in Vault control what a user can access. In the last section, we learned about authentication. This section is about authorization.

For authentication Vault has multiple options or methods that can be enabled and used. Vault always uses the same format for both authorization and policies. All auth methods map identities back to the core policies that are configured with Vault.

There are some built-in policies that cannot be removed. For example, the root and default policies are required policies and cannot be deleted. The default policy provides a common set of permissions and is included on all tokens by default. The root policy gives a token super admin permissions, similar to a root user on a linux machine.

Vault logo

Policies are an important part of Vault. While using the root token is easiest to get up and running, you will want to restrict access to Vault very quickly, and the policy system is the way to do this.

The syntax and function of policies is easy to understand and work with, and because auth methods all must map to the central policy system, you only have to learn this policy system.

Next step

Read on the deploy Vault guide.

Vault Getting Started - Policies

ACL policy

First, login with root token.

Click on the command () will automatically copy it into the terminal and execute it.

vault login root

The policy format uses a prefix matching system on the API path to determine access control. The most specific defined policy is used, either an exact match or the longest-prefix glob match. Since everything in Vault must be accessed via the API, this gives strict control over every aspect of Vault, including enabling secrets engines, enabling auth methods, authenticating, as well as secret access.

Open the example policy, my-policy.hcl

With this policy, a user could write any secret to secret/data/, except to secret/data/foo, where only read access is allowed. Policies default to deny, so any access to an unspecified path is not allowed.

To write a policy using the command line, specify the path to a policy file to upload.

vault policy write my-policy my-policy.hcl

To see the list of policies, execute the following command.

vault policy list

To view the contents of a policy, execute the vault policy read command.

vault policy read my-policy

Testing the Policy

First, check to verify that KV v2 secrets engine has not been enabled at secret/.

vault secrets list

To use the policy, create a token and assign it to that policy.

vault token create -policy=my-policy \
   -format=json | jq -r ".auth.client_token" > token.txt

Copy the generated token value and authenticate with Vault.

vault login $(cat token.txt)

Verify that you can write any data to secret/data/.

NOTE: When you access the KV v2 secrets engine using the vault kv CLI commands, you can omit /data in the secret path.

vault kv put secret/creds password="my-long-password"

Since my-policy only permits read from the secret/data/foo path, any attempt to write fails with "permission denied" error.

vault kv put secret/foo robot=beepboop

You also do not have access to sys according to the policy, so commands like vault policy list or vault secrets list will not work.