Managing HashiCorp Vault Access Policies

This is the third post in a series on Vault. For previous posts see, Getting Started and Secrets Engines.

Overview Link to heading

Vault uses policies to determine which secrets a client can see and what the user can do with them. Policies are deny by default in Vault and are evaluated as needed (i.e. lazy evaluation). As such the policy needs to be explicit about what access is granted.

Developing Policies Link to heading

To craft policies for a specific use case or deployment, consider reviewing HashiCorp’s own policy docs. These walk users through a basic workflow with examples for an admin and a provisioner.

Policy Structure Link to heading

Policies are written in JSON or HashiCorp’s Terraform language called HCL and contain a path and capabilities. See the HCL docs for more info on the syntax.

A simple policy to allow read access to a specific path looks like:

1
2
3

path "engine/path" {
  capabilities = ["read"]
}

Policy path’s can also use the wild card * to grant the desired capabilities to anything in a path. As well as the + wildcard to match a directory path.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# for everything under engine
path "engine/*" {
  capabilities = ["read"]
}

# For all subdirectories under engine, that also have a secrets sub-directory
# e.g. engine/v1/secrets, engine/v2/secrets
path "engine/+/secrets" {
  capabilities = ["read"]
}

There are parameter constraint keys that offer fine control over what path can have. These include the following:

• required_parameters: list of parameters that must be specified
• allowed_parameters: whitelist a list of keys and values that are permitted
• denied_parameters: blacklists a list of parameters and values

Finally, there are additional options for required response wrapping TTLs via a min_wrapping_ttl and max_wrapping_ttl.

Capabilities Link to heading

The capabilities options generally correspond to the HTTP verbs: create, read, update, delete, list. There are also sudo for root-protected paths and deny to specifically disallow access.

Policy CLI Link to heading

On the CLI here are the equivilient commands:

Built-in Policies Link to heading

There are two built-in policies that come with Vault:

Root Policy Link to heading

The root policy allows a user to do anything with Vault. The policy itself cannot be modified or removed. When Vault is first set up the root token is either passed in or provided to the user. This token is used to login as the root user and do the initial setup. Afterward, the token should be revoked:

1

vault token revoke "$token"

Default Policy Link to heading

The default policy is included in all tokens and provides common permissions. However, the user can update the administrator could update the policy to restrict these further. Vault makes sure to say that future updates to Vault would not override any changes an admin makes.

1
2
3
4

# view the default token
vault read sys/policy/default
# disables always attaching the default token
vault token create -no-default-policy

Next Steps Link to heading

With secrets stored and policies in place, it is time to grant access to the secrets!