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

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

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.

Links and References

• HashiCorp Vault Documentation
• Vault CLI Reference
• Vault Policy Management
• Terraform Vault Provider Registry
• jq Manual