Open Policy Agent after CNCF graduation: build policy as a tested decision system.

OPA is designed to evaluate policy against structured input and return a decision. The application, proxy, admission controller, gateway, CI job, or other integrating component remains responsible for enforcing that decision. This separation is powerful because the same policy model can be used across many systems, but it also creates an architectural boundary that needs explicit failure behavior.

Choose failure semantics up front

Some policy paths should fail closed; others may need continuity behavior. The right answer depends on consequence, availability requirement, local caching, bundle freshness, and whether a denial can create its own safety or operational risk. Document the decision instead of inheriting whatever a client library happens to do on timeout.

OPA includes a policy-testing framework and the opa test command. Use it for unit tests that prove allowed behavior, denied behavior, boundary cases, missing inputs, malformed data, role combinations, and exceptions. A policy test suite is most valuable when it protects the cases an author is likely to break during a seemingly unrelated rule change.

package authz

    test_admin_dev_allowed if {
      allow with input as {
        "user": {"role": "admin"},
        "resource": {"environment": "dev"}
      }
    }

    test_admin_prod_denied if {
      not allow with input as {
        "user": {"role": "admin"},
        "resource": {"environment": "production"}
      }
    }
    

Test undefined and missing data

One of the most dangerous policy bugs is disagreement about missing information. Does an absent attribute deny, fall back to a default, or cause an integration error? Write tests for missing identity attributes, unknown resource metadata, incomplete network context, and stale external data.

Test enforcement integration

Unit-tested Rego is not enough. Run integration tests that prove the surrounding application translates the decision correctly. Include OPA unavailable, bundle unavailable, invalid response, timeout, and stale-policy scenarios so the actual fail-open/fail-closed behavior is known before an outage.

Regression-test exceptions

Emergency exceptions tend to outlive their incident. Give exception rules an owner, reason, expiry condition, and tests that make the exceptional path visible. A later cleanup should fail a test if it accidentally broadens the exception rather than removing it.

Make policy changes auditable from request to enforcement.

1. Define the decision interface. Document input schema, output schema, default behavior, enforcement owner, and failure semantics.
2. Assign rule ownership. Security, platform, product, privacy, finance, or another function may own the requirement; the Rego author is not automatically the risk owner.
3. Require code review and tests. Use branch protection and reviewers appropriate to the consequence of the policy. A formatting-only change and a production authorization change should not necessarily have identical approval requirements.
4. Publish immutable revisions. Be able to identify which bundle revision each environment activated and roll back deliberately.
5. Observe decisions. Monitor denies, unexpected allows, undefined decisions, evaluation errors, latency, bundle health, and policy drift. Avoid collecting sensitive input fields simply because logging supports them.
6. Control exceptions. Time-bound waivers, document owners, and measure remaining usage so exceptions can be retired.
7. Reconstruct incidents. Preserve enough policy, data, deployment, and decision evidence to answer why a request was allowed or denied at a particular time.

Primary sources: CNCF OPA graduation announcement, Rego policy language, policy testing, integration guidance, and decision logs.