Governance: Sentinel, control groups & namespaces

Policy-as-code guardrails, four-eyes approval, and hard multi-tenancy.

ACL policies answer "can this identity touch this path?" Governance answers the harder questions: "should this action be allowed given the context?", "does it need a second approver?", and "how do we keep tenants truly isolated?" This is where secrets management meets policy-as-code and change control. The tools differ by product tier, but the patterns — conditional guardrails, multi-party approval, and hard multi-tenancy — are universal and worth designing for even if you implement them differently.

Conditional guardrails: Sentinel and OPA

ACLs are allow/deny on paths; guardrail policies add logic on top. Vault Enterprise’s Sentinel (and OPA-based equivalents in other systems) can enforce rules like "root-token generation only from the corporate CIDR", "no secret reads outside business hours for this role", or "MFA required for this mount." These are role-governing policies (evaluated on every request) and endpoint-governing policies (attached to specific paths). The point is that authorization becomes contextual — the same identity and path can be allowed or denied based on when, where, and how the request arrives.

import "sockaddr"
import "mfa"
 
# only from the corporate CIDR
cidr = rule { sockaddr.is_within(request.connection.remote_addr, "10.0.0.0/8") }
 
# and only with a validated MFA method
mfa_ok = rule { mfa.methods.duo.valid }
 
main = rule when request.path matches "secret/data/prod/.*" {
  cidr and mfa_ok
}

Control groups: four-eyes on a secret

Some secrets should never be read by one person alone. Control groups require that a request be approved by one or more other authorizers before the secret is released: the requester asks, the request enters a pending state, designated approvers sign off, and only then can the requester unwrap the value. This is four-eyes for break-glass credentials, production root passwords, or customer-data keys — the audit trail records who asked, who approved, and when, turning a sensitive read into a reviewable event instead of a silent one.

Namespaces: hard multi-tenancy

Templated policy isolates paths within one tenant space; namespaces isolate entire Vaults-within-a-Vault. Each namespace has its own policies, auth methods, secret engines, and identities, delegated to a tenant team that administers it without seeing or touching the others. This is the difference between "soft" multi-tenancy (one policy mistake away from a leak) and "hard" multi-tenancy (a structural boundary). Use namespaces when tenants are true trust boundaries — separate business units, customers, or regulatory scopes — and delegate their administration so the central team is not a bottleneck.