CEL Policies in Kyverno 1.17 Production Ready, Legacy APIs Deprecated

Contents

Kyverno has established itself as a policy-as-code tool for Kubernetes, allowing policies to be defined and enforced directly as Kubernetes resources – from validation and mutation to image verification. The tool thus addresses the growing complexity in operating Kubernetes clusters by mapping security and compliance rules as code. With version 1.17, the CNCF project is now making a strategic cut according to its own announcement: the CEL-first architecture (Common Expression Language) introduced in version 1.16 is leaving beta status and becoming the stable foundation.

CEL Policy Types Reach GA Status

According to the CNCF blog, the central innovation in Kyverno 1.17 is the promotion of all CEL-based policy types to API version v1. This means they are considered stable and production-ready. Specifically, this affects: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy, DeletingPolicy, and PolicyException – each including their namespaced variants (e.g., NamespacedValidatingPolicy).

The Common Expression Language is the same expression language that the Kubernetes API server itself uses for its native ValidatingAdmissionPolicies and MutatingAdmissionPolicies. According to the Kyverno development team, the switch to CEL is intended to noticeably improve evaluation performance and reduce the learning curve for platform teams, as they only have to deal with one language.

In parallel, the project has significantly expanded the available CEL functions. New additions include, among others, hash functions (md5, sha1, sha256), mathematical rounding (math.round(value, precision)), decoding X.509 certificates (x509.decode(pem)), random string generation, JSON and YAML parsing, and time-based functions such as time.now() and time.toCron(timestamp), which are also intended to enable policies for maintenance windows.

CLC 2026: Conference for DevEx and Platform Engineering

The CLC Conference, specializing in Developer Experience (DX) and Platform Engineering, will take place in Mannheim from November 11 to 12, 2026. The organizers have launched the Call for Proposals: proposals for workshops and talks are being sought until April 21 – primarily practical reports on Developer Experience, Platform Engineering, and Agentic AI.

Further information can be found on the CLC website.

Legacy APIs Being Deprecated – Migration Recommended

The GA status of CEL policies comes with a clear message to existing users: According to the announcement, Kyverno 1.17 officially marks the previous types ClusterPolicy and CleanupPolicy as deprecated. While these JMESPath-based APIs remain functional in the current version, they are slated for complete removal in a future version – likely within the current year. The developers strongly recommend writing new policies exclusively with the CEL-based APIs to avoid increasing future migration efforts.

For teams with extensive existing policy inventories, the project provides a migration guide that is intended to offer a field-by-field mapping of legacy configurations to their new equivalents. For example, the previous validate.pattern is mapped to CEL expressions in ValidatingPolicy. Those who previously bundled ClusterPolicy rules for mutation, validation, and generation into a single object will need to split these into the specialized types ValidatingPolicy, MutatingPolicy, and GeneratingPolicy in the future.

Multi-Tenancy: Namespaced Mutation and Generation

Kyverno already introduced namespaced variants for validation, cleanup, and image verification in version 1.16. Version 1.17 closes this gap with NamespacedMutatingPolicy and NamespacedGeneratingPolicy, according to the announcement. This allows namespace owners to define their own mutation and generation rules – for example, to automatically inject sidecar containers or create default ConfigMaps – without needing cluster-wide permissions or affecting other tenants. This is intended to enable true multi-tenancy at the policy level.

Supply Chain Security and Observability

For enhanced supply chain security, Kyverno 1.17 includes support for Cosign v3, according to the announcement, to keep image verification compatible with the evolving Sigstore ecosystem. The new YAML and JSON parsing functions in CEL are also intended to make it easier to check complex metadata and Software Bill of Materials (SBOMs) within attestations.

Regarding observability, the developers have made two adjustments: A new flag --allowedResults allows specific results (e.g., only failed checks) to be selectively saved in reports. This is intended to reduce the load significantly on etcd in large clusters. Furthermore, Kyverno 1.17 provides more detailed latency and execution metrics for CEL policies by default, according to the blog post.

New Website and Decoupled Developer Tools

In addition to the technical innovations, the Kyverno project has redesigned its entire web presence based on the Starlight framework. The revised documentation includes a structure tiered by user experience – from quick start to reference for advanced policy authors. The catalog with over 300 example policies can now be filtered by category and type (CEL vs. JMESPath).

For developers and integrators, the project has decoupled its core components: The CEL-based APIs have been moved to a separate repository (kyverno/api), which is intended to facilitate the import of Kyverno types into custom Go projects. Additionally, a dedicated SDK project (kyverno/sdk) is available for building custom controllers and tools.

Roadmap: Aiming for a Unified Tooling Platform

For future development, the Kyverno maintainers outline several focus areas: the various subprojects – CLI, Policy Reporter, and Kyverno-Authz – are to be merged into a unified platform. Furthermore, the team intends to establish automated performance tests and provide granular throughput and latency data, enabling platform teams to better assess Kyverno's behavior in high-load scenarios. An upgrade from version 1.16 to 1.17 is said to be straightforward, according to the developers; however, they recommend updating manifests to the new API version v1. The previous v1beta1 will continue to be supported for a transitional period.

(map)