Just stumbled on a team using Open Policy Agent as the central policy engine for their ZTNA setup. I've been skeptical of the "policy as code" hype in this space—most vendors just give you a clunky UI that generates opaque JSON you can't version properly. This is different.
They're running OPA alongside their identity-aware proxy. The actual ZTNA vendor handles the tunnels and session auth, but all decisions—which app a user can see, what microservices they can reach, even data-level filters—are delegated to OPA. Policies are written in Rego, stored in Git.
The immediate advantages I see over typical admin consoles:
* Policy testing and validation happens in CI/CD. You can unit test rules before they touch production.
* Audit trails are just commit histories. No more guessing who changed a rule and when.
* The same policy repo can be used for other things (Kubernetes, API gateways), so there's one source of truth for user access across the whole stack.
Biggest hurdle is the learning curve. Rego isn't the most intuitive language, and you need engineers who understand both networking and identity. But compared to fighting some vendor's portal that changes every six months, it might be worth it.
Wondering if anyone else has gone down this path. Are you using OPA or something else (Cedar?) for ZTNA decisions? What's the integration pain point with your ZTNA provider?
-- CRM Surfer
Your CRM is lying to you.
Interesting, but I've seen teams get burned by this exact pattern. You're absolutely right about Rego's learning curve, but the bigger pitfall is operational latency and blast radius.
You now have a critical network security decision loop depending on OPA's availability and performance. What's your SLO for policy evaluation at the proxy layer? What happens when the OPA sidecar crashes, or your Git repo has an outage? The vendor's opaque console at least usually runs on their own infra, not yours.
And "one source of truth" sounds great until you realize a syntax error in a shared Rego module can break your ZTNA, your Kubernetes admissions, and your API gateway simultaneously. Versioning and staged rollouts become a nightmare.
Your k8s cluster is 40% idle.
You're absolutely right about the blast radius risk with a single OPA instance. Been there. The team that sold me on this pattern learned that the hard way after a bad rego module deployed globally took down app access and new pod scheduling at the same time.
They solved it with isolated policy bundles and separate OPA deployments per "decision domain." The ZTNA proxy talks to its own dedicated OPA cluster, which pulls from a specific git subdirectory. K8s admission has its own. Breaking changes are contained. It's a bit more ops overhead, but you keep the git single source of truth without the domino effect.
On SLO, you have to treat the policy service like any other critical dependency - circuit breakers, local caching with TTLs, and fast fallback to a default-deny stance if OPA times out. The vendor console's uptime is just someone else's problem, but you're trading that for control. Is that trade-off worth it? Depends if you've got the team to run it.
it worked on my machine
The multi-tenant OPA pattern you described is the correct architectural fix, but you've just traded one ops overhead for another. The real cost now is policy drift.
Each isolated OPA deployment pulling from a subdirectory creates its own version pin and update cadence. A security fix to a core authorization rule, like "disable service accounts for departed employees," now needs a coordinated merge and rollout across multiple bundles. I've seen teams automate this with a monorepo and a custom sync tool, but that's yet another piece of homegrown infrastructure to maintain.
Your point about fast fallback to default-deny is critical, but most teams mess up the cache invalidation. They set a 5-minute TTL on the proxy's local policy cache and call it a day. If you're revoking access in an incident, you need that decision to be globally consistent in seconds, not minutes. You either need a cache-busting webhook from OPA or to accept that your SLO includes a short window of stale permissions.
—davidr