Cloud Edition
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.
Running Kyverno well isn't a one-time install. It's a lifecycle.
Most Kyverno incidents start with a default nobody revisited, not a novel exploit.
failurePolicy: Fail and run at least three replicas of each controller, so an outage doesn't admit everything.verifyImages rules enforcing, not stuck in audit mode.Policies are code. Give them the same lifecycle.
kyverno test against known-good and known-bad fixtures in CI, and gate the pull request on the result.validationFailureAction: Audit first, then switch to Enforce.ClusterPolicy, Policy, CleanupPolicy and legacy PolicyException. Put the CEL migration through the same pipeline.Four critical-to-high Kyverno CVEs landed in six months of 2026, and each fix shipped in a different minor release.
Upgrading Kyverno isn't always a drop-in patch. 1.10, 1.13 and 1.20 all carry breaking changes or major deprecations.
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}'
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.
Five questions, one point each. Answer honestly.
nctl is free and runs offline, with no policy engine in the cluster. Get nctl →
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.