Vault Enterprise RGP (Role Governing Policy): Designing and Implementing Role-Level Control

RGP (Role Governing Policy) is a type of Sentinel policy in Vault Enterprise that imposes additional governance (conditions such as time of day or network) on tokens issued from a specific authentication role.

The standard practice is to define functional permissions with ACL policies and narrow them down by context with EGP/RGP. This article summarizes how to think about RGP from an Ops perspective, implementation steps, comparison points, and key tips for exam preparation.

RGP Overview and Prerequisites

RGP (Role Governing Policy) is a Vault Enterprise-only feature that applies policies written in the Sentinel language at the authentication-role level. Once ACL defines "what can be done," RGP is a complementary layer that narrows down "when, from where, and under what conditions it is allowed." RGP does not expand permissions; it denies requests that do not meet the conditions.

RGP applies to roles defined on each authentication method such as AppRole, Kubernetes, and AWS. It is evaluated against requests from tokens issued by the target role. This allows you to separate governance per subject with different characteristics, such as humans vs. machines or CI vs. production apps.

• Enterprise-only feature (not in the OSS version)
• Complements ACL with finer-grained context-based control
• Applied per authentication role (e.g., auth/kubernetes/role/web)
• Cannot expand permissions; can only add denials
• In Ops, role design and RGP binding determine operational quality

Differences Between ACL, EGP, and RGP (What to Constrain with Which)

Vault access control is layered. ACL defines basic permissions (read/write/list, etc.) at the path level. EGP attaches context conditions to endpoints (paths), and RGP attaches conditions to tokens originating from an authentication role. In operations, it is safer to define "what can be done" with ACL and narrow down "when/where/who is allowed" with EGP/RGP.

On certification exams, questions that ask "which layer should constrain it" based on use cases are common. The standard approach is to separate conditions that depend on the subject (role) — such as time of day or source network — into RGP, and conditions that depend on the path into EGP.

• ACL: defines path x capabilities
• EGP: conditions on paths (e.g., writes to target endpoints only during business hours)
• RGP: conditions on roles (e.g., CI role tokens can only read production paths)

Multi-layer governance in a Vault request (conceptual diagram)

RGP Evaluation Scope and Application Considerations

RGP is evaluated against requests from tokens issued by the specified authentication role. It does not apply to unauthenticated endpoints or tokens unrelated to the target role. If the evaluation result is deny, the operation is denied even if ACL allows it.

Operationally, making roles too coarse widens RGP's blast radius and increases unintended denials. Splitting them too finely bloats role management. Designing roles and RGPs together per boundary (human/machine, CI/production, Prod/Non-Prod) makes impact easier to predict.

• RGP is a mechanism that adds "deny" context per target role
• Not evaluated for unauthenticated requests or tokens from non-target roles
• Designing role granularity with blast radius in mind is critical
• When updating roles, also review the RGP target list for safe operation

Role-Level Control Patterns (Real-World Use Cases)

Requirements like the following are well-suited to per-role control with RGP. Implement "when/where/who" conditions that are hard to express via ACL, tailored to the nature of each role.

Time- and network-dependent requirements tend to have optimal conditions that vary by environment (prod/staging) and subject characteristics (human/machine), so combining role separation with RGP is effective.

• Writes allowed only during business hours (e.g., manual operations roles)
• Source CIDR restrictions (e.g., allow only internal IPs / specific VPC)
• MFA attribute requirements for high-risk operations (e.g., humans-only)
• CI role: read-only on production paths, writes limited to staging
• Audit/operations roles limited to specific namespaces

Create, Apply, and Verify an RGP (Hands-On)

As an example, add a governance rule of "writes only allowed weekdays 9:00 to 18:00" to a human-facing Kubernetes role. Assume ACL already grants the necessary capabilities (read/write, etc.), and use RGP to deny writes outside the allowed time window.

RGP can be configured with enforcement_level as soft-mandatory (allow with a warning on violation) or hard-mandatory (deny on violation). For phased rollout, observe the impact under soft, confirm there are no issues, and then switch to hard — this is the practical approach.

• Define conditions in a Sentinel file
• Create the policy at sys/policies/rgp
• Apply by specifying the target role
• Verify with a token from the target role
• Phased rollout is safer going soft to hard

Defining and applying an RGP (example: writes only during business hours)

# 1) Sentinel policy (office-hours.sentinel)
import "time"

main = rule {
  # Current time (be aware of server timezone / UTC)
  t = time.now()

  # Allow only weekdays from 09:00 to 18:00
  weekday = t.weekday
  in_office_hours = t.hour >= 9 && t.hour < 18
  is_weekday = weekday >= 1 && weekday <= 5  # 1=Mon ... 5=Fri

  # Narrow to write operations only (this policy does not deny reads, etc.)
  write_ops = ["create", "update", "patch"]
  is_write = rule { request.operation in write_ops }

  # For writes, the time window must be satisfied.
  # Non-write operations (read/list, etc.) are not denied by this RGP.
  (is_write and (is_weekday and in_office_hours)) or (!is_write)
}

# 2) Create the RGP (Enterprise only)
# Example: apply with hard-mandatory. Soft is recommended first.
vault write sys/policies/rgp/office-hours \
  [email protected] \
  enforcement_level=hard-mandatory \
  roles="auth/kubernetes/role/human-ops"

# 3) Verify
# Authenticate with the target role and attempt a write outside business hours - it will be denied
# During the allowed window, ACL-permitted operations succeed
# Confirm the RGP-driven deny in audit logs

Ops Exam Tips and Pitfalls

Remember that RGP is "context control on tokens originating from a role." EGP is per-path, and ACL provides base permissions. Exams test your ability to quickly tell "what to constrain — subject or path?" from the use case.

Phased introduction (soft-mandatory to hard-mandatory), understanding the blast radius (inventory target roles), and verification in audit logs (confirm deny reasons) are Ops fundamentals. Watch out: forgetting to update RGP targets when consolidating/renaming roles easily causes unexpected denies.

• RGP does not "expand" permissions; it only adds deny conditions
• Subject-driven (role-driven) conditions go to RGP; path-driven go to EGP
• Use enforcement_level wisely (observe with soft, then enforce with hard)
• Blast radius scales with role design; separation per boundary is effective
• Plan rollouts assuming observability via audit logs

Check Your Understanding

Frequently Asked Questions