News from Nirmata, October 2026
Kyverno sits in front of the Kubernetes API server. Every create, update and delete passes through it before the cluster accepts anything. That position is what makes policy-as-code work: a rule written once applies to every workload, with nothing to install in the application and no sidecar to maintain.
September was a reminder that the position cuts both ways. A joint threat model turned Kyverno hardening into a checklist of its own. A new workflow moved policy checks ahead of the Terraform apply. The CEL migration reached its last release before ClusterPolicy is removed. And the same governance questions started arriving for AI agents, which never touch an admission webhook at all.
Here is what changed, and what it means for the way you run policy.
Kyverno Hardening Is Now Part of the Job
Three critical vulnerabilities were disclosed in Kyverno inside six months: CVE-2026-22039 (CVSS 10.0), an authorization bypass that broke namespace isolation; CVE-2026-4789 (CVSS 9.8), an SSRF through the CEL http library; and CVE-2026-54523 (CVSS 9.6), which let a NamespacedGeneratingPolicy create RoleBindings in any namespace, including kube-system.
In his September 19 post, Ritesh Patel ties that pace to AI-assisted vulnerability research, which has changed how quickly flaws surface in widely deployed open source. Average patch cycles, meanwhile, still run around 55 days.
The response is the Kyverno End User Threat Model and Hardening Guide, a joint effort by the CNCF, security consultancy ControlPlane and the Kyverno maintainer community, including Nirmata’s Jim Bugwadia and Shuting Zhao. It documents 13 threats, maps attacker techniques to MITRE ATT&CK, and aligns its remediation guidance with NIST SP 800-53. The finding worth sitting with is that most of the risk in production comes from how Kyverno is configured, not from flaws in the software.
Four Kyverno hardening checks to run this week:
- Check your failurePolicy. Set to Ignore, the webhook fails open: whenever Kyverno is unavailable, workloads are admitted unchecked.
- Check the mode on image verification. A policy running in Audit reports unsigned images and admits them anyway.
- Sign your policy bundles. Signing with cosign before distribution lets a cluster detect a tampered policy before it is applied.
- Check who can write policies and exceptions. Anyone able to create a PolicyException can exempt a workload from enforcement, so RBAC on ClusterPolicy and PolicyException resources is part of the control.
ControlPlane published its own account of the assessment on September 9, covering both Kyverno and cert-manager from the auditor’s side.
Policy Moves Ahead of the Terraform Apply
A Terraform change can clear code review and still open a security group to 0.0.0.0/0 once it is applied. The plan is where the real change is described, and until recently that is not where policy ran.
In Beyond the Merge, Sachin Agarwal walks through checking the plan itself. Export it as JSON, run nctl scan terraform against your policy sets in CI, and violations come back as pull-request comments within minutes: security groups open to the world, missing S3 block-public-access settings, wildcard IAM permissions.
The part worth copying is how exceptions are handled. Instead of switching a rule off for everyone, a PolicyException YAML file lives in the repository and names the exact resource addresses it covers. Each exception is reviewable in a pull request, discoverable months later, and revocable by deleting a file.
ClusterPolicy Is Deprecated. Plan the Migration Now.
Kyverno 1.19, released August 20, brought the CEL-based policy types to full feature parity with the legacy ones. In the same release, ClusterPolicy and Policy were deprecated, along with CleanupPolicy and ClusterCleanupPolicy. Removal is planned for 1.20, estimated for November 2026, which makes 1.19 the last release with full support for the legacy types.
Every legacy rule type now has a CEL replacement: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy and DeletingPolicy, each with a namespaced variant. The 1.19 announcement links to a migration guide with field-by-field mappings from ClusterPolicy rules, and the Kyverno Playground supports all of the new types.
Kyverno 1.19.1 followed on September 10 with security fixes of its own: a PolicyException scope bypass in ImageValidatingPolicy (GHSA-5cjf-wwfg-pj4c), an IPv6-embedded-IPv4 blocklist bypass in apiCall.service egress, and Go updates for CVE-2026-39821 and CVE-2026-56853.
If a November removal is faster than your fleet can move, that gap is what Nirmata Enterprise for Kyverno is built for: CVE fixes backported to every supported release, 18 months of patch support per release, and 24/7 support with SLAs on critical fixes. N4K is OSS-compatible rather than a fork, so policies and tooling carry over unchanged.
Guardrails, Not Gates
Writing for the CNCF on October 1, Ambassador Koray Oksay points out that most platform teams use Kyverno for one of its four functions: validation. Mutation and generation let the platform apply the safe default automatically instead of rejecting the deployment and handing the problem back to the developer.
That distinction matters more for adoption than for security. A rule that blocks teaches teams to route around the platform. A rule that fixes the manifest and lets the deploy through does not. The full post is worth reading alongside August’s Kyverno Is a Platform Primitive.
The Same Questions Are Arriving for AI Agents
AI agents never reach an admission webhook. They call tools and models over HTTP, often with a static API key and an over-privileged role, and nothing in the Kubernetes control plane sees any of it.
On September 28, Craig McLuckie of Stacklok argued on the CNCF blog that coding agents need a distributed harness: one that separates the agent loop from execution environments, tool catalogs and session storage, with explicit permission boundaries on tool use. Among the unsolved design problems he lists are identity delegation chains, carried through SPIFFE.
Those are the questions Nirmata AIControls answers using the model Kyverno already established. Identity at the boundary, policy evaluated before the call is made, and an audit trail after it.
The surface keeps widening, too. The CNCF announced Karmada’s graduation in September, with 1,214+ contributors across 292 organizations and multi-component scheduling for distributed AI training jobs in v1.19. As fleets spread across clusters, clouds and regions, policy has to be enforced the same way in all of them rather than configured cluster by cluster.
What to Do Before KubeCon
Four things worth finishing before Salt Lake City:
- Run the four Kyverno hardening checks above against your production clusters and write down the gaps.
- Read the threat model and map its 13 threats onto your own deployment, whether that is a single cluster or hub-and-spoke across a fleet.
- Inventory your ClusterPolicy and Policy resources and decide the migration order.
- Decide what covers you if 1.20 lands before the whole fleet has moved.
KubeCon + CloudNativeCon North America runs November 9 to 12 in Salt Lake City, with 9,000+ attendees and 400+ sessions. Co-located events fill Monday, November 9, including Agentics Day: MCP + Agents, Open Source SecurityCon and Platform Engineering Day. The main conference runs Tuesday to Thursday with the new AI Inference + Agentic track and Maintainer Track sessions for projects including Kyverno.
We’ll be at KyvernoCon on Tuesday, November 10. Meet the Nirmata team in Hall 4, Booth 278 to talk through Kyverno hardening, N4K, or AI governance.
Bring a question. Let’s work through it together.
