Confluent Developer Marketplace Get started
  1. Home
  2. Platform
  3. CFK

Confluent for Kubernetes Release Notes

Confluent for Kubernetes (CFK) is continuously updated with new features and enhancements. This topic highlights significant new and updated features, bug fixes, and known limitations in each release.

Note

For the list of security and vulnerability issues fixed in any release, see Security Advisories and Security Release Notes.

[September 25, 2026] Confluent for Kubernetes 3.0.6 Release Notes

Compatibility and container images

CFK 3.0.x lets you deploy and manage Confluent Platform versions 7.2.x to 8.0.x on Kubernetes versions 1.25 to 1.33 (OpenShift 4.12 to 4.20).

The images released in CFK 3.0.6 are:

  • confluentinc/confluent-operator:0.1263.243

  • confluentinc/confluent-init-container:3.0.6

Breaking changes

There are no breaking changes in this release.

New features

Enhancements

  • Removes hard-coded ParallelGCThreads=1 or ConcGCThreads=1 JVM defaults. See Default JVM settings.

  • Enables FIPS on the Kafka broker and applies FIPS JVM settings through jvm.config.

  • Adds InternalClientConfig override support for the operator’s internal Kafka client. See Disable TLS hostname verification for the Kafka internal client.

  • Checks Schema Registry status directly instead of trusting a cached configuration hash.

  • Makes the Kafka-to-LDAP TLS client FIPS-aware using a Bouncy Castle FIPS Keystore (BCFKS).

  • Removes stale multi-region cluster (MRC) bypass-prechecks guidance, a follow-up to the ZooKeeper chroot fix below.

Bug fixes

  • Fixed Jolokia configuration options not rendering as a single comma-separated line.

  • Fixed the default ZooKeeper chroot to root during KRaft migration for MRC endpoints.

  • Fixed the KafkaTopic controller so it keeps retrying replication factor (RF) fetches after a transient failure, instead of giving up permanently. The bug left status.replicas empty for topics created with spec.replicas unset, and was most noticeable when creating many topics at once through Helm. Broker-side RF was always correct. Only the KafkaTopic status was affected.

  • Fixed the Metadata Service (MDS) client keystore rendering for the mtls type without sslClientAuthentication.

  • Fixed the Schema Registry restConfig bootstrap URL.

  • Fixed spec.tls.fips.enabled: true not being applied to the embedded Kafka REST proxy’s Metadata Service (MDS) client TLS configuration, which was always generated as JKS instead of BCFKS. Manual kafka.rest.client.ssl.* configuration overrides are no longer needed to run FIPS and RBAC deployments together.

  • Fixed Kafka-to-ZooKeeper TLS connections crash-looping under FIPS mode due to a missing BCFKS keystore or truststore configuration.

  • Fixed a java.security.properties path typo that silently prevented FIPS enforcement from taking effect.

  • Fixed reconcile errors and a stale cluster phase being hidden in Kafka status. Status, Kubernetes events, and broker logs now surface the actual failure reason and cluster phase instead of generic or missing messages. This helps diagnose and recover from issues faster.

  • Fixed an unnecessary full cluster roll caused by a stale cached read of tracked secret versions.

  • Fixed a per-role Kafka discovery override issue in Connect, ksqlDB, and KafkaRestProxy.

  • Fixed the Replicator mTLS connector plugin version.

  • Fixed an RBAC name collision between External-DNS and Ingress-Nginx.

  • Fixed FIPS-prefixed Kafka clients missing security.providers.

  • Fixed excessive LDAP load caused by each mirror topic independently triggering an OAuth token request. Tokens are now batched and cached, preventing LDAP overload at scale.

  • Fixed Cluster Linking remote-auth secrets not mounting on Kafka brokers.

  • Fixed a Schema resource that could report status.appState: Created without the schema actually being registered in Schema Registry, following a reconcile interrupted at a specific point. Affected resources now self-heal on the next reconcile.

  • Fixed Kafka custom resource (CR) reconciliation failures caused by TLS secrets (for example, services.kafkaRest mTLS) that contained only JKS or PKCS12 material. Only PEM-style secrets were supported.

  • Fixed an operator memory leak caused by idle outbound HTTP connections that were never closed, which could cause gradual memory growth and potential OOMKilled restarts. Idle connections now close after a configurable timeout set by CONFLUENT_OPERATOR_HTTP_IDLE_CONN_TIMEOUT, which defaults to 90 seconds. See Deploy CFK with custom environment variables.

  • Fixed the default OpenID Connect (OIDC) session token expiry, increasing it from 90 seconds to 15 minutes.

  • Fixed TLS handshake errors flooding Control Center Prometheus and Alertmanager logs, caused by Kubernetes health checks against TLS-enabled endpoints. Set useProcNetPortCheck: true under spec.podTemplate.probe.readiness or spec.podTemplate.probe.liveness on the ControlCenter CR to switch these health checks to a TLS-free method.

  • Fixed an issue that prevented installing or pinning to a specific, non-latest, CFK version through the OpenShift OperatorHub. Each release now retains a direct upgrade link to its predecessor in the Red Hat operator catalog.

