Whitepaper

The Kyverno Operator's Playbook

Every request to your cluster passes through Kyverno. In 2026, four critical-to-high CVEs hit settings most teams never revisit. Here's how to harden, test, patch and upgrade it.

Download the PDF Check your version

By the Kyverno maintainers at NirmataFor SecOps and platform teams

Four stages, repeated every release

Running Kyverno well isn't a one-time install. It's a lifecycle.

Every new release or CVE restarts the loop

1 · Harden the baseline

Most Kyverno incidents start with a default nobody revisited, not a novel exploit.

Set failurePolicy: Fail and run at least three replicas of each controller, so an outage doesn't admit everything.
Keep verifyImages rules enforcing, not stuck in audit mode.
Sign policy bundles and verify them on every cluster. Scope RBAC and PolicyException access tightly.

2 · Test and roll out policies

Policies are code. Give them the same lifecycle.

Run kyverno test against known-good and known-bad fixtures in CI, and gate the pull request on the result.
Roll out new rules with validationFailureAction: Audit first, then switch to Enforce.
Kyverno 1.20 removes ClusterPolicy, Policy, CleanupPolicy and legacy PolicyException. Put the CEL migration through the same pipeline.

Version check

Is the Kyverno you run still getting patches?

Upstream Kyverno patches only its latest minor, v1.19, until v1.20 ships (projected Nov 2026). Pick your version:

Not sure? kubectl get deploy -n kyverno -o jsonpath='{..image}'

CVEs fixed in Nirmata Enterprise for Kyverno on the v1.17 branch, per the N4K release notes. Upstream no longer patches this branch.

Upstream community patches: Ended
Nirmata Enterprise for Kyverno: Supported through Aug 2027

Get patched v1.17 See the v1.17 fixes

The backport gap

Can't upgrade every quarter?

Upstream Kyverno patches only its latest release. Nirmata Enterprise for Kyverno backports CVE fixes, including Kyverno engine fixes, to every supported release for 18 months. You upgrade on your own schedule, not upstream's.

See how backports work

Score your deployment

Five questions, one point each. Answer honestly.

Is failurePolicy: Fail set in production, with at least three replicas of each controller?Is image signature verification enforcing, not sitting in audit mode?Are policy bundles signed, and verified on every cluster that uses them?Is every policy change gated on kyverno test in CI and rolled out in Audit before Enforce?Do you know the support end date for the version you run, with the next upgrade already scheduled?

0/5

A single Kyverno outage or one unpatched CVE becomes a fleet-wide bypass. Start with stages 1 and 3.

Check your answers in about a minute

# 1. Any fail-open webhooks?
kubectl get validatingwebhookconfigurations \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.webhooks[*].failurePolicy}{"\n"}{end}'

# 2. Which Kyverno version are you actually running?
kubectl get deploy -n kyverno \
  -o jsonpath='{range .items[*]}{.spec.template.spec.containers[*].image}{"\n"}{end}'

# 3. Everything else: RBAC, network policies, replicas, PDBs, probes, reports offload
nctl kyverno health

nctl is free and runs offline, with no policy engine in the cluster. Get nctl →

Keep going

Blog
Kyverno runs your admission control. Is it actually hardened?
The companion post to this playbook.
Product
Nirmata Enterprise for Kyverno
CVE fixes backported to every supported release, for 18 months.
Guide
Migrating to CEL-based policies
Kyverno 1.20 removes ClusterPolicy and Policy. Plan the migration before it ships.
Docs
N4K release notes and LTS matrix (opens in a new tab)
Backport history and support windows.

Talk to the team that created Kyverno

Planning the 1.20 migration, stuck on an out-of-support version, or scaling Kyverno across a fleet? Talk to the maintainers, or see how Enterprise Kyverno keeps older releases patched.

Talk to a Kyverno maintainer Explore Enterprise Kyverno