Hashicorp Vault: Fine-Grained Access Control with Policies

Source: Dev.to

Introduction

HashiCorp Vault is a flexible secret management engine that provides several authentication and authorization mechanisms. It stores secrets such as credentials, ciphers, or certificates. To use Vault’s functionality, a client must first authenticate, receiving an access token and the policies attached to that token. These policies determine which actions on which mount paths are allowed.

This article details Vault policies, shows how to write them in HCL, explains the action verbs and path patterns, and provides practical examples. The technical context is hashicorp_vault_v1.21.1 (released 2025‑11‑18); the examples remain valid for newer versions.

Policy Fundamentals

• Policies encode which actions (e.g., create, read, delete) are allowed at specific mount paths.
• All Vault functionality is accessed via mount paths, whether through the CLI or the HTTP API.
• If a token lacks a policy that permits a given path/action, the request is denied.
• Two built‑in policies exist:
  • root – full access to all paths and actions; attached to the root token for initial setup.
  • default – attached to all tokens (unless removed) and governs self‑referential lookup and data access for the token itself.

When a token has multiple policies with overlapping path declarations, Vault resolves them according to its priority matching ruleset, then checks the requested action against the combined capabilities.

Some paths are only accessible by the root policy or when the sudo capability is granted for that path (see the documentation on root‑protected API endpoints).

Policy Syntax (HCL)

A policy is written in the HashiCorp Configuration Language (HCL). The minimal structure includes a path block with a capabilities list:

path "PATH" {
  capabilities = ["cap"]
}

Advanced Options

Additional parameters can be explicitly allowed, denied, or required for HTTP API endpoints:

path "PATH" {
  capabilities = ["cap"]
  allowed_parameters = {
    "key" = ["value1", "value2"]
  }
  denied_parameters = {
    "key" = ["value3"]
  }
  required_parameters = {
    "key" = ["value4"]
  }
}

Response Wrapping

For endpoints that support response wrapping (to protect sensitive data), you can specify TTLs:

path "PATH" {
  capabilities   = ["cap"]
  min_wrapping_ttl = "5m"
  max_wrapping_ttl = "1h"
}

Path Wildcards

Path declarations can include two wildcard symbols:

Capabilities (Action Verbs)

The capabilities property is a list of verbs that control access:

• create – Add a new entity definition.
• read – Retrieve an entity definition.
• update / patch – Modify an existing entity definition (both map to the same CLI command vault patch).
• delete – Remove an entity definition.
• list – Enumerate entity definitions by name or ID (full details still require read).
• sudo – Grant full access to the entity, including root‑protected API endpoints.
• deny – Explicitly block all access to the resource.

All verbs except sudo and deny correspond directly to HTTP methods or CLI commands.

Example Policies

1. Managing a KV v2 Secrets Engine

path "kv2/*" {
  capabilities = ["create", "read", "update", "delete"]
}

2. Managing Authentication Methods

path "sys/auth" {
  capabilities = ["create", "read", "update", "delete", "sudo"]
}

path "sys/auth/+/tune" {
  capabilities = ["create", "read", "update", "delete", "sudo"]
}

3. Creating Orphaned Tokens

path "auth/token/create" {
  capabilities = ["create", "sudo"]
}

Conclusion

HashiCorp Vault implements fine‑grained access control through policies written in a concise HCL syntax. A policy consists of:

1. Path declaration – fixed or wildcard‑enabled.
2. Capabilities – verbs such as create, read, delete, list, sudo, or deny.

Policies are attached to tokens; when a token accesses a path, Vault resolves all applicable policies in priority order to determine whether the request is allowed. The examples above illustrate how to manage authentication methods, configure a KV v2 secrets engine, and issue orphaned tokens.