Policy as Code

4 open source tools compared. Sorted by stars. Scroll down for our analysis.

Tool	Stars	Velocity	Language	License	Score
opa Open Policy Agent (OPA) is an open source, general-purpose policy engine.	11.9k	-	Go	Apache License 2.0	73
kyverno Unified Policy as Code	7.9k	-	Go	Apache License 2.0	69
gatekeeper 🐊 Policy Controller for Kubernetes	4.2k	-	Go	Apache License 2.0	59
conftest Write tests against structured configuration data using the Open Policy Agent Rego query language	3.2k	-	Go	-	51

Stay ahead of the category

New tools and momentum shifts, every Wednesday.

Our Analysis

opa11.9k★

OPA, the Open Policy Agent, is a general-purpose policy engine: you write rules in a language called Rego, and OPA evaluates them to make yes-or-no decisions for anything that asks. Should this Kubernetes pod be allowed? Can this user call this API? Is this Terraform plan compliant? One engine, consistent policy across your whole stack. Open source and free, a graduated CNCF project. It runs as a service or a library that your applications and infrastructure query at decision points. The power is decoupling policy from code: instead of hardcoding rules into every service, they live in Rego and OPA answers the questions. Rego takes real effort to learn, and that's the honest cost of the flexibility. Setup is easy, getting good at Rego is not. OPA is free. Styra, founded by OPA's creators, sells Styra DAS: a commercial control plane for managing policies, distribution, and monitoring across a large environment. Solo and small teams, raw OPA, or Gatekeeper if your only use case is Kubernetes. Large orgs running policy everywhere, Styra DAS is the management layer. The catch: Rego is the barrier. It's a declarative logic language that thinks differently from normal code, and the learning curve is steep enough that teams often stall. If your only need is Kubernetes admission control, Gatekeeper or Kyverno wrap OPA-style policy in something friendlier. Reach for raw OPA when you genuinely need one policy engine across many systems.

kyverno7.9k★

Kyverno is policy-as-code built specifically for Kubernetes, and its big selling point is that policies are just YAML, not a separate language. Want to require every pod to have resource limits, block images from untrusted registries, or auto-add labels? You write a Kubernetes-native policy resource and Kyverno enforces it. Open source, a CNCF project, free. It runs as an admission controller in your cluster, checking or mutating resources as they're created. Because policies look like the Kubernetes YAML your team already writes, adoption is far gentler than learning Rego. It can validate, mutate, and generate resources, and it can verify image signatures from Cosign to enforce a signed-images-only rule. Kyverno is free. Nirmata, which drives much of its development, sells a commercial platform for managing policies across many clusters. Solo and small teams, Kyverno alone covers Kubernetes policy cleanly, and for Kubernetes specifically it's often the easier choice over OPA Gatekeeper because there's no new language to learn. Large multi-cluster fleets, the commercial layer helps. The catch: it's Kubernetes-only by design. If you need policy across Terraform, APIs, and CI as well as clusters, OPA is the general engine and Kyverno isn't. That focus is exactly why it's simpler for Kubernetes, but don't expect it to govern anything outside the cluster.

gatekeeper4.2k★

Gatekeeper brings OPA's policy engine into Kubernetes as an admission controller. It enforces Rego-based policies on everything created in your cluster: require labels, block privileged containers, restrict which registries images can come from. It's the official OPA integration for Kubernetes, a CNCF project, open source and free. It runs in-cluster and uses a constraint framework: you install a policy template once, then apply constraints that parameterize it, which makes policies reusable across teams. It also audits existing resources, not just new ones, so you can see what already violates a policy before you start blocking. Setup is a Helm install plus the policy library. Fully free. The real decision is Gatekeeper versus Kyverno. Both do Kubernetes admission control; Gatekeeper uses Rego and inherits OPA's ecosystem and power, Kyverno uses plain YAML and is easier to pick up. If your org already runs OPA elsewhere and wants one policy language, Gatekeeper fits. If Kubernetes is the only target, Kyverno is usually the gentler path. The catch: you inherit Rego. Gatekeeper's power comes from OPA, and so does its learning curve. For simple policies the constraint templates hide most of it, but anything custom drops you back into writing Rego. That's the trade for the flexibility.

conftest3.2k★

Conftest tests configuration files against policies you write in Rego. Point it at a Kubernetes manifest, a Terraform plan, a Dockerfile, or any structured config, and it checks them against your rules and passes or fails. It brings OPA-style policy to the command line and CI, open source and free. It's a single binary built for pipelines: run it in CI to block a merge when a config violates policy, before anything reaches a cluster or a cloud account. Unlike Gatekeeper, which enforces at Kubernetes admission time, Conftest works at the file level anywhere in your workflow, so it fits config that never touches a cluster. Policies are Rego, shared through OCI registries. Fully free, part of the OPA project. It fills the gap between a general policy engine and your CI: the same Rego skills, applied to files instead of live systems. Solo and small teams, a clean way to gate config in pull requests. Larger orgs, pair it with Gatekeeper so the same policy ideas run in CI and at admission time. The catch: Rego again. Conftest is only as useful as the policies you write, and those are in Rego, so the learning curve carries over. And it checks files, not running systems, so a config that passes Conftest can still drift after it's deployed. It's a pre-deploy gate, not runtime enforcement.