Kubernetes Policy Comparison: Kyverno vs. OPA/Gatekeeper
Updated Nirmata Team
Kyverno and OPA Gatekeeper are both CNCF policy engines for Kubernetes admission control. Kyverno writes policies as Kubernetes YAML and can validate, mutate, generate and clean up resources. Gatekeeper writes policies in Rego, is built on the general-purpose Open Policy Agent, and mainly validates. Kubernetes-first teams usually pick Kyverno; teams already using Rego often stay with Gatekeeper.
Editor’s Note: We’re republishing this blog post from a few years back by Chip Zoller because it’s one of our most popular still to this day and we wanted to make it easier to find and read. Enjoy! - Nirmata
With the elimination of Pod Security Policies (PSPs) in Kubernetes v1.25, it is imperative to have insights regarding the future of Kubernetes’ policies. Kubernetes replaced PSPs with a controller called Pod Security Admission, which applies formal controls called Pod Security Standards (PSS). Pod Security Admission is a limited successor. It only works on pods, its messages can’t be configured, its audit logs are hard to reach, and it has no DevOps pipeline. So it’s time to look for alternatives.
Currently, there are two primary choices to replace PSPs: Kyverno and Open Policy Agent (OPA) via Gatekeeper. Kyverno has moved from the CNCF sandbox to the CNCF Incubating project maturity level, while OPA is a CNCF graduate maturity level project. Both are full policy engines and both are strong contenders, but each has different strengths. Read about Kyverno release 1.13 here.
This article pulls together what exists on OPA/Gatekeeper and Kyverno so you can make an informed choice between the two projects.
Note: The text of the article will provide assessments regarding the facets of Kubernetes only.
Which is better, Kyverno or OPA Gatekeeper?
It depends on where your policies live and who writes them. The table sums up the trade-off.
| Capability | Kyverno | OPA Gatekeeper |
|---|---|---|
| Policy language | Kubernetes YAML | Rego |
| Kubernetes-native | Yes | Partial |
| Validation | Yes | Yes |
| Mutation | Built-in | Limited |
| Resource generation | Built-in | No |
| Learning curve | Low | Higher |
| DevOps adoption | High | Moderate |
| Best fit | Kubernetes-first teams | Policy-heavy environments |
When Kyverno is the better choice
Kyverno is the preferred option when:
- Teams want fast policy adoption
- Kubernetes is the primary platform
- Policies need to mutate or generate resources
- Developer experience matters
- GitOps is a core workflow
Where OPA Gatekeeper still fits
OPA Gatekeeper can be a good fit for:
- Organizations already invested in Rego
- Cross-platform policy enforcement beyond Kubernetes
- Highly complex logical policies managed by dedicated policy teams
Even in these cases, many teams still use Kyverno for Kubernetes-specific governance. Moving from Gatekeeper? See 10 reasons why Kubernetes users choose Kyverno over OPA Gatekeeper, the OPA to Kyverno guide and how Wayfair migrated from OPA to Kyverno.
What is a Kubernetes policy?
Kubernetes is a portable, extensible environment for organizing and orchestrating containerized applications within a cluster. Like any policy, a Kubernetes policy codifies a set of rules that apply intent to the environment. If you are new to the idea, start with our policy as code overview.
Pod Security Policy in Kubernetes was a set of mechanisms for validating Pod controls and attributes. But PSP operated on Pods only, which is a setback: production Kubernetes needs control over entities beyond Pods. PSP could also only block or allow the creation of Pods. It had no way to remediate them.
Policy engines such as Gatekeeper and Kyverno go much further. They aren’t limited to Pods, they do more than basic validation, and they give you a framework for governing every kind of control in a Kubernetes environment.
Where do Gatekeeper and Kyverno come from?
The two projects started from different places, and that shapes how each one writes policy.
Gatekeeper
Gatekeeper is an open-source project built through collaboration between several companies, notably Google and Microsoft, and later donated to the CNCF. It is often called “OPA/Gatekeeper” because its third iteration was developed around Open Policy Agent. That iteration added structures for Kubernetes-specific implementations. Gatekeeper works as an extensible, parameterized policy library that can validate and mutate requests.
Open Policy Agent’s distinctive trait is Rego, a specialized programming language. Anyone working with OPA has to learn Rego to write the logic and policy decisions. OPA is also designed to run logic at a high level, so it applies to many kinds of software rather than to Kubernetes alone.
Kyverno
Kyverno is also an open-source policy engine donated to the CNCF; it was created by the founders of Nirmata. Kyverno can validate and mutate, and it adds Kubernetes resource generation. Unlike Gatekeeper, Kyverno was built and refined only for Kubernetes. Its generation ability and architecture set it apart, and unlike other policy managers, Kyverno does not use a unique programming language, making it easier to use.
How do Kyverno and Gatekeeper compare feature by feature?
The three tables below cover technical characteristics, the community around each project, and a few other traits.
Note:
* Beta status
** Not available with all CRDs
*** Separate CLI
Technical characteristics
| Features/Capabilities | Gatekeeper | Kyverno |
|---|---|---|
| Validation | Yes | Yes |
| Mutation | Yes* | Yes |
| Generation | No | Yes |
| Image Verification | No (via extensions) | Yes |
| Image Registry lookups | No (via extensions) | Yes |
| Extensions | Yes | No |
| Policy as native resources | Yes | Yes |
| Metrics exposed | Yes | Yes |
| OpenAPI validation schema (kubectl explain) | No** | Yes |
| High Availability | Yes | Yes |
| API object lookup | Yes | Yes |
| CLI with test ability | Yes*** | Yes |
| Policy audit ability | Yes | Yes |
| Self-service reports | No | Yes |
Community characteristics
| Community/Ecosystem | Gatekeeper | Kyverno |
|---|---|---|
| CNCF status | Graduated (OPA) | Incubation |
| GitHub status (stars, forks, releases, commits) | 2700, 582, 63, 1040 | 2900, 400, 132, 4605 |
| Downloads | 100 million + | 300 million |
| Policy sample library | Yes | Yes |
Miscellaneous characteristics
| Meta/Misc | Gatekeeper | Kyverno |
|---|---|---|
| Programming | Yes | No |
| Use outside Kubernetes | Yes | No |
| Birth | July 2017 | May 2019 |
| Origins | Styra (OPA) | Nirmata |
What are the pros and cons of each?
The tables list features. The lists below sum up the broader points we think decide between the two projects.
Gatekeeper advantages
- Older than Kyverno
- Multiple replicas for scaling and availability are supported
- Holds the ability to express sophisticated and intricate policies
Gatekeeper disadvantages
- Generation of technical debt and consumption of time and energy because of the unique programming language required to navigate within the engine
- Complicated and protracted policies often require various documents for execution
- Functionality limited to validation use cases
- Incipient mutation ability
Kyverno advantages
- Does not require knowledge of a specialized programming language
- Well-developed mutation abilities
- Kubernetes-style framework for policy expression
- Greater flexibility and simplicity with a minimum generation of technical debt
- Supports numerous replicas for availability and scale
- Unmatched generation and synchronizing ability
Kyverno disadvantages
- Not applicable outside Kubernetes
- Newer than OPA but still has a fast-growing community
Why does Rego matter for Kubernetes policy?
Kubernetes is a declarative system. It holds the user’s desired state and runs many controllers that reconcile the observed state with it. As a cloud-native platform, it puts the responsibility for that logic on the platform rather than on the user. Each resource type carries the internal logic needed to move toward its desired condition.
Gatekeeper’s fault lines show up because it needs a purpose-built language to express that logic. The fundamental weakness of Gatekeeper is its dependence on the Rego programming language, which is only compatible with OPA, and OPA is a general policy engine. Gatekeeper exists to adapt OPA into a Kubernetes form factor. Once that is in place, every policy gets its decision logic through Rego.
So added technical debt is inevitable with Gatekeeper. Managing Kubernetes policies in an external DSL takes time and effort, and the process gets complex and tedious. The trade-off is real, though: Rego makes very strong policies possible.
Why does Kyverno fit the Kubernetes model?
Kyverno grew out of a reaction to Gatekeeper’s technical demands. Its policies are declarative and its design is Kubernetes-specific, so it describes and reconciles objects the way Kubernetes does. The decision logic lives in the tool, not with the user. With Kyverno, the ramifications of policy elaboration are thoroughly simplified, making it easier to construct policies.
Add mutation, generation and API lookups, and Kyverno becomes a full automation tool. It can also replace other tools that may be scattered across a cluster or an organization.
That makes it useful to new and experienced operators alike, and it adds to its value as a policy engine. For a hands-on start, see the Kyverno playbook.
Bottom line
Gatekeeper and Kyverno are both capable policy engines, each with its own strengths and weaknesses. Both are a big step up from PSP/PSA. Every operations team should plan to run a policy engine to secure its clusters and simplify Kubernetes management. In the end, users should evaluate and make the most educated decision given their use cases and constraints regarding Kyverno vs OPA for their needs. Readers here know where our allegiance lies, but we also know that different DevOps teams have different needs.
Learn more about Kyverno by Nirmata on this page, or see Nirmata Enterprise for Kyverno. Please reach out to our team with any questions you have after reading this post. You can also request a free demo to see how Nirmata helps DevOps and platform engineering teams.
Frequently asked questions
Does Pod Security Admission remove the need for Kyverno or Gatekeeper?
No. Pod Security Admission applies the Pod Security Standards, but it only works on pods, its messages can't be configured, its audit logs are hard to reach and it doesn't fit into a DevOps pipeline. Kyverno and Gatekeeper govern any Kubernetes resource, and Kyverno can also mutate and generate resources, so most production clusters still need a policy engine.
Can OPA policies be used outside Kubernetes?
OPA itself, yes. Open Policy Agent is a general-purpose engine that evaluates Rego against any JSON input, so teams use it for microservice authorization, CI/CD checks and infrastructure-as-code reviews as well. Gatekeeper is the Kubernetes integration of OPA. Kyverno, by contrast, was built only for Kubernetes, which is why its policies look like Kubernetes resources.
How do I test policies before rolling them out?
Both projects ship a command-line tool. Gatekeeper's testing runs through a separate CLI, gator, which checks constraint templates and constraints against sample objects. Kyverno's CLI runs `kyverno apply` and `kyverno test` against resource manifests, so the same YAML files can be tested locally and in CI before any policy reaches the cluster.
Which engine has the shorter learning curve?
Kyverno, for most Kubernetes teams. Its policies are Kubernetes resources with match and exclude blocks that work like the label selectors engineers already use. Gatekeeper asks authors to learn Rego and to split each policy into a ConstraintTemplate and a Constraint. That pays off for teams that already write Rego for other systems.