Known limitations

There are no new known limitations in this release.

Deprecations

There are no new deprecations in this release.

[June 23, 2026] Confluent for Kubernetes 3.0.5 Release Notes

Compatibility and container images

CFK 3.0.x lets you deploy and manage Confluent Platform versions 7.2.x to 8.0.x on Kubernetes versions 1.25 to 1.33 (OpenShift 4.12 to 4.20).

The images released in CFK 3.0.5 are:

  • confluentinc/confluent-operator:0.1263.163

  • confluentinc/confluent-init-container:3.0.5

New features

Enhancements

  • Validates configOverrides.server for blocklisted keys (for example, zookeeper.connect) before starting KRaft migration, and blocks migration with an actionable error on conflicts.

  • Improves Kafka and KRaft readiness probing to avoid probe-generated connection churn and false mTLS authentication failures from polluting operational metrics.

  • Masks sensitive credentials in CFK log output through a centralized redaction wrapper, so plain-text credentials are sanitized before reaching any log sink.

Bug fixes

  • Fixed a multi-region KRaft migration issue where the KRaft controller required a manual override for the zookeeper.connect configuration.

  • Fixed Schema Registry cluster discovery for external-access and multi-region deployments by handling multi-URL endpoints correctly when schemaRegistryClusterRef is used.

  • Fixed a connector cleanup issue to ensure that CFK deletes connectors even if their creation returned an HTTP 500 error, preventing orphaned connectors from accumulating on the Connect cluster.

  • Fixed incorrect advertised.listeners ports when multiple user-defined listeners share the same static or nodePort offset.

Known limitations

  • The operator can leak memory and goroutines over time from idle outbound HTTP connections (to Kafka REST, Metadata Service (MDS), Schema Registry, or an OAuth identity provider) that are never closed. This can affect any deployment. Upgrade to CFK 3.0.6 or later, which adds a configurable idle-connection timeout to fix this. See [September 25, 2026] Confluent for Kubernetes 3.0.6 Release Notes.

Deprecations

There are no new deprecations in this release.

[25 March, 2026] Confluent for Kubernetes 3.0.4 Release Notes

CFK 3.0.4 allows you to deploy and manage Confluent Platform versions from 7.2.x to 8.0.x on Kubernetes versions 1.25 - 1.33 (OpenShift 4.12 - 4.20).

The images released in CFK 3.0.4 are:

  • confluentinc/confluent-operator:0.1263.124

  • confluentinc/confluent-init-container:3.0.4

For details on installing CFK and Confluent Platform using the above images, see Deploy Confluent for Kubernetes and Deploy Confluent Platform using Confluent for Kubernetes.

Notable fixes

  • Fixed an issue where custom OAuth listeners failed to validate without JAAS configurations.

  • Fixed metrics TLS configuration to correctly resolve keystore passwords from Vault-injected files when using DirectoryPathInContainer.

  • Added support for configuring JMX authentication and access control using CR specifications to secure exposed JMX ports for all Confluent Platform components.

    Important

    This is a breaking change to secure exposed JMX ports. This affects existing deployments that access JMX ports remotely for metrics queries.

    For more information, see JMX Metrics.

  • For the list of security and vulnerability issues fixed in this release, see Security Advisories and Security Release Notes.

