Vault Enterprise: Advanced Policy Control with Sentinel Policies

When you need Vault access control that reasons about who, where, when, and under what conditions a request is made, Enterprise Sentinel Policies are the centerpiece.

This article walks through EGP/RGP, evaluation order, practical policy examples, and test/rollout strategy from an Ops perspective — also covering the key points you need for the exam.

Big Picture and Terminology (How ACLs and Sentinel Relate)

Vault Enterprise Sentinel Policies layer runtime evaluation on top of standard ACLs. First, ACLs decide the base capabilities (read/write/list/etc.); requests that pass then go through Sentinel, which renders the final verdict using additional conditions such as time of day, token metadata, Identity groups, and parameter contents.

The most commonly used scopes are EGP (Endpoint Governing Policy), which targets an endpoint, and RGP (Role Governing Policy), which targets a specific role's operations. Both come with an enforcement level (advisory / soft-mandatory / hard-mandatory); hard-mandatory always denies on failure.

• Evaluation order: ACL → Sentinel (proceed if it passes, deny if it does not)
• Enforcement level: advisory (notification only), soft-mandatory (enforced by default, commonly configured so that privileged actors may override), hard-mandatory (absolute enforcement)
• EGP: applied broadly based on path and operation type
• RGP: applies fine-grained constraints to operations and parameters tied to a specific role (e.g., PKI/AWS/Database roles)

Vault request evaluation flow

Creating and updating EGP/RGP (example)

## EGP example: lock down operations directly under sys/*
evn VAULT_ADDR=https://vault.example.com
vault login $TOKEN
vault write sys/policies/egp/egp-sys-guard \
  [email protected] \
  enforcement_level=hard-mandatory \
  paths="sys/*"

## RGP example: limit the TTL on a PKI issuing role
evn VAULT_ADDR=https://vault.example.com
vault write sys/policies/rgp/pki-ttl-guard \
  [email protected] \
  enforcement_level=soft-mandatory \
  paths="pki/issue/*"

Evaluation Triggers and Available Context

Sentinel evaluates once a request that matches the target endpoint or role clears ACL. The evaluation can inspect the request path, operation type, and body data, as well as token metadata and the attached Identity entity and groups. This makes it possible to encode operations-aware rules such as 'only this group may issue with this parameter value' or 'block mutating operations outside business hours.'

In practice, the following are the most commonly used inputs. Exact attribute names may shift between versions, but the high-level shape — request (path/operation/data), token (policies/meta), and identity (entity/groups) — is stable.

• request: path, operation (read/create/update/delete/list/sudo, etc.), data (the input for write operations)
• token: policies (attached policies), meta (arbitrary KV pairs such as team or change_window)
• identity: entity (ID/aliases), groups (name/ID)
• Standard libraries such as time and strings: handy for time-window checks and string prefix matching

Scoping EGP paths (example)

# To evaluate it only on mutations (create/update/delete),
# condition on the operation inside the policy itself.
# Keeping the path broad and narrowing by operation in Sentinel is easier to maintain.

vault write sys/policies/egp/kv-change-guard \
  [email protected] \
  enforcement_level=hard-mandatory \
  paths="kv/*"

Practical Policy Example: Block Out-of-Hours Writes with a Metadata Gate

The example below permits mutating operations on KV paths under prod (e.g., kv/data/prod/...) only when the request is inside business hours and the token carries the metadata change_window=daytime. Reads are always allowed.

Operationally, you would pair this with a process that issues a token carrying this metadata only after a change advisory board (CAB) approval, for example.

• Time-of-day control is implemented with the standard time library
• Reads are always allowed; only write/update/delete are gated
• Metadata is attached by the issuance flow so that requests remain auditable

Sentinel (EGP) sample: gate prod KV writes by time of day plus metadata

import "strings"
import "time"

# Business hours (09:00-18:00)
allowed_write_window = rule {
  time.hour(time.now()) >= 9 and time.hour(time.now()) < 18
}

