Kyverno v1.18.0 just dropped, and if you thought this was another one of those releases where the changelog is longer than the actual new features, you would be absolutely right. But here is the thing: buried under all those incremental improvements is a release that quietly makes Kyverno a lot more serious about security, a lot more friendly to multi-tenant environments, and a lot more usable for day-to-day operations. That is not nothing.
If you have never heard of Kyverno: it is a CNCF graduated project that lets you manage Kubernetes clusters using policy-as-code. Think of it like a bouncer for your cluster — it checks every request against your rules and decides whether to let it through, block it, or mutate it on the fly. Instead of writing Go plugins or maintaining a custom webhook, you write YAML policies and let Kyverno handle the enforcement.
So what is new in v1.18.0, and should you care? Let us walk through it.
Secure HTTP Calls: The Blocklist That Actually Blocks
Kyverno policies can make external HTTP calls to pull in data — think fetching a certificate from a CA, checking a deny-list against an external service, or validating against a remote policy. This is powerful, but it is also a supply-chain attack vector if you do not want someone injecting malicious data into your policy evaluation.
v1.18.0 introduces a configurable blocklist for HTTP context loading, along with scoped token authorization. The idea is simple: your policies can talk to the outside world, but only to the hosts you explicitly allow. Everything else gets blocked.
Because in cybersecurity, the best defense is still “I told you not to call that host.”
The blocklist is controlled via the FLAG_HTTP_BLOCKLIST environment variable, giving you a straightforward way to whitelist trusted endpoints. If your policies need to reach out, you know exactly where. If they try to reach somewhere unexpected, you get a block — and a chance to investigate.
Namespaced Image Registry Credentials
Here is a feature that multi-tenant Kubernetes operators have been begging for. Previously, if you wanted Kyverno to verify container images in your cluster, the image registry credentials had to live at the cluster level. That meant every namespace shared the same credentials, which is fine if you trust everyone in every namespace. It is not fine if you are running a managed Kubernetes platform where each tenant needs their own registry access.
v1.18.0 lets imageRegistryCredentials reference namespaced secrets and pod-level imagePullSecrets. This means you can now configure image verification on a per-namespace or even per-pod basis. Multi-tenant clusters just got a lot more practical.
Finally, Kyverno can play nice in shared environments without turning every namespace into a trust-all zone.
Details: #15112
CLI Gets a Major Policy Expansion
The kyverno apply and kyverno test commands just got a serious upgrade. They now support cleanup policies, HTTP/Envoy authorization policies, and mutateExisting MutatingPolicies. This means you can test the full surface of Kyverno policies locally without needing a live cluster.
For policy authors, this is a massive DX win. No more spinning up a test cluster just to verify that your cleanup policy actually cleans up. No more guessing whether your HTTP authz policy works with the right headers. You write the policy, you run kyverno apply, you get the result. The feedback loop shrinks from hours to seconds.
If you have ever written a Kyverno policy and then spent 20 minutes debugging why it was not matching on a live cluster — this is the feature you should be excited about.
Details: #15732, #15645, #15691, #15253
Success Event Filtering
If you run Kyverno in a large cluster, you know the drill: success events pile up fast. Every policy that passes on every resource generates an event, and in a busy cluster, that means thousands of events per minute. Most of them are noise.
v1.18.0 adds a new successEventActions ConfigMap parameter that lets you control which success events are emitted. You can filter by policy, by namespace, or by resource type. This is not a feature that will make your newsfeed, but it is the kind of operational tuning that makes your logs actually readable when you need to debug something.
Because sometimes the most valuable feature is the one that stops your monitoring pipeline from crying.
Details: #15466
Other Notable Improvements
Beyond the highlights, there are several other improvements worth mentioning:
- Admission-controller autoscaling based on memory utilization — At scale, the Kyverno admission controller can hit memory pressure. v1.18.0 adds memory-based autoscaling, which means the controller can now scale up when it needs to. This is a production-scale reliability feature that enterprise buyers have been asking for.
- TLS encryption on the /metrics endpoint — If you are scraping Kyverno metrics in a multi-tenant environment, this is a no-brainer. Your metrics are now encrypted in transit.
- gzip library support for confidential containers — If you are working with confidential computing workloads, Kyverno can now handle gzip-compressed container images.
- Projected service account token support in Helm chart — The Helm chart now supports projected service account tokens, which is the recommended way to handle authentication in modern Kubernetes.
- –exemplarFilter flag for Prometheus metrics — Fine-grained control over exemplar collection in metrics output, useful for teams running Prometheus at scale.
Bug Fixes: The Image Verification Deep Dive
Here is where things get interesting. Kyverno v1.18.0 includes 16 image verification bug fixes. That is not a typo — sixteen. The image verification subsystem is clearly a priority area for the Kyverno team, and this release shows it.
The fixes cover a wide range of issues:
- matchImageReferences not filtering images properly (#15834) — A policy that was supposed to match specific images was missing some. Fixed.
- CEL evaluation being skipped due to early return (#15882) — A critical bug where the image verification policy evaluation was short-circuited, meaning some images could slip past verification entirely.
- Silently bypassing image verification on patch failure (#15705) — If a patch failed, the verification was silently skipped. Not anymore.
- Multi-signature annotation validation bug (#14500) — Images with multiple signatures were not all being validated.
- Signed timestamp verification for TSA cert chains (#15305, #15192) — Proper verification of signed timestamps when using a Timestamp Authority.
- Relaxed EKU validation for DigiCert TSA (#15093, #15148) — Compatibility fix for DigiCert’s TSA certificates.
- TUF client synchronization (#14829) — Fixed a data race in the TUF (The Update Framework) client initialization.
For teams that rely on Kyverno for supply-chain security, these fixes are not optional. They are mandatory.
Security Fixes
Three CVEs were addressed in this release:
- CVE-2026-32280 — Intermediate certificate validation issue in image verification. If you use Kyverno to verify container images against certificate chains, this affects you.
- CVE-2026-32283 — Go toolchain vulnerability. Standard dependency update.
- CVE-2026-24686 — go-tuf library vulnerability. Affects the TUF client used for image verification.
For teams using image verification with certificate chains, CVE-2026-32280 is the one to prioritize. The fix ensures intermediate certificates are properly validated during the image verification process.
Breaking Changes
None identified in this release cycle. The removal of kubectl from the webhook cleanup binary reduces the image footprint, but it is transparent at the API level. You can upgrade without worrying about breaking changes.
What This Means for You
Kyverno v1.18.0 is not a “look at all the new things” release. It is a “Kyverno is growing up” release. The focus on image verification hardening, multi-tenant credential handling, and operational tooling tells a clear story: Kyverno is moving from a policy engine that works well in single-tenant clusters to a production-grade security platform that can handle the complexity of real-world environments.
If you run Kyverno in a multi-tenant cluster, the namespaced image registry credentials alone make this upgrade worth doing. If you run it at scale, the memory-based autoscaling and success event filtering will make your life easier. And if you are just getting started with Kyverno, the CLI improvements mean you can develop and test policies locally without spinning up a cluster.
No breaking changes, no migration headaches, just a bunch of improvements that make Kyverno more secure, more usable, and more production-ready. That is how you do a release.
