Kyverno is a Kubernetes-native policy engine that lets platform engineering teams define security, compliance, automation, and governance rules as policy-as-code, using the Kubernetes tools they already run rather than a separate policy language.

What it is

Kyverno is an open-source policy engine written in Go and licensed under Apache-2.0, published by the Kyverno project and documented at kyverno.io. It runs inside Kubernetes and treats policy as ordinary Kubernetes configuration, so policies are authored, reviewed, versioned, and shipped through the same workflows as the rest of a cluster's manifests. The project describes itself as "Unified Policy as Code" and positions itself for platform engineering teams that need security, compliance, automation, and governance controls applied consistently across clusters. It carries the topics compliance, governance, kubernetes, policy-as-code, and security.

The concrete problem it solves is enforcement at the point where resources enter and change in a cluster. Instead of relying on documentation, review checklists, or a bespoke policy language that only a few engineers can read, Kyverno validates, mutates, generates, and cleans up resources through Kubernetes admission controls and background scans. It also verifies container image signatures for supply chain security. Policies live in Git and are applied with kubectl and kustomize, which replaces the separate toolchain and unfamiliar DSL that policy engines traditionally required.

Key capabilities

• Validate, mutate, generate, and clean up Kubernetes resources using admission controls and background scans.
• Verify container image signatures as part of supply chain security enforcement.
• Author and deliver policy using kubectl, kustomize, and Git rather than a new policy language.
• Complement Kubernetes' built-in ValidatingAdmissionPolicies and MutatingAdmissionPolicies with comprehensive reporting, exception management, and periodic background scanning.
• Publish and consume packages through Artifact Hub under the kyverno repository.
• Extend beyond the core engine with companion projects: Chainsaw for end-to-end testing, Policy Reporter for policy violation reporting and a UI, and policy evaluation for non-Kubernetes environments.
• Run alongside Kubernetes RBAC rather than replacing it, adding checks that RBAC cannot perform.

Who uses it and how

• Platform engineering teams standardizing security and compliance rules across clusters, with policies stored beside application manifests in Git.
• Security and compliance groups enforcing guardrails during admission, so non-conforming resources are caught before they are created rather than audited afterwards.
• Supply chain teams requiring container image signature verification before workloads are admitted.
• Teams validating policy behaviour in CI with Chainsaw, the companion end-to-end testing tool.
• Operations teams needing visibility into violations through Policy Reporter, which provides reporting and a UI on top of engine output.

Getting started

Installation and deployment instructions live in the project documentation at kyverno.io, and installable packages are published to Artifact Hub under the kyverno repository.

How it compares

Kyverno is not a replacement for Kubernetes RBAC: RBAC controls access while Kyverno enforces policy compliance, and cluster admins are expected to use RBAC for user and service account authorization before layering Kyverno on top. It also complements, rather than substitutes for, the native ValidatingAdmissionPolicies and MutatingAdmissionPolicies controls, adding reporting, exception management, and periodic background scanning that the built-in controls do not provide. Capabilities outside the core engine, such as end-to-end testing and violation reporting, are handled by companion projects in the Kyverno organization.

When to use it — and when not to

Kyverno only enforces the policies a team defines, so it must be actively maintained like any other security product, and it will not cover requirements nobody wrote down. It cannot address security flaws inherent in Kubernetes itself: it does not protect against vulnerabilities in the Kubernetes API server, such as Billion Laughs YAML deserialization or a faulty admission controller, and its enforcement may be bypassed if Kubernetes has a security flaw. Teams expecting it to fix Kubernetes design weaknesses, replace RBAC, or govern non-Kubernetes systems with the core engine should look elsewhere, and the project carries 703 open issues, so operators should track upstream activity before standardizing on it.