[25 February, 2026] Confluent for Kubernetes 3.0.3 Release Notes

CFK 3.0.3 allows you to deploy and manage Confluent Platform versions from 7.2.x to 8.0.x on Kubernetes versions 1.25 - 1.33 (OpenShift 4.12 - 4.20).

The images released in CFK 3.0.3 are:

  • confluentinc/confluent-operator:0.1263.105

  • confluentinc/confluent-init-container:3.0.3

For details on installing CFK and Confluent Platform using the above images, see Deploy Confluent for Kubernetes and Deploy Confluent Platform using Confluent for Kubernetes.

Notable fixes

  • Fixed connector reconciliation for masked sensitive fields in Connect.

    Updated CFK’s connector reconciliation logic to properly handle Connect’s credential masking in the REST API, preventing unnecessary connector updates or restarts when sensitive configuration fields are masked.

  • Fixed file permissions for user-store secret mounts to use 0600 permissions.

  • Fixed an issue where the platform.confluent.io/roll-delay-interval-seconds annotation was ignored when upgrading the operator. This was causing the pods to roll immediately instead of waiting for the configured delay.

  • Added auto reconcile capability for cluster link.

  • Improved validation for inter-broker protocol (IBP) version and added automatic derivation of IBP for standard Confluent Platform images.

  • Added enableExternalInterInstance field to the SchemaRegistry CRD to enable external inter-instance communication as a first-class API, with backward compatibility for existing configOverrides.server configuration.

  • For the list of security and vulnerability issues fixed in this release, see Security Advisories and Security Release Notes.

[8 December, 2025] Confluent for Kubernetes 3.0.2 Release Notes

CFK 3.0.2 allows you to deploy and manage Confluent Platform versions from 7.2.x to 8.0.x on Kubernetes versions 1.25 - 1.33 (OpenShift 4.12 - 4.20).

The images released in CFK 3.0.2 are:

  • confluentinc/confluent-operator:0.1263.79

  • confluentinc/confluent-init-container:3.0.2

For details on installing CFK and Confluent Platform using the above images, see Deploy Confluent for Kubernetes and Deploy Confluent Platform using Confluent for Kubernetes.

Notable fixes

  • Fixed issues with renewing certificate authorities (CAs) for auto-generated certificates.

    See Manage TLS Certificates for Confluent Platform Using Confluent for Kubernetes.

  • Added preventive validation in the CFK webhook for Kafka cluster scale-up and scale-down operations.

  • Removed the inter-broker protocol version in Kafka server properties for KRaft-based clusters.

  • Improved output of the KafkaRestClass custom resource (CR) status through kubectl.

  • Fixed an issue in KRaft migration rollback to ZooKeeper where the required platform.confluent.io/format-cluster-metadata-in-kafka annotation was not being automatically added to the Kafka CR.

  • Fixed node port collision for Kafka Token and TokenSASL listeners when using mTLS and RBAC in a Multi-Region Cluster (MRC) setup.

  • Fixed load balancer port collision for Kafka Token and TokenSASL listeners when using mTLS and RBAC in a Multi-Region Cluster (MRC) setup.

  • Now you can configure container security context for Control Center’s Prometheus and Alertmanager containers.

  • Fixed an issue where only the Control Center Prometheus load balancer service was created when external access was enabled for both Control Center and Prometheus.

  • Fixed GnuTLS security failures by falling back to curl if wget is unable to retrieve Connect plugins.

  • For the list of security and vulnerability issues fixed in this release, see Security Advisories and Security Release Notes.

[29 September, 2025] Confluent for Kubernetes 3.0.1 Release Notes

CFK 3.0.1 allows you to deploy and manage Confluent Platform versions from 7.2.x to 8.0.x on Kubernetes versions 1.25 - 1.33 (OpenShift 4.12 - 4.18).

