Four options for enforcing policy as code in a Kubernetes cluster, evaluated on learning curve, feature breadth, Kubernetes-native fit, community health, and how much ongoing maintenance you are taking on.
OPA / Gatekeeper
| Criterion | Score |
|---|---|
| Learning curve | 4 / 10 |
| Feature breadth | 8 / 10 |
| Kubernetes-native fit | 6 / 10 |
| Community health | 8 / 10 |
| Ops overhead | 5 / 10 |
- OPA is a general-purpose policy engine originally built for service mesh, API gateways, and CI/CD; Gatekeeper is the Kubernetes admission controller wrapper on top of it
- Policies are written in Rego, a purpose-built declarative language that has a steep learning curve and is genuinely difficult to debug — most engineers need dedicated training to write non-trivial rules
- Gatekeeper handles validation only; mutation support was added later and remains limited compared to other options
- No native resource generation — you cannot use Gatekeeper to create dependent resources in response to policy events
- Two separate projects to track, update, and understand (OPA and Gatekeeper), which adds operational surface
- OPA itself is a CNCF graduated project with strong backing; Gatekeeper is actively maintained by a healthy community
- The Rego investment pays off if you need unified policy enforcement across Kubernetes and non-Kubernetes systems (APIs, microservices, Terraform) from a single language
Stay on OPA/Gatekeeper if you have existing Rego expertise or if cross-stack policy unification is a hard requirement.
Kubewarden
| Criterion | Score |
|---|---|
| Learning curve | 5 / 10 |
| Feature breadth | 7 / 10 |
| Kubernetes-native fit | 7 / 10 |
| Community health | 6 / 10 |
| Ops overhead | 6 / 10 |
- Policies compile to WebAssembly (WASM) modules, which means you can write them in Rust, Go, or any language with a WASM target — a genuine differentiator for teams with existing language preferences
- The WASM compilation and module distribution workflow adds a build step that most policy workflows do not need and most platform teams do not want to own
- Supports validate and mutate; resource generation support is limited
- PolicyReports are produced in the standard Kubernetes format, which integrates cleanly with dashboards
- Smaller community and slower release cadence than Kyverno or OPA/Gatekeeper; fewer production case studies
- Depends on a controller manager plus an audit scanner plus a policy server, which is more moving parts than the problem warrants for most clusters
Worth considering for teams that already invest in WASM tooling or want to distribute policies as OCI artifacts without learning a policy-specific language.
jsPolicy
| Criterion | Score |
|---|---|
| Learning curve | 6 / 10 |
| Feature breadth | 5 / 10 |
| Kubernetes-native fit | 5 / 10 |
| Community health | 2 / 10 |
| Ops overhead | 5 / 10 |
- Policies are written in JavaScript or TypeScript and executed in a V8 sandbox — execution is fast and the language is familiar to a wide audience
- The project is maintained by Loft Labs and has seen no meaningful releases or community activity since mid-2024; it should be treated as effectively unmaintained
- No path to CNCF graduation; not on any active roadmap; the GitHub repository has stalled issue backlogs and no active maintainer engagement
- Supports validation and mutation but not resource generation or image signature verification
- Running an unmaintained admission controller in a production cluster is a security liability — admission webhooks intercept every API request, and an unpatched webhook is a significant attack surface
Do not adopt jsPolicy for new deployments. Teams running it should be planning a migration.
Kyverno ✦ recommended
| Criterion | Score |
|---|---|
| Learning curve | 9 / 10 |
| Feature breadth | 10 / 10 |
| Kubernetes-native fit | 10 / 10 |
| Community health | 9 / 10 |
| Ops overhead | 8 / 10 |
- Policies are Kubernetes resources —
ClusterPolicyandPolicyobjects written in YAML, managed withkubectl, versioned in Git, and applied with Kustomize or Helm like any other manifest - No new language to learn; engineers already fluent in Kubernetes YAML can write functional policies on day one
- Supports the full policy lifecycle: validate, mutate, generate, clean up, and verify image signatures — all from a single engine with a consistent resource model
- Native image verification against Cosign and Notary signatures, with
ImageValidatingPolicyas a dedicated CRD (as of 1.14), covering software supply chain security without an additional tool - Resource generation allows policies to create dependent resources automatically — default NetworkPolicies on namespace creation, for example — which no other tool in this group handles as cleanly
- Automatically generates rules for Pod controllers (Deployment, StatefulSet, DaemonSet) from a single Pod-level policy, removing a whole class of coverage gaps
- PolicyReports are generated automatically and integrate with Policy Reporter for dashboards and alerting
- CNCF incubating project with active development: 1.15 shipped in August 2025, 1.16 in November 2025; over 850 merged changes across 70+ contributors in the 1.15 cycle alone
- CLI supports offline policy testing in CI/CD pipelines against local manifests before anything reaches a cluster
- The new CEL-based policy types introduced in 1.14–1.16 align with native Kubernetes
ValidatingAdmissionPolicyandMutatingAdmissionPolicy, giving a migration path toward in-server validation for performance-sensitive rules while keeping the Kyverno authoring experience
The only meaningful limitation is that Kyverno is purpose-built for Kubernetes and cannot enforce policy across non-Kubernetes systems — if cross-stack Rego reuse is genuinely required, OPA remains the answer.
Criteria comparison
| OPA / Gatekeeper | Kubewarden | jsPolicy | Kyverno | |
|---|---|---|---|---|
| Policy language | Rego | Rust / Go / WASM | JavaScript / TypeScript | YAML (CEL in newer types) |
| Validate | ✓ | ✓ | ✓ | ✓ |
| Mutate | Limited | ✓ | ✓ | ✓ |
| Generate resources | ✗ | ✗ | ✗ | ✓ |
| Image verification | ✗ | ✗ | ✗ | ✓ (Cosign + Notary) |
| Auto-gen for Pod controllers | ✗ | ✗ | ✗ | ✓ |
| PolicyReports | ✓ | ✓ | ✗ | ✓ |
| CNCF status | Graduated (OPA) | Sandbox | None — unmaintained | Incubating |
| Non-K8s policy use | ✓ | ✗ | ✗ | Limited |
For teams starting fresh, Kyverno is the clear choice — it covers the full policy surface, requires no new language, and has the most active community in this group. Teams with cross-stack Rego investment should evaluate whether that investment justifies staying on OPA/Gatekeeper. Everyone running jsPolicy should migrate.
Top comments (0)