Kubewarden Admission Controller vs Kyverno

Both Kyverno and Admission Controller can write validation, mutation and image verification policies. These policies can target any kind of Kubernetes resource, including Custom Resources.

Kyverno also supports additional policy types that Admission Controller does not provide:

Kyverno has historically used its own Domain Specific Language based on JMESPath and YAML overlay patterns to write policies. This traditional language, used through the ClusterPolicy and Policy Custom Resources, has been deprecated as of Kyverno v1.17 (January 2026) and is planned for removal in v1.20 (October 2026).

The current recommended approach for writing Kyverno policies is CEL (Common Expression Language), used through the new ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy, and ImageValidatingPolicy Custom Resources introduced starting from Kyverno v1.14.

Admission Controller supports writing policies using CEL, the same language now adopted by Kyverno. Both projects can also run native Kubernetes ValidatingAdmissionPolicy (VAP) resources.

In addition, Admission Controller supports writing policies using traditional programming languages (like Go, Rust and others) or other Domain Specific Languages like Rego.

Sometimes a policy needs data about the current state of the cluster to make a validation or mutation decision. For example, a policy validating Ingress resources might need to know other Ingress resources already defined in the cluster to ensure no clashes happen. Admission Controller calls these policies "context aware".

Both Kyverno and Admission Controller support these types of policies.

When deploying Kyverno, a Kubernetes administrator decides which types of cluster data to make available to the policies at evaluation time. However, this data is then accessible by all the policies deployed.

For example, if a Kyverno policy requires access to Kubernetes Secrets, all the other policies deployed are able to read this data as well.

Conversely, Admission Controller provides a granular access to cluster resources. Each policy has access only to the resources that the Kubernetes administrator specifies. Attempting to read unauthorized data is immediately blocked and reported to the cluster administrators.

Both Kyverno and Admission Controller can validate arbitrary JSON data beyond Kubernetes resources.

Kyverno provides this capability through its ValidatingPolicy type, by setting the spec.evaluation.mode field to JSON. See the Kyverno ValidatingPolicy documentation for details.

Admission Controller provides the same capability through raw policies, which can evaluate policies against arbitrary JSON input data without requiring a running Kubernetes cluster.

Kyverno and Admission Controller CEL policies have the source code of the policy embedded in the Custom Resource defining a policy in Kubernetes.

Additionally, Admission Controller policies can have the source code of the policy managed like container images (for Rego, Go, Rust, …​). Once built, they’re pushed into container registries as OCI artifacts.

You can sign and verify Admission Controller policies using container image tools like cosign, from the Sigstore project.

You can distribute Admission Controller policies among geographically distributed container registries using the traditional tools and processes adopted for container images.

Both Kyverno and Admission Controller are managed using GitOps methodologies.

Kyverno provides the kyverno CLI for testing policies in CI/CD pipelines. It includes the kyverno test command for running predefined test cases and the kyverno apply command for testing resources against policies. A GitHub Action is also available for integrating Kyverno CLI into GitHub Actions workflows.

Admission Controller policies have CI/CD pipelines like traditional microservices. Usually their source code lives in a Git repository and then, using traditional CI/CD systems, unit tests run against it. You write unit tests using the testing frameworks of the language used to write the policy. Once all the tests pass, you compile the policy to WebAssembly and push it to a container registry. This kind of pipeline is usually maintained by the policy author.

Kubernetes administrators typically maintain other automation pipelines that react to new releases of the policy (using automation tools like Dependabot, Renovate bot, updatecli and others), or to changes to the policy configuration.

The pipeline tests the policy against different types of requests. You can do the testing using the kwctl CLI tool, without requiring a running Kubernetes cluster. The kwctl CLI tool uses the same evaluation engine used by the Admission Controller stack deployed in a Kubernetes cluster.

Both Kyverno and Admission Controller can deploy policies using two different operation modes:

Kyverno runs as a set of Kubernetes Deployments (admission controller, background controller, reports controller, cleanup controller). The admission controller handles all policy evaluations. While it supports running multiple replicas for high availability, all replicas evaluate all policies. There is no way to assign specific policies to specific instances.

Conversely, Admission Controller allows definition of multiple evaluation servers. You define these servers by a Custom Resource called PolicyServer.

When declaring a Admission Controller policy, the Kubernetes administrator decides which PolicyServer host it.

This allows interesting scenarios like the following ones:

As policies are added, removed, and reconfigured the resources already in the cluster might become non-compliant.

Both Kyverno and Admission Controller have a scanner that operates in the background. This scanner evaluates resources already defined in the cluster and flags non-compliant ones.

Kyverno stores the results in PolicyReport and ClusterPolicyReport Custom Resources following the format defined by the Kubernetes Policy working group. As of Kyverno v1.15, alpha support for openreports.io is also available.

Admission Controller stores the results inside of a set of the Reports Custom Resources defined by openreports.io.