The images released in CFK 3.0.1 are:

  • confluentinc/confluent-operator:0.1263.34

  • confluentinc/confluent-init-container:3.0.1

For details on installing CFK and Confluent Platform using the above images, see Deploy Confluent for Kubernetes and Deploy Confluent Platform using Confluent for Kubernetes.

Notable update

A new Confluent Enterprise license is available for the customer-managed Confluent Platform for Confluent Cloud subscription. This license allows you to use self-managed Confluent Platform components exclusively with Confluent Cloud services.

If you encounter the following error when provisioning a new license, you should upgrade to a CFK version, 2.9.7, 2.10.3, 2.11.3, 3.0.1, or later.

secretRef confluent-license: missing subject or contains invalid subject

Notable fixes

  • Fixed the empty STATUS in the Schema CRD.

  • Fixed the issue where OAuth configuration in the SchemaExporter CRD was ignored when exporting schemas to Confluent Cloud.

  • IPv6 now correctly works for rack aware Kafka setup.

  • For the list of security and vulnerability issues fixed in this release, see Security Advisories and Security Release Notes.

[13 June, 2025] Confluent for Kubernetes 3.0.0 Release Notes

CFK 3.0.0 allows you to deploy and manage Confluent Platform versions from 7.2.x to 8.0.x on Kubernetes versions 1.25 - 1.33 (OpenShift 4.12 - 4.18).

The images released in CFK 3.0.0 are:

  • confluentinc/confluent-operator:0.1263.8

  • confluentinc/confluent-init-container:3.0.0

For details on installing CFK and Confluent Platform using the above images, see Deploy Confluent for Kubernetes and Deploy Confluent Platform using Confluent for Kubernetes.

New features and enhancements

CFK 3.0.0 is a major release with the following noteworthy new features and updates.

Zookeeper deprecation and removal

Starting with Confluent Platform version 8.0, ZooKeeper has been deprecated and is no longer included in Confluent Platform 8.0 and later.

To use CFK 3.0 to deploy and manage Confluent Platform 8.0, migrate your Confluent Platform 7.x deployment to KRaft, first, and then upgrade Confluent Platform to 8.0.

For details about ZooKeeper to KRaft migration, see Migrate a Single Cluster from ZooKeeper to KRaft.

Confluent Control Center 2.2 support

Confluent Platform 8.0.0 is compatible with Confluent Control Center 2.2.0 and later, which can be deployed on machines on IPv6 network, IPv4 network, or dual-stack with both IPv4 and IPv6.

Confluent Control Center (Legacy) was deprecated and removed from Confluent Platform 8.0.0.

For the notes about upgrading Confluent Control Center (Legacy) to Control Center, see Upgrade Confluent Platform Using Confluent for Kubernetes.

Passwordless OAuth/OIDC authentication

Support for OpenID Connect (OIDC) authentication and Open Authorization (OAuth) 2.0 authorization has been enhanced with client assertion for Kafka, KRaft, MDS, and Schema Registry.

See OAuth/OIDC authentication.

mTLS with RBAC brownfield support

Brownfield deployment for using mTLS identities with RBAC authorization is now generally available. You can use CFK to migrate Confluent Platform to enable RBAC with mTLS.

See Configure RBAC for Confluent Platform Using Confluent for Kubernetes.

Log4j 2 support

CFK 3.0.0 uses Log4j 2 for logging.

With Confluent Platform 8.0, you can only use Log4j 2. For configuring and using Log4j 2, see Configure Log4j 2.

With Confluent Platform 7.x, use the platform.confluent.io/use-log4j1=true annotation to enable Log4j. For more information, see Upgrade CFK.

Log4j 2 is not backward compatible with Log4j.

SNI validation

Due to the Jetty 12 upgrade, SNI validation is enabled by default in Confluent Platform for encryption. For disabling SNI validation, see Disable SNI validation.

