HashiCorp Certified: Vault Associate Certification

Create Vault Policies

Working with Policies

In this guide, you’ll learn how to create and test tokens scoped to specific policies and write administrative policies for Vault operators. Leveraging policy-based access control (PBAC) in HashiCorp Vault ensures fine-grained security, minimal access, and clear audit trails.

Table of Contents

  1. Creating a Token with a Policy
  2. Inspecting an Existing Token
  3. Testing Token Capabilities
  4. Writing Administrative Policies
  5. Links and References

Creating a Token with a Policy

To issue a new Vault token and bind it to one or more policies, run:

vault token create -policy="web-app"

Example output:

Key                    Value
---                    -----
token                  s.7uBlZwXSxOg31uGXIUetEdXD
token_accessor         18r88muoe3x1xEqVqXdlTMwJ
token_duration         768h
token_renewable        true
token_policies         ["default" "web-app"]
identity_policies      []

Token Attributes

FieldDescription
tokenThe actual authentication token
token_accessorShort-lived handle for revocation or lookup
token_durationTime-to-live (TTL) for the token
token_renewableIndicates if the token can be renewed
token_policiesList of attached policies (always includes default)
identity_policiesAttached identity group policies (if any)

Note

Every token in Vault inherits the default policy. Always design your custom policies to grant only the permissions required for your application.


Inspecting an Existing Token

To review the details and policies of an existing Vault token, use:

vault token lookup <token>

This command displays all token attributes, including the list of policies attached.


Testing Token Capabilities

Before deploying a token in production, validate that it grants exactly the permissions you need. Suppose your web-app policy (web-app.hcl) should:

  1. Read a secret at secret/data/api/key/google.
  2. Generate AWS credentials from aws/creds/s3-readonly.

After writing and loading your policy:

vault policy write web-app web-app.hcl

Test the policy with these steps:

# 1. Create a token scoped to "web-app"
vault token create -policy="web-app" -format=json \
  | jq -r ".auth.client_token" > token.txt

# 2. Log in with the new token
vault login "$(cat token.txt)"

# 3. Verify read access (should succeed)
vault kv get secret/api/key/google

# 4. Verify write access is denied (should fail)
vault kv put secret/api/key/google key="ABCDE12345"

# 5. Verify AWS credentials issuance (should succeed)
vault read aws/creds/s3-readonly

Warning

Always test both allowed and denied operations. Overprovisioned policies can lead to security risks.


Writing Administrative Policies

Vault operators need permissions to manage core system paths under sys/. Below is an example HCL policy granting common operator capabilities:

# Manage License
path "sys/license" {
  capabilities = ["read", "list", "create", "update", "delete"]
}

# Initialize Vault
path "sys/init" {
  capabilities = ["read", "create", "update"]
}

# Configure the UI
path "sys/config/ui" {
  capabilities = ["read", "list", "update", "delete", "sudo"]
}

# Rekey and Unseal Keys
path "sys/rekey/*" {
  capabilities = ["read", "list", "update", "delete"]
}

# Rotate the Master Key
path "sys/rotate" {
  capabilities = ["update", "sudo"]
}

# Seal the Vault
path "sys/seal" {
  capabilities = ["sudo"]
}

Key Points

  • Capabilities

    • read, list, create, update, delete: Standard operations.
    • sudo: Grants access to root-protected endpoints (use sparingly).
  • Least Privilege
    Only include the paths and capabilities that each operator role truly requires.


Watch Video

Watch video content

Practice Lab

Practice lab

Previous
Customizing the Path