Kyverno is a CNCF Incubating Kubernetes policy engine that uses standard YAML and Common Expression Language (CEL) instead of proprietary policy languages. Originally contributed by Nirmata, it has 7.4k GitHub stars, 466 contributors, and is used by over 1,000 organizations in production — including Adidas, Bloomberg, LinkedIn, Spotify, Vodafone, and the US Department of Defense.
The latest release is v1.17.0 (February 2026). Kyverno validates, mutates, generates, and cleans up Kubernetes resources, Terraform plans, Dockerfiles, and HTTP requests.
It also verifies container image signatures using Sigstore Cosign and Notary.
What is Kyverno?
Kyverno runs as a Kubernetes admission controller that intercepts API requests before resources are persisted to etcd. It checks resources against loaded policies and takes action based on the policy type — blocking non-compliant resources, modifying them to meet standards, or allowing them through.
Policies are managed using the same tools and workflows as other Kubernetes resources: kubectl, kustomize, and Git. This design eliminates the need for teams to learn a separate policy language.
Version 1.15+ introduced five new policy types, including ValidatingPolicy and MutatingPolicy that extend Kubernetes’ native ValidatingAdmissionPolicy and MutatingAdmissionPolicy. Kyverno now supports any payload type beyond just Kubernetes resources, including Terraform plans and Dockerfiles.
Key Features
| Feature | Details |
|---|---|
| Policy language | Kubernetes YAML and Common Expression Language (CEL) |
| Policy actions | Validate, mutate, generate, clean up |
| Payload types | Kubernetes resources, Terraform plans, Dockerfiles, HTTP requests, Envoy requests |
| Image verification | Sigstore Cosign, Notary |
| Scanning modes | Admission control (enforce/audit) and background scanning |
| CLI tooling | Policy testing, validation, and offline evaluation |
| CNCF status | Incubating |
| Adoption | 1,000+ organizations in production |
Policy Types
Kyverno supports validation (enforce or audit mode), mutation (modify resources before admission), generation (create related resources), and cleanup (remove resources based on conditions). This covers use cases from security enforcement to operational automation.
Background Scanning: Beyond admission control, Kyverno continuously scans existing cluster resources to detect policy violations. This capability identifies drift when resources are modified outside normal workflows or when policies are updated after resources already exist.
Image Verification: Built-in support for verifying container image signatures and attestations strengthens supply chain security. Policies can require images to be signed by specific keys or come from trusted registries before allowing deployment.
Policy Reporting: Kyverno generates detailed reports showing which resources violate policies, making compliance auditing straightforward. Reports can be exported for analysis or integrated with monitoring systems.
CLI Tools: The Kyverno CLI allows teams to test policies against resource manifests before applying them to clusters. This offline testing capability helps catch policy errors during development rather than in production.
Policy enforcement workflow
Kyverno installs as a Kubernetes deployment with admission webhook configurations. When enabled, the Kubernetes API server sends admission requests to Kyverno before persisting resources.
Kyverno evaluates the request against all applicable policies in the cluster.
For validation policies, Kyverno checks if the resource matches defined criteria. In enforce mode, non-compliant resources are rejected with an error message explaining the violation.
In audit mode, resources are allowed but violations are recorded in policy reports.
Mutation policies modify resources before admission. For example, a policy might add security contexts to pods missing them, inject sidecar containers, or set resource limits.
These modifications occur transparently and the modified resource is what gets persisted.
Generation policies trigger after a resource is created. If a new namespace is created, Kyverno can automatically generate default NetworkPolicies, LimitRanges, or RBAC roles for that namespace. This automation ensures consistent security posture without manual intervention.
Getting Started
When to Use Kyverno
Strengths:
- No new language to learn—uses familiar Kubernetes YAML and CEL
- Comprehensive policy actions including generation and cleanup
- Active CNCF community with vibrant ecosystem
- Native Kubernetes integration without external dependencies
- Strong image signature verification for supply chain security
- Policy testing and validation through CLI tools
Limitations:
- Limited to Kubernetes environments (not a general-purpose policy engine)
- Complex policies may become verbose in YAML compared to purpose-built DSLs
- Admission webhook latency can impact cluster performance at scale
- Requires careful policy ordering when multiple policies affect the same resources
- Background scanning can be resource-intensive on large clusters
For a broader view of Kubernetes security strategy, see our cloud infrastructure security guide. Kyverno works well alongside other IaC security tools in a defense-in-depth strategy.
Teams often combine Kyverno with runtime security tools like Falco for behavioral monitoring, and container scanners for vulnerability detection. Recent integrations with Istio enable centralized application authorization, extending Kyverno’s reach beyond admission control to runtime request authorization.
