Skip to main content

Reference Architectures & Operating in Production

Overview​

The Architect-track course on how continuous authorization is actually deployed and operated. It covers the five-layer continuous-authorization reference architecture (identity assertion, context, policy evaluation, enforcement, unified audit), the five deployment topologies you choose between (sidecar, centralized, Enterprise-OPA masking, AI-MCP gateway with workload mTLS, and admission controller), the latency budgets each has to hold, the fail-mode decision that every enforcement point must make explicit (fail-closed versus fail-open), and how decision logging with decision_logs.mask turns runtime decisions into durable evidence. A runnable OPA lab models one production decision end to end: a fail-closed default and a masking-aware decision at an AI-MCP gateway.

Who this is for​

Architects and senior platform or security engineers designing a continuous-authorization deployment, both EnforceAuth customers and open-source OPA/Enterprise OPA users. You should already understand how Writ governs and promotes signed bundles from Govern with Writ and how decision logs and decision_logs.mask produce compliance evidence from Decision Logs, Continuous Authorization & Compliance Evidence. This course assumes you can read and write Rego; the lab has you author policy rules.

Outcomes​

By the end of this course you will be able to:

  • Name the five layers of the continuous-authorization reference architecture and say what each contributes to a single decision, from SPIFFE identity assertion through unified audit.
  • Choose among the sidecar, centralized, Enterprise-OPA masking, AI-MCP gateway (workload mTLS), and admission-controller topologies, and state the latency budget and tradeoff each carries.
  • Decide, per enforcement point, whether it should fail closed or fail open, and justify the choice against blast radius and availability.
  • Design a production decision policy with a fail-closed default and a masking-aware decision, and prove with opa test that the field the policy flags for redaction is the field the decision-log mask removes.

Lessons​

  1. The five-layer continuous-authorization reference architecture
  2. Deployment topologies and latency budgets
  3. Fail modes: fail-closed versus fail-open in production
  4. Decision logging, masking, and replay in operations

Hands-on lab​

This course includes a graded lab in lab/. It models the decision a Policy Decision Point returns for one production request at an AI-MCP gateway Policy Enforcement Point: an AI agent, carrying a SPIFFE workload identity over mutual TLS, asking to invoke a tool. The policy has a fail-closed default and a masking-aware decision: it names the sensitive field the audit layer must redact, and a system.log.mask policy removes exactly that field. The policy ships as a starter with the two authorizing reason rules stubbed behind a # TODO(learner) block. Clone the public labs repo and run:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/reference-architectures -v

The starter reports FAIL: 2/11. Implement the two reason rules in lab/policy.rego until it reports PASS: 11/11. Keep iterating until opa test is green.

Certification​

Counts toward the Architect track and is required for it. Certification is a machine-graded practical: the assessment engine gives you a production decision scenario and runs your policy against a HIDDEN opa test suite you never see, checking that your default is fail-closed, that your allow rules match the scenario, and that every field you flag for redaction is actually masked. This lab is practice for that exam, not the exam itself.