We’re thrilled to share the launch of Kyverno 1.18 — our first release since achieving graduation status within the Cloud Native Computing Foundation.
This version reinforces Kyverno’s expanding role as a Kubernetes-native policy engine, bringing major upgrades in security, CLI functionality, and policy engine dependability. It also advances our shift toward CEL-based policy types, laying the groundwork for the next generation of policy as code.
TL;DR
Kyverno 1.18 brings:
- Enhanced security protections for HTTP-based policy execution along with multiple CVE fixes
- Major CLI upgrades for testing and applying modern policy types
- Policy engine refinements for better performance, observability, and scalability
- Upgrades to the policies Helm chart for greater customization
This release contains no breaking changes. However, the deprecation of ClusterPolicy is still on schedule, and users are encouraged to start transitioning to the newer policy types.
Security improvements
Security sits at the heart of Kyverno, and 1.18 introduces key safeguards for how policies are executed.
Safer HTTP execution
Kyverno policies can reach out to external services through HTTP CEL libraries. In 1.18, this feature has been substantially hardened:
- Blocklist/allowlist enforcement: By default, unsafe addresses such as loopback and metadata endpoints are blocked. Users can set up both an allowlist and a blocklist for cluster-scoped and namespaced policies. Additionally, HTTP calls from namespaced policies are disabled by default and must be turned on explicitly through configuration flags. These measures help guard against SSRF-style attacks. Refer to CVE-2026-4789 for more information.
- Scoped token authorization: Previously, Kyverno HTTP calls carried a token that could potentially be exploited to impersonate Kyverno controllers. Now, HTTP calls use a distinct scoped token, ensuring that receiving servers cannot abuse it. Refer to CVE-2026-41323 for more information.
These updates lower the risk of unintended external access while preserving the flexibility needed for advanced policy scenarios.
CLI expansion and developer experience
Kyverno’s CLI continues to mature as an essential tool for building and testing policies.
Expanded policy support
The kyverno apply and kyverno test commands now accommodate:
- Cleanup policies
- HTTP and Envoy authorization policies
mutateExistingrules within MutatingPolicy- The
--exceptions-with-policiesflag for streamlined testing workflows
These additions greatly enhance the ability to test modern policy types both locally and within CI pipelines.
Reliability and usability improvements
A wide range of fixes tackle:
- Error handling and reporting
- CRD compatibility without requiring cluster connections
- Stability concerns such as panics and file handle leaks
The outcome is a more consistent and developer-friendly experience when working with policies.
Policy engine improvements
Kyverno 1.18 introduces several enhancements that refine how policies are executed and managed at scale.
Fine-grained success event filtering
A new successEventActions ConfigMap parameter lets users control:
- Which success events get emitted
- How verbose or quiet policy reporting should be
This is particularly useful in large-scale environments where event volume needs careful tuning.
Performance and scalability
Notable improvements include:
- Memory-based HPA autoscaling for the admission controller
- TLS support on the /metrics endpoint
- Better concurrency handling and a reduced risk of race conditions
These changes make Kyverno more robust in high-scale production settings.
CEL and policy execution enhancements
- A gzip CEL library has been added for crafting more advanced expressions
- Improved compilation and evaluation of policy variables and conditions
- Stronger alignment between policy types and their execution engines
Image verification improvements
Several focused improvements have been made to image verification:
- For
ClusterPolicies,imageRegistryCredentials.secretsnow supports a namespace/name format, and pod-levelimagePullSecretsare automatically leveraged as registry credentials — a helpful feature in multi-tenant setups where each namespace manages its own pull secrets. - Reliability fixes for
ImageValidatingPolicy, including improved handling of signed timestamps and TSA certificate chains, Notary resolver corrections, accuratematchImageReferencesfiltering, and better autogen support for namespaced policies.
Policies Helm chart enhancements
The policies Helm chart continues to evolve with improved customization and control.
New capabilities include:
- Support for excludes in
ValidatingPolicies(namespace, subject, resource rules, and match conditions) auditAnnotationconfiguration- Per-policy annotation overrides
These improvements make it simpler to adapt policies to specific organizational and operational requirements.
Updated support policy
As Kyverno continues to grow in adoption, contributions, and overall project scope, we are refining how we handle release support.
Starting with the 1.18 release, Kyverno will adopt a “main + 1” patch support model.
This means:
- The current release (main) and the immediately preceding release will receive patches. Patches are limited to critical and high-severity CVEs, along with other essential fixes. This provides approximately 3 months of community patch support.
- Older versions will no longer receive regular updates or fixes.
Why this change
This adjustment enables the maintainer team to:
- Efficiently handle the AI-driven increase in security issues and pull requests
- Uphold higher standards for security and responsiveness
- Concentrate efforts on current and actively used versions
- Keep the project sustainable and manageable as it scales
What this means for users
We recommend that users:
- Stay current with recent Kyverno releases
- Plan upgrades in alignment with the 3-month support window, or use a commercial
Here’s the paraphrased version:
A distribution that offers better SLAs and long-term support
This update lets us keep delivering a secure, stable, and continuously improving project for all users.
Reminder: ClusterPolicy deprecation
Just a heads-up — ClusterPolicy resources are scheduled for deprecation later this year.
We highly recommend starting your migration to the newer policy types:
- ValidatingPolicy
- MutatingPolicy
- GeneratingPolicy
- ImageValidatingPolicy
- DeletingPolicy
Steps to take
- Begin migrating your existing policies
- Run thorough tests using the CLI
- Flag any gaps or problems you encounter
Your feedback is critical for a smooth transition and achieving full feature parity. Please report any issues and help us reach complete parity over the coming months.
Community updates
Kyverno’s graduation within the CNCF is a significant milestone for both the project and its community.
Get involved
Kyverno community meetings are now held at multiple times to accommodate participants worldwide:
- APAC / EU: Every other Wednesday at 9:00 CET / India 13:30h / EU: 09:00h / Singapore: 16:00h / Australia: 18:00h
- USA/LATAM: Every other Wednesday at 16:00 CET / India 20:30h / EU: 16:00h / NYC: 10:00h / SF: 7:00h
All meetings are listed on the CNCF Calendar — just filter by Kyverno.
We’re also building a dedicated space where community members can share case studies and real-use scenarios on our community blog. The goal is to create a place where everyone can learn from each other’s experiences. Stay tuned for announcements about when this blog section goes live. If you’d like to contribute a use case or case study, please reach out directly to cortney.nickerson@nirmata.com.
Getting started and upgrading
Kyverno 1.18 introduces no breaking changes, so upgrading should be safe and straightforward for most users.
Upgrade
- Read through the release notes
- Test in a staging environment first
- Follow the upgrade steps in the documentation
Install
Install directly from the Kyverno website
Release Notes
Find the full release notes on GitHub
What’s next
Going forward, the Kyverno roadmap is focused on:
- Ongoing development of CEL-based policy types
- A better policy authoring experience
- Scaling policies across multi-cluster setups
- Branching into AI governance and policy-driven automation
Conclusion
Kyverno 1.18 represents a meaningful step forward after our CNCF graduation.
With stronger security, expanded CLI features, and continued investment in a reliable policy engine and Kubernetes-native policies, Kyverno is helping teams shift from basic policy enforcement to policy-driven operations at scale.
As the project grows, we’re also evolving how we operate to ensure long-term sustainability. Our shift to an N-1 support model reflects our commitment to maintaining high-quality releases while keeping up with the needs of a rapidly growing community and ecosystem.
Upgrade to Kyverno 1.18, stay on supported releases, start migrating to the new policy types, and help us shape the future of policy as code.



