Vault - admin-policy.hcl (administrators)

category: solutionz · date: 2024-12-31 · updated: 2026-10-02 · author: LALA

Vault Solution · Config document · referenced from Authentication and policies

The policy attached to every human administrator account. It lets an administrator run the cluster, manage auth methods, mounts and policies, and read nothing in the secret store itself.

Item	Value
Path on the host	`/etc/vault.d/policy/admin-policy_v02.hcl`
Policy name in Vault	`admin-policy`
Loaded on	PROD, NONPROD and COMMON
Used by	administrators, through the `userpass` auth method
Applied with	`vault policy write admin-policy <file>`

The file

hcl

############################################################################
# ADMIN POLICY
############################################################################

############################################################################
# Basic permissions
############################################################################

# Read system health check
path "sys/health"
{
  capabilities = ["read", "sudo"]
}

############################################################################
# Operator command permissions
############################################################################

# vault operator members
# vault operator members list-peers
path "sys/ha-status"
{
  capabilities = ["read"]
}

# vault operator raft list-peers
path "sys/storage/raft/configuration"
{
  capabilities = ["read"]
}

# vault operator step-down
path "sys/step-down"
{
  capabilities = ["update", "sudo"]
}

############################################################################
# Policies administration - Create and manage ACL policies broadly across Vault
############################################################################

# List existing policies
path "sys/policies/acl"
{
  capabilities = ["list"]
}

# Create and manage ACL policies
path "sys/policies/acl/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo", "patch"]
}

############################################################################
# Authentication administration - Enable and manage authentication methods broadly across Vault
############################################################################

# Manage auth methods broadly across Vault
path "auth/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo", "patch"]
}

# Create, update, and delete auth methods
path "sys/auth/*"
{
  capabilities = ["create", "update", "delete", "sudo", "patch"]
}

# List auth methods
path "sys/auth"
{
  capabilities = ["read"]
}

############################################################################
# Secrets engines administration -  Enable and manage the key/value secrets engine at `secret/` path
############################################################################

# List, create, update, and delete key/value secrets
path "secret/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo", "patch"]
}

# Manage secrets engines
path "sys/mounts/*"
{
  capabilities = ["create", "read", "update", "delete", "list", "sudo", "patch"]
}

# List existing secrets engines.
path "sys/mounts"
{
  capabilities = ["read"]
}

What it does not grant

There is no rule for kv2/, so an administrator cannot read a customer secret with this policy alone. An administrator can, however, write a new policy that does and attach it to an account, and auth/* with sudo covers token creation. The separation is therefore an audit control, not a technical barrier: both actions are among the events the security operations centre alerts on.

Checked against Vault 2.1

Syntax and capabilities are unchanged. create, read, update, patch, delete, list, sudo and deny mean what they meant.
*secret/ is a leftover.** No mount named secret/ existed on these clusters; the rule comes from the tutorial this policy started from and grants nothing.
Root-level operations changed in 2.0. Rekeying and generating a root token now need a Vault token in addition to the recovery-key shares, so a current admin policy needs rules for sys/rekey/, sys/rekey-recovery-key/ and sys/generate-root/* if administrators are to run them. See the important changes.
A key written twice in one block is an error since 1.21. This file has none.

See policies.