Open Policy Agent (OPA) is a declarative policy engine for making decisions about data. Supply JSON input and requirements written in Rego; OPA evaluates them to produce a policy decision. The same approach can serve governance needs beyond Kubernetes. section 4.2.1 section 4.1.1
For a development team that owns its deployment pipeline, compliance checks embedded in a centrally managed pipeline would undermine autonomy. An admission controller instead checks a requested change at the deployment boundary. OPA can provide the policy engine for that check, allowing teams to retain their pipelines while shared requirements remain enforceable. section 4.2 section 4.4
Build a policy gate incrementally:
- Choose a requirement that can be checked against the requested change, such as whether a Kubernetes deployment has labels needed for cost tracking. section 4.1.1
- Identify the data needed for the decision. OPA can use data included with its deployment or fetched when the policy runs. section 4.2.1
- Express the requirement as Rego assertions and test both approval and rejection. For example, a coverage rule can compare a deployment’s source identifier with code-quality data and deny coverage below 80%. section 4.2.1
package test #1
default allow := false #2
allow if user_is_over_12 #3
user_is_over_12 if { #4
data.user_attributes[input.user].age > 12
}
This small Rego policy defaults to denying access, then allows it when a predicate finds that the input user’s recorded age exceeds 12. It makes the relationship between input, stored data, and decision visible before applying the same pattern to deployment controls. section 4.2.1
Gatekeeper offers a Kubernetes admission controller based on OPA and Rego, but formats policies more like Kubernetes resources. If policies will span multiple disciplines, decide early whether that format and its distribution assumptions fit a shared policy standard; differences can create friction later. section 4.1.1
