v1.13

Contains release notes of N4K v1.13

The latest version of the 1.13 release of Enterprise Kyverno is v1.13.6-n4k.nirmata.2.

For a complete list of changes, refer to the upstream Changelog.

Report Server Installation Advisory

(Kubernetes Issue #122668) where multiple components serving the same CustomResourceDefinitions (CRDs) via an APIService can lead to OpenAPI handler failures during cluster startup.

Reports Server serves the same report-related CRDs that Kyverno uses. When these CRDs are present both via the APIService (Reports Server) and within Kyverno’s installation, the Kubernetes apiserver may detect duplicate API paths, resulting in temporary failures, including potential crash loops of Kyverno pods until the APIService becomes fully available.

To mitigate this, native reports server installation with n4k:

  • Enterprise Kyverno (N4K) chart can install reports server natively, init containers for N4K controllers will wait till it’s APIService registers the report CRDs.

separate chart:

  • Install Reports Server first, allowing its APIService to register the report CRDs.
  • Once the Reports Server is fully up and its APIService is ready, install Enterprise Kyverno (N4K) separately, so that Kyverno can detect the existing CRDs without attempting to install them again.

This installation sequence avoids CRD conflicts and ensures stable operation.

v1.13.6-n4k.nirmata.10

Targeted Report Reconciliation on Policy Changes (PR #13664)

Previously, the reports controller would reprocess all reports whenever any policy changed, leading to significant performance issues in large clusters.

This update introduces:

  • A cache mapping report UUIDs to the policies that affect them
  • Replacement of enqueueAll() with a targeted enqueueReportsForPolicy() method
  • Reconciliation now only processes reports actually impacted by a given policy change
  • A background cleanup routine to prevent memory leaks in the cache

Impact: This change dramatically reduces CPU usage and reconciliation latency by ensuring that only relevant reports are processed when policies change, rather than all reports in the cluster.

Dynamic Watcher Resource Hash Optimization (PR #13693)

Switched to a lazy loading model for updating dynamic watcher resource hashes, eliminating the need for expensive list calls on every update.

Improvements include:

  • Resource hashes are now updated only when required, rather than proactively on every event
  • Avoids unnecessary list calls, reducing API server load and improving scalability

Security Fixes

v1.13.6-n4k.nirmata.7

Bug Fixes

Controller Report Breaker Enhancement (PR #13641)

Fixed a critical issue where controller initialization would fail completely if ephemeral reports list+watch operations encountered errors. This problem particularly affected clusters that depend on the reports server, where server unavailability could block the admission flow and cause serious cluster failures.

The fix implements:

  • Centralized access to the reports creation entity (reports breaker)
  • Mock entity replacement when initialization fails
  • Background retry mechanism to continuously attempt watch establishment
  • Improved resilience during controller startup

Important Note: This fix addresses initialization-time failures only. Runtime issues are already handled by the existing circuit breaker functionality, which allows the admission workflow to continue normally when reports become unavailable during operation.

JMESPath Expression Safety (PR #13138)

Resolved panic conditions in the getValueAsStringMap function when processing malformed JMESPath expressions. The function would previously crash when encountering nil or non-string values in map structures, particularly when using the {{@}} variable with non-existent functions.

Improvements include:

  • Added proper nil checking before type assertions
  • Implemented safe type switching for non-string values
  • Comprehensive test coverage (increased from 16% to 70%)
  • Enhanced error handling for malformed expressions

Misc

  • Additional security vulnerability patches
  • Fixed FIPS image workflow

v1.13.6-n4k.nirmata.2

Breaking Changes

Default exception settings: the Helm chart values of the prior versions enabled exceptions by default for all namespaces. This creates a potential security issue. See CVE-2024-48921 for more details. This change will impact users who were relying on policy exceptions to be enabled in all namespaces.

If you do not want to use Policy Exceptions, you can continue to use the default installation settings.

If you were not using Policy Exceptions previously and want to use it from 1.13 onwards, it is advised to set features.policyExceptions.enabled to true in the values.yaml file and store exceptions in a dedicated namespace by setting features.policyExceptions.namespace to nirmata-exceptions.

If you were using Policy Exceptions previously, when upgrading to this new version, set features.policyExceptions.enabled to true in the values.yaml file, and set the exception namespace value to the namespace that you used for storing exceptions. For example, if exceptions were stored in the kyverno namespace, then set features.policyExceptions.namespace to kyverno. Since it was possible to create exceptions in any namespace before, in order to maintain backwards compatibility, you can also set features.policyExceptions.namespace to *.

NOTE: Limiting exceptions to a specific namespace is recommended.

disableAutoWebhookGeneration flag: The disableAutoWebhookGeneration flag in Kyverno is a configuration option that allows users to prevent Kyverno from automatically generating webhooks for policies during or after installation. By default, Kyverno manages webhooks to ensure its policies are applied to Kubernetes resources, but in certain cases, users may want to control or manage webhooks manually.

When this flag is set to true, Kyverno will not automatically create or modify the webhooks that connect its policies to the Kubernetes API server. This can be useful in scenarios where:

  • Manual control over webhook management is desired.
  • Custom webhook configurations are needed for specific use cases, such as integrating with third-party systems or configuring webhooks differently.
  • A user wants to avoid webhook generation on clusters where webhooks are already in place or managed separately.

You can enable the disableAutoWebhookGeneration flag by setting the config.disableAutoWebhookGeneration.enable to true and specifying name of the webhooks to disable by adding values to config.disableAutoWebhookGeneration.webhooks in values.yaml file.

Or

You can directly enable the flag and specify the webhook names to disable while installing n4k charts.

Example:

helm install kyverno nirmata/kyverno -n kyverno --create-namespace --set config.disableAutoWebhookGeneration.enable=true --set "config.disableAutoWebhookGeneration.webhooks={
kyverno-policy-validating-webhook-cfg,kyverno-exception-validating-webhook-cfg}"

This setting can be especially helpful when integrating Kyverno in environments where other tools or manual processes already manage webhook configurations, ensuring that Kyverno does not interfere with or overwrite those setups.

Major Changes

  • Reports server is now disabled by default. If you are using N4K, and want to install the reports-server chart, set the following values in the values.yaml file.
helm install kyverno --namespace kyverno --create-namespace nirmata/kyverno --set crds.reportsServer.enabled=true

Starting this release, the default value of crds.reportsServer.enabled has changed from true to false.

Reports Server Updates:

  • Added support for etcd compaction (auto compaction enabled by default). Use the config.etcd.autoCompaction.mode and config.etcd.autoCompaction.retention fields to override the default values.
  • Optionally configure HPA for reports-server. Autoscaling is disabled by default. Use the autoscaling.enabled field to turn it on and also specify the HPA behavior.
  • Added default resource requests and limits for reports-server pod. However, it is recommended to monitor for these values in production and adjust accordingly.

CVE Fixes

  • Fixed High CVEs (2025-22874 , 2025-26569)
  • Fixed Medium CVEs (2025-0913, 2025-4673)