Overview

Some companies implement a policy on their Kubernetes clusters to ensure that every configuration and setup is deployed in accordance with applicable rules, to meet sound security standards, and, most importantly, to comply with the ISO 27001 standard, which requires that every running workload meet minimum security standards based on the CIS Benchmark.

Background

GitOps is a common practice found in many organizations. By integrating Kubernetes manifest management—for example, using Helm charts and ArgoCD—the deployment workflow for Kubernetes workloads becomes controllable and auditable. However, does this approach cover everything? Unfortunately, this mechanism only covers the client-side, where in a business-as-usual scenario, users are required to create manifests using templates from provided charts—which sometimes also impose restrictions on helper files.These templates are meant to ensure conventions and governance remain within established guidelines—for example, every deployment must have a “team” tag, or a container image must not use the “latest” tag. However, these mechanisms only enforce compliance on the client-side. The same applies to ArgoCD: ArgoCD only ensures that running workloads align with the declarative manifest stored in the VCS. Although it offers auto-sync and auto-heal features, both still have time intervals that could potentially create security vulnerabilities. So, how can we ensure security not only on the client-side but also on the server-side? What if a user has access to the cluster with a role that allows them to create or modify existing workloads? It’s entirely possible for that user to escalate their privileged access to perform uncontrolled actions. That’s where Kyverno comes in....

Bottom line: Helm’s helpers.tpl and ArgoCD’s self-heal feature bridge the gap between “what’s in Git” and “what’s in the cluster.” However, both assume that the entire resource lifecycle originates from and is controlled solely through the Git → Helm render → ArgoCD apply pipeline. As soon as a resource originates from another path—such as a controller/operator, subchart, runtime debug, a reconciliation time gap, or a tooling compromise—that protection no longer applies. Kyverno closes that gap because it is positioned not within a “specific deployment pipeline,” but within the API server itself, so its scope automatically covers all of the above paths without needing to know where the resource came from.

Explanation

Kyverno runs on a Kubernetes Admission Controller (KAC, a component of the Kubernetes API Server), intercepting incoming requests to the Kubernetes API before they are forwarded and stored in etcd, and performing mutations and validations on them. In addition, Kyverno also functions as a controller, using a watch-and-reconcile mechanism to generate new rules or modify existing ones in response to activities or events that occur.

The following is a flowchart showing how Kyverno reviews and patches incoming requests from clients.

The following is Kyverno’s flow as a controller that performs watch-and-reconcile events or activities.

Use Case

Kubernetes has a native, built-in admission controller commonly referred to as podSecurity or PSA (Pod Security Admission). PSA has only three profiles: privileged, baseline, and restricted. Once you apply a profile, all the controls within it take effect simultaneously; you cannot selectively enable or exclude specific controls, for example, on a per-image or per-container basis.
For example, suppose you want to use the “restricted” profile for all namespaces starting with “prod-*,” but there’s a Cadvisor container that needs access to the host’s /proc directory. This causes that container to fail the Seccomp check. PSA also only has the capability to block at the pod level, not at the controller level. As a result, a Deployment or StatefulSet can remain deployed even if its pods are not, which will create “ghost” events or resources due to control desynchronization.

Use cases that can only be fulfilled using Kyverno (not possible with standard native Kubernetes):

• Auto-restart a Deployment when the Secret it uses changes (mutate-existing).
• Automatically generate a default-deny NetworkPolicy and ResourceQuota when a new namespace is created (generate).
• Verify image signatures (Sigstore/cosign/Notary) before a pod is allowed to run.
• Automatically mutate image tags to digests to make the image immutable.
• Granular exceptions per image/container against a single security profile (e.g., exclude a single container from a restricted profile without compromising the entire namespace) —> this is not possible with native PSA.
• Validate cross-resource dependencies (e.g., check that labels are unique across the cluster, or that a field in one resource matches a field in another resource).
• Synchronize content between resources (e.g., copy data from one ConfigMap to another ConfigMap in a different namespace).
• Native compliance reporting within the cluster (Policy Reports) without relying on external audit logs.
• Combining validate + mutate + generate within a single policy definition for an end-to-end scenario (e.g., generate a new resource, then mutate that resource once it’s successfully created).
• Testing policies in CI before they reach the cluster (Kyverno CLI), including manifest checks against the Restricted Pod Security Standard without requiring a running cluster.

Why do we need it?

Kubernetes doesn’t have a single place to manage “policies” comprehensively.

• RBAC handles who can access what
• ResourceQuota and LimitRange handle resource quotas
• NetworkPolicy handles network traffic
• PSA handles pod security. These four components operate independently, have different configuration methods, and none of them can be used to create policies specific to our own business needs—such as “images must come from the internal registry” or “all resources must have a ‘team’ label.” Kyverno unifies all of these into a single policy model written in YAML.

Another issue is that all of those built-in mechanisms are purely for validation, and even then, their scope is limited. None of them can automatically “correct” or create new resources on their own if something is missing. Kyverno has the capability to do that—it can mutate existing resources and even automatically generate new ones—a capability that no native mechanism possesses.

As for PSA, even though it’s a built-in Kubernetes feature, it actually has quite a few limitations. It applies only to Pods, operates on an all-or-nothing basis per profile, cannot be customized per image or per container, has very rigid exceptions, and we cannot get violation reports directly within the cluster—we have to go through audit logs located outside the cluster.

And most importantly, the ecosystem has been around for a long time and is well-established. There are hundreds of ready-to-use policies available in the official library; it supports image signature verification (Sigstore/Notary); there are Policy Reports to monitor compliance; and a CLI for testing policies directly in CI. So we don’t need to build separate tools to get all of this.

Kyverno vs. Similar Tools: Benchmarks & Trade-offs

An objective comparison of Kyverno against OPA/Gatekeeper, Kubewarden, and native Kubernetes features (ValidatingAdmissionPolicy/MutatingAdmissionPolicy), based on Kyverno 1.13 vs. Gatekeeper 3.18 (early 2026 release) and the official documentation for each project.

Conclusion

If the primary parameter is purely “speed per request,” Gatekeeper or native VAP/MAP might have a slight edge in some scenarios. However, when operational costs (cold-start, memory), feature completeness (validate + mutate + generate + image verification in a single package), and ecosystem maturity are factored in, Kyverno excels in the combination of all these factors—though this doesn’t mean it wins outright on every individual metric.