Difficulty: beginner
Estimated Time: 5 minutes

HashiCorp Vault secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing.


Vault uses policies to govern the behavior of clients and instrument Role-Based Access Control (RBAC) by specifying access privileges (authorization).

When you first initialize Vault, the root policy gets created by default. This root policy is a special policy that gives superuser access to everything in Vault. Therefore, it is recommended that a token with root policy is used for just enough initial setup or in emergencies. As a best practice, use tokens with an appropriate set of policies based on your role in the organization.

This scenario supplements the Vault Policies guide.

In this scenario, you will learn how to write an ACL policy in Vault.

Vault logo

This scenario gave you a quick introduction to writing Vault policies.


Vault ACL Policies

Step 1 of 4

Write an ACL policy

Everything in Vault is path based, and admins write policies to grant or forbid access to certain paths and operations in Vault. Vault operates on a secure by default standard, and as such, an empty policy grants no permissions in the system.

First, login with root token.

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

vault login root

Before begins, let's check which secrets engines have been enabled: vault secrets list

The output should look like:

Path          Type         Description
----          ----         -----------
cubbyhole/    cubbyhole    per-token private secret storage
identity/     identity     identity store
secret/       kv           key/value secret storage
sys/          system       system endpoints used for control, policy and debugging

For each of these path, you must write policies to allow any operation against it.

Write a Policy File

You are going to write an ACL policy in HCL format. HCL is JSON compatible; therefore, JSON can be used as completely valid input.

Remember, an empty policy grants no permission in the system. Therefore, ACL policies are defined for each path.

path "<PATH>" {
   capabilities = [ "<LIST_OF_CAPABILITIES>" ]

The path can have a wildcard ("*") at the end to allow for any string in its place. For example, "secret/training_*" grants permissions on any path starting with "secret/training_" (e.g. secret/training_vault). To allow wildcard matching for a single directory, use "+". For example, "secret/app/+/stage" would match a path such as "secret/app/release_1.0/stage".

The base.hcl file should be opened in the editor pane. Enter the following policy rules in the editor (the following snippet can be copied into the editor):

path "secret/data/training_*" {
   capabilities = ["create", "read"]

path "secret/data/+/apikey" {
   capabilities = ["create", "read", "update", "delete"]

Notice that the path has the "splat" operator (training_*) as well as single directory wildcard (+). This is helpful in working with namespace patterns.

This policy grants create and read operations on any path starting with secret/data/training_. Also, permits create, read, update, and delete operations on any path matching the pattern of secret/data/<string>/apikey.

NOTE: When you are working with key/value secrets engine v2, the path to write policies would be secret/data/<path> even though the K/V command to the path is secret/<path>. When you are working with v1, the policies should be written against secret/<path>. This is because the API endpoint to invoke K/V v2 is different from v1.

Get help for the vault policy command:

vault policy -h

To view the full list of optional parameters for vault policy write operation, run the following command: vault policy write -h

To clear the screen: clear