Known issues

  • When deploying CFK to Red Hat OpenShift with Red Hat’s Operator Lifecycle Manager using the OperatorHub, you must use OpenShift version 4.9 or higher.

    This OpenShift version restriction does not apply when deploying CFK to Red Hat OpenShift in the standard way without using the Red Hat Operator Lifecycle Manager.

  • When CFK is deployed on an OpenShift cluster with Red Hat’s Operator LIfecycle Manager/OperatorHub, capturing the support bundle for CFK using the command, kubectl confluent support-bundle --namespace <namespace>, can fail with the following error message:

    panic: runtime error: index out of range [0] with length 0

  • If the ksqlDB REST endpoint is using the auto-generated certificates, the ksqlDB deployment that points to Confluent Cloud requires trusting the Let’s Encrypt CA.

    For this to work, you must provide a CA bundle through cacerts.pem that contains both (1) the Confluent Cloud CA and (2) the self-signed CA to the ksqlDB CR.

  • When TLS is enabled, and when Confluent Control Center (Legacy) uses a different TLS certificate to communicate with MDS or Confluent Cloud Schema Registry, Control Center (Legacy) (used with Confluent Platform 7.x) cannot use an auto-generated TLS certificate to connect to MDS or Confluent Cloud Schema Registry. See Troubleshooting Guide for a workaround.

  • When deploying the Schema Registry and Kafka CRs simultaneously, Schema Registry could fail because it cannot create topics with a replication factor of 3. It is because the Kafka brokers have not fully started.

    The workaround is to delete the Schema Registry deployment and re-deploy once Kafka is fully up.

  • When deploying an RBAC-enabled Kafka cluster in centralized mode, where another “secondary” Kafka is being used to store RBAC metadata, an error, “License Topic could not be created”, may return on the secondary Kafka cluster.

  • A periodic Kubernetes TCP probe on ZooKeeper (in Confluent Platform 7.x) causes frequent warning messages “client has closed socket” when warning logs are enabled.

  • REST Proxy configured with monitoring interceptors is missing the callback handler properties when RBAC is enabled. Interceptor would not work, and you would see an error message in the KafkaRestProxy log.

    As a workaround, manually add configuration overrides as shown in the following KafkaRestProxy CR:

    configOverrides:
  server:
    - confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler
    - consumer.confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler
    - producer.confluent.monitoring.interceptor.sasl.login.callback.handler.class=io.confluent.kafka.clients.plugins.auth.token.TokenUserLoginCallbackHandler

  • When configuring source-initiated cluster links with CFK where the source cluster has TLS enabled, set the following in the Source mode ClusterLink CR, under the spec.configs section:

    • local.security.protocol: SSL and local.listener.name: <SSL listener name> for mTLS.

    • local.security.protocol: SASL_SSL for SASL authentication with TLS.

    For details about configuring source-initiated Cluster Linking, see Configure the source-initiated cluster link on the source cluster.

  • The CFK support bundle plugin on Windows systems does not capture all the logs.

    As a workaround, specify the --out-dir flag in the kubectl confluent support-bundle command to provide the output location for the support bundle.

  • When you have external access enabled with load balancer type for both Control Center and Prometheus, only controlcenter-next-gen-prometheus-bootstrap-lb gets created.

    The workaround is to enable Control Center external access first, and then add Prometheus external access. This will show both Control Center and Prometheus external controlcenter-next-gen-bootstrap-lb and controlcenter-next-gen-prometheus-bootstrap-lb get created.

Known gaps from Confluent Platform 8.0

CFK 3.0 does not support the following Confluent Platform 8.0 functionality:

  • Kafka authentication mechanisms: Kerberos and SASL/Scram

Known gaps in CFK Blueprints

Confluent for Kubernetes (CFK) Blueprints is deprecated and will be removed in a future release.

CFK Blueprints 3.0 does not support the following CFK functionality:

  • Internal listener authentication change on the running cluster

  • A central Confluent Platform cluster serving as the RBAC metadata store for multiple Confluent Platform clusters

  • The StaticPortBasedRouting and NodePort external access methods

  • Monitoring multiple Kafka clusters in Confluent Control Center (Legacy)

  • Configuring and managing KRaft-based clusters

  • Using OpenID Connect (OIDC) for authentication