Vault Policies Part 2

​

Core Capabilities Overview

​

Example 1: Simple CRUD Policy

1. Read access to database/creds/dev-db01.
2. Full CRUD on kv/apps/dev-app01.

path "database/creds/dev-db01" {
  capabilities = ["read"]
}

path "kv/apps/dev-app01" {
  capabilities = ["create", "read", "update", "delete"]
}

• For KV v2, prefix paths with data/ (e.g., path "data/kv/apps/dev-app01").
• A single policy can include multiple path blocks; tokens inherit all rules.

​

Example 2: Glob Patterns with Explicit Deny

kv/
└── apps/
    ├── webapp/
    │   ├── api
    │   ├── token
    │   ├── hostname
    │   └── super_secret
    ├── mid-tier/
    └── database/

path "kv/apps/webapp/*" {
  capabilities = ["read"]
}

path "kv/apps/webapp/super_secret" {
  capabilities = ["deny"]
}

• The glob webapp/* matches all child paths—not the directory itself.
• deny on super_secret overrides any read rights.

​

Pop Quiz

1. Does kv/apps/webapp/* allow access to kv/apps/webapp (no trailing slash)?
   No. The glob only matches subpaths after the slash.
2. Can a user browse the UI down to webapp?
   Not without list on the parent paths (kv/, kv/apps/, kv/apps/webapp).
   Example policy to enable UI navigation:
   path "kv/apps/webapp/*" {
     capabilities = ["read", "list"]
   }
   
   # Or more broadly:
   path "kv/*" {
     capabilities = ["list"]
   }
   

​

Wildcards in Policy Paths

1. Asterisk (*) at the end of a path segment (glob).
2. Plus (+) replacing exactly one path segment.

​

Asterisk (*) Globs

# Read anything under application1
path "secret/apps/application1/*" {
  capabilities = ["read"]
}

# Matches kv/platform/db-2, kv/platform/db-3/production, etc.
path "kv/platform/db-*" {
  capabilities = ["read"]
}

path "secret/apps/application1" {
  capabilities = ["read"]
}

​

Plus (+) Wildcards

# Matches secret/dev/db, secret/prod/db, etc.
path "secret/+/db" {
  capabilities = ["read"]
}

# Matches kv/data/apps/dev/webapp or kv/data/apps/qa/webapp
path "kv/data/apps/+webapp" {
  capabilities = ["read"]
}

path "secret/apps/+/*team-*" {
  capabilities = ["create", "read"]
}

​

ACL Templates (Variable Interpolation)

path "secret/data/{{identity.entity.id}}/*" {
  capabilities = ["create", "read", "update", "delete"]
}

path "secret/metadata/{{identity.entity.id}}/*" {
  capabilities = ["list"]
}

​

Assigning and Testing Policies

1. Create a policy (e.g., web-app) via the Vault CLI or API.
2. Issue a token bound to that policy:
   vault token create -policy="web-app"
   
   Example output: Key Value

   ---

   token hvs.7uBlZwXSxOg31uGXIUetEdXD token_accessor 18r88muoe3x1xEqVqXdlTMwJ token_duration 8h token_renewable true token_policies [“default” “web-app”] identity_policies []
3. Test with the new token:
   vault login <token>
   
   # Should succeed (read)
   vault read secret/apikey/Google
   
   # Should fail (no create/update)
   vault write secret/apikey/Google key="ABCDE12345"
   
   # Should succeed (AWS read-only creds)
   vault read aws/creds/s3-readonly
   

​

Example: Administrative Policy

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

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

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

# Rekey operations
path "sys/rekey/*" {
  capabilities = ["read", "list", "create", "update", "delete"]
}

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

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