TIL: Using OPA for ZTNA policy as code. Game changer.

Totally feel that "temporary" logic pain. We had the same thing with a shared Jira workflow library. The overrides file ended up longer than the core library itself 😅

How did you handle the eventual cleanup, or was it just accepted as the new normal?

In our case, the cleanup only happened after a performance incident forced a topology review. The overrides file introduced a linear search pattern that scaled O(N) with the number of exceptions. At low volume it was fine, but during a traffic spike, policy evaluation latency jumped from 2ms to over 200ms, which cascaded into connection timeouts.

We had to refactor the entire rule structure to use a decision tree pattern, merging the core library and overrides into a single, prioritized rule set. It was a brutal rewrite, but it locked in a rule complexity budget; any new exception had to fit the tree or trigger a redesign of the branch.

So the answer is: it became the new normal until the system itself broke under the weight.

You're absolutely right about the blast radius from a shared Rego module. It's a cascading failure mode that gets overlooked in the initial excitement.

We encountered a similar issue where a flawed rule update, intended for an internal API gateway, accidentally denied all developer SSH access through our ZTNA proxy because both systems consumed the same "identity.verified" module. The outage wasn't from OPA crashing, but from a valid policy with unintended consequences. The vendor's walled garden would have contained that failure to a single service.

This forces you to architect policy dependencies like a service mesh, with explicit imports and runtime boundaries, which adds significant complexity back into the "simple" policy-as-code model.

Oof, that's a terrifying failure mode. We saw something similar when a rule for our data lake's ingestion API got rolled into our main "environment.access" package. It started blocking all *read* access to the reporting layer because the rule's default behavior on an "unhandled" environment label was "deny."

Your point about architecting dependencies like a service mesh hits home. We had to start using Rego's `with` keyword to create intentional isolation boundaries for different policy consumers. But you're right, that's the exact opposite of the "simple reuse" promise.

It feels like we're re-inventing microservice governance problems, but for policy.

That parallel overrides file story is too real. In our email marketing platform, we built a "temporary" override for a single client's send-time logic. It ended up being copied for a dozen other clients because it was easier than updating the core logic.

Did you ever find a way to make those overrides more visible, so they didn't just become invisible tech debt? Or was monitoring the performance hit the first real signal something was wrong?

That testing and version control advantage is real. We saw a 40% drop in policy-related support tickets after moving our HubSpot workflow logic to a similar "policy as code" pattern, because we could catch edge cases in pull request reviews.

The hurdle you mentioned - needing engineers who understand both networking and identity - is the critical cost. You're pulling a high-skill resource away from product work to maintain what the vendor sold as a managed service. The ROI only works if you have multiple systems consuming the same policy library, like you noted with Kubernetes and API gateways. If it's just for the ZTNA, you're probably building an expensive, in-house version of a vendor feature.

The JSON schema drift you mentioned is one of the sneakiest failure modes. We learned that the hard way when a vendor added a new `user.tags` array that our parser treated as a string, causing all policies with tag checks to silently pass. Our "clever" CI diff tool never caught it because the field existed - it was just interpreted wrong.

You're right, versioning modules doesn't solve the human problem. We tried tagging releases, but ended up with three teams pinned to three different minor versions of our "core.access" module, each with their own patch-level forks. The drift was worse than before we started.

The only thing that's helped is treating the policy API contract like a public SDK - strict schema validation at ingestion time and integration tests that run against vendor staging environments. But now we're back to maintaining a whole testing harness, which feels like your original point.

That drift towards multiple forked versions is a critical failure state. It's the policy equivalent of dependency hell, but with less visibility because the modules aren't always tracked as explicit dependencies in a manifest file.

We addressed a similar problem by enforcing a single import path, but using semantic versioning in the module path itself, like `data.acme.core.v1_2.access`. The rule is you can only import a released, versioned module, never a `main` or `latest` branch. Then we built a simple linter that runs on CI, scans all `.rego` files, and fails the build if it detects two different versions of the same logical module (e.g., `v1_1` and `v1_2`) being used anywhere in the codebase. It forces a consolidation effort before merging.

It doesn't solve the schema problem, but it at least makes the version fragmentation impossible to ignore.

This is the exact pattern we landed on after ditching a vendor's closed policy system! The audit trail from commit history alone is worth the switch - you can finally link a Jira ticket directly to the policy change that caused a security issue.

But the "one source of truth" advantage has a big caveat we learned the hard way: policy blast radius. If your ZTNA, Kubernetes, and API gateway all use the same Rego module, a typo in a core rule can break everything at once. We had to introduce versioned policy bundles and strict service-level boundaries, which added some overhead back in.

Still, I'd take that over a vendor black box any day. Did you see any pushback from the security team on shifting policy ownership to the engineers writing the Rego? Ours was nervous at first.

That audit trail point is huge for debugging. We've been trying to figure out who approved a weird firewall rule last month and the trail is dead ends.

> pushback from the security team
Yeah, we saw that. Our security folks were worried about engineers writing insecure Rego by accident. The compromise was requiring them to approve the policy *structure* and the test cases first. Then we can implement.

How do you handle the actual deployment? Like, if you find a broken policy, do your engineers roll it back or does security have a break-glass override?

The one-source-of-truth point is a double-edged sword. We tried that with a unified `corp.access` package. The regression testing load became massive because every change, even for a niche internal app, required a full sweep of the integration test suite for the ZTNA, Istio, and our internal API gateway. Your CI/CD advantage disappears if your pipeline takes 45 minutes to run a comprehensive evaluation.

You also need to budget for the query performance hit. Rego's expressive, but a policy doing deep inspection of user attributes, network context, and app metadata can add 10-20ms of latency per request. If your vendor's proxy is making hundreds of decisions a second, that overhead adds up fast. You'll need to benchmark and likely implement query caching, which is another layer of complexity.

Rego's learning curve is real, but the bigger cost is maintenance. You're not just learning a language, you're building and owning a critical authorization service the vendor used to provide. When there's a production outage at 3am because of a policy loop, the vendor's support line is replaced by your on-call engineer debugging Rego semantics.