Reference Architectures
These patterns describe how enterprises typically operationalize authorization with EnforceAuth. Each links to deeper guides — use them in architecture reviews and platform standards.
Pattern 1 — Kubernetes microservices (sidecar PDP)
We recommend this for cloud-native application authorization when each service owns its policy slice.
Git (Rego) → EnforceAuth (build, test, promote) → S3/GCS bundle
↓
Pod: App PEP ─localhost─► OPA/EOPA sidecar ─poll/logs─► EnforceAuth
| Question | Guidance |
|---|---|
| Why choose it | Lowest PEP→PDP latency; failure isolated per pod |
| When to avoid | Hundreds of ephemeral functions without orchestration overhead budget |
| Who uses it | Platform teams on EKS/GKE/AKS; product microservices |
| Latency | Sub-millisecond localhost hop |
| Blast radius | One pod; other replicas continue |
| Ops complexity | Medium — manifests, API keys, staggered bundle polling |
| Failure behavior | Stale bundle until next successful poll; sidecar crash affects one pod |
→ Deployment patterns § Sidecar · Kubernetes Control Center
Pattern 2 — Centralized PDP for polyglot fleets
Typically best suited when many languages share one policy revision and a network hop is acceptable.
Many PEPs (Java, Python, Node, …) ─HTTP─► OPA/EOPA cluster (HA) ─► EnforceAuth logs
| Question | Guidance |
|---|---|
| Why choose it | One upgrade path, one bundle poll cycle, language-agnostic HTTP |
| When to avoid | Strict sub-ms SLOs or air-gapped per-service isolation requirements |
| Who uses it | Enterprises with diverse stacks and platform SRE ownership |
| Latency | One network round trip per decision |
| Blast radius | Fleet-wide if the PDP pool is down — plan HA and health checks |
| Ops complexity | Higher — scaling, mTLS, capacity planning |
| Failure behavior | All callers denied until recovery unless you cache last-known decisions in PEP |
→ Deployment patterns § Centralized
Pattern 3 — Regulated workloads (EOPA + masking)
Consider this when decision logs must not carry raw PII outside your network.
Same control plane as Patterns 1–2, with EOPA masking at the PDP before decision_logs ship
| Question | Guidance |
|---|---|
| Why choose it | Native decision_logs.mask at evaluation time |
| When to avoid | Greenfield teams with no masking mandate — start with OSS OPA |
| Who uses it | Healthcare, financial services, data-residency-sensitive tenants |
| Latency | Same as chosen deployment pattern |
| Blast radius | Same as chosen deployment pattern |
| Ops complexity | Add mask path maintenance and regression tests |
| Failure behavior | Masking misconfiguration can block log shipping — test in lower environments |
→ OPA vs EOPA · PDP integration § EOPA
Pattern 4 — AI agents and MCP tool governance
Use when autonomous agents call enterprise MCP tools (filesystems, APIs, databases) and you need policy + audit at the tool boundary.
Agent ─MCP─► MCP Authorization Gateway (PEP) ─► OPA ─► EnforceAuth bundle + decision logs
EnforceAuth documents this as the MCP Authorization Gateway pattern. Our reference implementation and baseline starting point is PortcullisMCP from PAC.Labs — Gate, Keep, and Guard components with allow / deny / escalate semantics.
→ MCP Authorization Gateway · AI workload guardrails
Pattern 5 — Cluster admission (platform governance)
Separate from app authz — gates Kubernetes resource shape at admission time.
→ Kubernetes Control Center § Cluster admission
Choosing a pattern
| Your primary workload | Start here |
|---|---|
| Kubernetes microservices | Pattern 1 |
| VMs / bare metal | Host agent |
| Polyglot HTTP callers | Pattern 2 |
| HIPAA / PCI decision-log rules | Pattern 3 |
| AI agents + MCP tools | Pattern 4 |
| Platform security baseline | Pattern 5 |