Runtime Boundary and Scope of Responsibility
EnforceAuth is a control plane. Runtime authorization is synchronous and customer-operated. This page defines what that means for availability, support, and blast radius.
Two paths customers often conflate
| Path | Synchronous? | Who operates it | Failure typically looks like |
|---|---|---|---|
| PEP → PDP (app → OPA/EOPA) | Yes — every authorization check | Customer | Production impact if the PEP fails closed (deny / error) |
| OPA → bundle storage (poll) | No — background | Customer PDP; EnforceAuth writes the artifact | Stale policy after prior activation (usually not an outage) |
| OPA → EnforceAuth API (decision logs / status) | No — telemetry | Customer PDP → EnforceAuth | Observability gap; console and fleet views degrade |
Only the first row sits on the request path for end-user traffic.
What EnforceAuth owns
- Policy build, test, promote, and rollback
- Publishing bundles to your bundle destination
- Decision log and fleet status ingestion and console evidence
- APIs and UI for governance, deployments, and audit
EnforceAuth does not proxy, host, or guarantee availability of the synchronous PEP → PDP evaluation path in the standard (customer-operated PDP) model.
What you own
- OPA / EOPA process health, capacity, and HA
- Network connectivity from your PEP to your PDP
- How your PEP behaves when the PDP is unreachable (fail closed vs fail open)
- Timeouts, retries, and how authorization errors surface to end users
- Bundle polling configuration and first-boot activation before traffic
Production impact vs control-plane impact
| Event | Live authorization (PEP → PDP) | EnforceAuth console / API |
|---|---|---|
| EnforceAuth SaaS unavailable | Continues with the last activated bundle on your PDPs | Deploy, logs, and fleet status may stop |
| Bundle storage down after activation | Continues with stale policy | New publishes may fail |
| PDP unreachable / down | Stops or denies per your PEP | Fleet health / log gaps may appear first |
| New pod never activated a bundle | Deny / undefined until first successful poll | Deploy may show Success while PDP is not ready |
Deployment pattern and blast radius
Your deployment pattern determines how far a PDP failure spreads:
- Sidecar — typically one pod (or replica set) when that sidecar fails
- Host daemon — all local PEPs on that machine
- Centralized PDP — fleet-wide; HA and failover are required before production
Sidecar is the usual recommendation when you want to limit production blast radius.
Visibility vs operation
EnforceAuth helps you see PDP problems (PDP Monitoring, status plugin, decision log gaps). Visibility is not the same as operating your PDP fleet. Unless you have a separately contracted managed-runtime offering, PDP availability remains your operational responsibility.
Before you escalate production-down
- Can the PEP reach the PDP? (
OPA_URL, sidecar health, network policy) - Has the PDP activated a bundle at least once? (
/v1/statusbundles) - Is the failure deny-by-policy or PDP unavailable? (decision logs / PEP error handling)
- Is EnforceAuth API down while local evaluation still works? (control plane vs data plane)