v1.14

Contains release notes of N4K v1.14

The latest version of the 1.14 release of Enterprise Kyverno is v1.14.4-n4k.nirmata.1.

The latest container images can be inferred from the appVersion of the Helm chart (https://github.com/nirmata/kyverno-charts/blob/release-1.14-n4k/charts/nirmata/Chart.yaml)

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

Reports Server Updates:

(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(Recommended):

  • 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.14.4-n4k-nirmata.1

  • Contains the backport fix for lastRefreshInterval of GlobalContextEntry (PR #13700).

v1.14.3-n4k.nirmata.4

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.

Misc

  • Additional security vulnerability patches
  • Fixed FIPS image workflow

v1.14.3-n4k.nirmata.2

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.

v1.14.3-n4k.nirmata.1

Known Issues

Report Server Installation Advisory

In N4K versions 1.13.6 and 1.14, we have removed the built-in Reports Server dependency from the N4K Helm chart to avoid installation conflicts. This change was driven by an upstream Kubernetes issue where multiple components serving the same CustomResourceDefinitions (CRDs) via an APIService can lead to OpenAPI handler failures during cluster startup.

In our case, the 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:

  • 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.

We strongly recommend keeping Reports Server and Enterprise Kyverno as separate Helm deployments until we deliver a patch that supports a consolidated Helm chart.

Refer to the following guides for separate deployments: