AppSecNews
IaC Security Open source Established Verified profile

Kyverno

by The Kyverno Project (CNCF)

A Kubernetes-native policy engine that enforces, mutates and generates resources through admission webhooks, with policies written as YAML.

Visit kyverno.io (leaves AppSecNews, opens in a new tab) Leaves AppSecNews for the vendor's own site.

No endorsements yet

Run Kyverno in production? A named recommendation helps the next team shortlisting it.

Recommend this tool

Endorsers verify their identity through LinkedIn. Titles and companies are self declared, shown as they were when each person signed, and reviewed by an editor before anything is published. Endorsements are never paid for.

What it does

Kyverno runs as an admission controller inside the cluster. The Kubernetes API server calls its webhook on resource creation and update, and Kyverno evaluates matching policies before the object is persisted. Policies are Kubernetes custom resources written in YAML, which is the design decision that defines the tool: you describe the resource pattern you require, and Kyverno compares the incoming object against it, rather than writing a program that inspects the object.

It does three things beyond validation. Mutation rules rewrite incoming resources, adding labels, injecting sidecar configuration or setting security context defaults, so that compliance is achieved rather than merely demanded. Generation rules create companion resources automatically, such as a default network policy or a pull secret whenever a namespace appears. And image verification rules check container image signatures and attestations against Sigstore, gating deployment on supply chain provenance. A CLI runs the same policies against manifests in CI.

Where it fits

Kyverno is a cluster gate, sitting at the API server boundary between deployment tooling and the running workload. Platform engineering owns it. Because it can block object creation, the rollout order matters: policies start in Audit mode, produce PolicyReport resources describing what would have failed, and move to Enforce once the existing estate is clean. Running the same policies in CI is how teams avoid surprising developers at deploy time.

Strengths

  • Policies are YAML that looks like the resources they govern, so a Kubernetes operator can read and write them without learning a separate policy language.
  • Mutation and generation turn policy from a gate into a paved road, fixing resources instead of only rejecting them.
  • Native PolicyReport output gives you a queryable record of violations in the cluster rather than only webhook rejections.
  • Image signature verification brings supply chain enforcement into the same policy layer as configuration.

Limitations

  • It is Kubernetes-only by design. Terraform, cloud accounts and non-Kubernetes workloads are out of scope entirely.
  • An admission webhook is in the critical path of the API server. Misconfigured failure policy, resource starvation or a webhook outage can block deployments cluster-wide, so it needs the availability treatment of any critical component.
  • Complex conditional logic becomes awkward in YAML. Policies that need real computation end up using JMESPath expressions or CEL and read considerably worse than the simple cases.

Who it suits

Right for platform teams that want Kubernetes guardrails maintained by people who work in YAML and manifests daily, especially where auto-remediation through mutation is valuable. Wrong if you need one policy language spanning cloud infrastructure and clusters, or if your team already runs OPA broadly and would rather consolidate on Rego.

Used Kyverno? Recommend it under your own name and title.

Recommend this tool