# Is it a mutation on KV under prod?
is_prod_kv_write = rule {
  strings.has_prefix(request.path, "kv/data/prod/") and
  (request.operation == "create" or request.operation == "update" or request.operation == "delete")
}

main = rule {
  if is_prod_kv_write {
    allowed_write_window and token.meta["change_window"] == "daytime"
  } else {
    true
  }
}

Composition Strategy in Production: ACL + Control Groups + Sentinel

Build the foundation with least-privilege ACLs, layer Control Groups on top for multi-party approval of critical operations, and add conditional Sentinel guards above that — this is both safe and realistic. High-risk operations such as issuing root tokens, long-lived PKI certificates, or transit key operations should be guarded with hard-mandatory.

The standard rollout pattern is to start with advisory to observe impact, move to soft-mandatory, and then escalate to hard-mandatory in stages. When using Namespaces, validate thoroughly in lower environments before promoting upward.

• Phased rollout: advisory → soft-mandatory → hard-mandatory
• Pair Control Groups with Sentinel for high-risk operations (multi-party approval plus conditional guards)
• Apply changes per Namespace to keep the blast radius small
• Keep explicit exceptions (e.g., break-glass users) to a minimum and always pair them with heightened auditing

Escalating the enforcement level in stages (example)

# Start with advisory
vault write sys/policies/egp/kv-change-guard \
  [email protected] \
  enforcement_level=advisory \
  paths="kv/*"

# Move soft -> hard once the behaviour looks right
vault write sys/policies/egp/kv-change-guard \
  [email protected] \
  enforcement_level=soft-mandatory \
  paths="kv/*"

vault write sys/policies/egp/kv-change-guard \
  [email protected] \
  enforcement_level=hard-mandatory \
  paths="kv/*"

Testing and Debugging: Verifying Safely

Sentinel can be unit-tested with its standalone CLI. Prepare mock inputs that mimic Vault's evaluation context (request/token/identity) and use sentinel apply/test to confirm the policy evaluates as expected. On the Vault side, the safe move is to roll out with advisory first and watch hits in the audit log.

Use Sentinel's -trace option to step through each branch and rule truth value when tracing an evaluation failure.

• Test locally with the Sentinel CLI → apply in a lower Namespace as advisory → escalate in stages
• Cross-reference audit logs with related IDs (path/operation/entity) to surface false positives
• Always test boundary times (e.g., 9:00 / 18:00) and how DST is handled

Local verification with mock input (example)

# Save policy.sentinel (the example above) locally
# mock.json: a simple stand-in for Vault's evaluation context
{
  "request": {
    "path": "kv/data/prod/app1",
    "operation": "update",
    "data": {"key":"value"}
  },
  "token": {
    "meta": {"change_window":"daytime"}
  },
  "identity": {
    "entity": {"name":"alice"},
    "groups": ["devops"]
  }
}

# Run the test (adjust the paths)
sentinel apply -trace policy.sentinel -json mock.json

Exam Tips (Ops Focus)

The exam frequently tests the division of labor between ACL and Sentinel, what EGP and RGP each apply to, and the differences between enforcement levels and how to use them in practice. Lock in the basics: a request that passes ACL can still be denied by Sentinel, and hard-mandatory is, as a rule, non-overridable.

Be ready for operationally-flavored questions too: the rollout flow (advisory → observe → escalate), using token metadata and Identity-based conditions, and verifying behavior via audit logs.

• ACLs grant capabilities; Sentinel is the final gate for runtime conditions
• EGP covers endpoints in general; RGP is specialized for role-bound operations
• The differences between advisory/soft/hard and a canonical use case for each
• Best practices for phased rollout and audit-log utilization

Checking and deleting policies (operations the exam likes to ask about)

# Check the policies you created
vault read sys/policies/egp/kv-change-guard
vault read sys/policies/rgp/pki-ttl-guard

# Delete
vault delete sys/policies/egp/kv-change-guard
vault delete sys/policies/rgp/pki-ttl-guard

Check Your Understanding

Frequently Asked Questions