Notable fixes

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

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

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

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

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.

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

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.

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

Notable fixes

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

Notable fixes

• Fixed a problem of CFK failing to communicate with the internal Kafka topics when the certificate authority chain had multiple certificates.

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

Notable fixes

• Fixed an issue that caused an authentication failure when scaling down a Kafka cluster, due to an incorrectly constructed REST call to the Self-Balancing Cluster (SBC) feature.

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

Notable fixes

• Internal issues were resolved, including critical security and vulnerability issues.

Notable enhancements and updates

• Kafka broker port changes in RBAC

  In previous releases, CFK set the Kafka broker port to the token listener port in case of RBAC.

  Starting in this release, CFK only changes the ports for the internal listener (port 9071) and replication listener (port 9072). Other listener ports are no longer changed for RBAC and remain the same as you configured. See Networking for the default port numbers.

  To avoid disruption after upgrading an existing RBAC cluster, use the config override feature to change the port to 9073, in case the Kafka dependency is specified with a port other than 9071 and 9072. For example:

  configOverrides:
  server:
    - bootstrap-server=<kafka-hostname>:9073
  

Notable fixes

• Fixed the rollback workflow for KRaft migration jobs.

• Fixed critical internal issues.

Upgrade notes

• Update Confluent Platform CRDs to 2.9.2.

• Update the CFK init-container to 2.9.2.

Notable fixes

• Fixed Connect OAuth properties for RBAC.

• Fixed an upgrade issue when upgrading to CFK 2.9.0 with Control Center (Legacy) single sign-on (SSO) enabled.

• Fixed issues in the CFK API Reference Guide.

New features

OAuth 2.0 support

You can configure and use the OAuth mechanism on Apache Kafka®, KRaft, Schema Registry, Kafka Connect, REST Proxy, and Confluent Control Center (Legacy) for authentication and authorization.

See OAuth for Kafka and OAuth for other components.

You can configure CFK Day 2 application resources to use OAuth to get access to Confluent Platform components.

Multi-region cluster deployment with KRaft

You can configure and deploy KRaft clusters in multiple regions to form a logical cluster of KRaft controllers across Kubernetes region clusters.

See Configure KRaft in a multi-region cluster.

Multi-region cluster deployment with Connect

You can configure and deploy Connect in one Kubernetes region cluster and utilize the stretched Kafka.

See Configure Connect in a multi-region cluster.

Federal Information Processing Standards (FIPS)

• FIPS can be enabled for the Kafka, Connect, ksqlDB, and Schema Registry clusters.

  See Security Compliance in Confluent for Kubernetes.

• CFK now can be set up running in the FIPS mode using the Helm argument –set fipsmode=”true”.

Configurable Pod Disruption Budget

Now you can set or disable the pod disruption budget for all Confluent Platform components, namely, Apache Kafka®, ZooKeeper, KRaft, Connect, ksqlDB, and Schema Registry.

See Advanced Configuration Options in Confluent for Kubernetes.

Notable enhancements and updates

• The location to download the CFK bundle has changed to the following:

  https://packages.confluent.io/bundle/cfk/confluent-for-kubernetes-2.9.8.tar.gz
  

• Confluent-operator now uses UBI-micro base image which leads to reduced size and reduced security vulnerabilities.

• Improved the support bundle diagnostics to now include Pod Disruption Budgets, Persistent Volumes, Persistent Volume Claims, Pod Specs, and kernel parameters.

• CFK support bundle now can capture large logs even when debug/trace logging is enabled. Specify the duration (in seconds) you want to follow the pod logs using the new follow-logs-duration option.

  See Troubleshoot Confluent for Kubernetes.

Notable fixes

• The readiness and liveness port of Kafka has been changed back to 9071.

• Fixed an issue that caused the Schema Registry endpoint to be empty when doing self-discovery with external access enabled.

• To prevent a possible data loss, you cannot change the Kafka cluster used by that Topic Custom Resource (CR) after you create a topic using the Topic CR.

• Removed the one-minute context timeout in the Clusterlink Reconcile loop in the ClusterLink CR. The timeout caused problems when there were many topics.

• Added configuration to increase the number of workers in Day 2 resources.

• Fixed an issue in KRaftMigrationJob rollback to ZooKeeper for mTLS-enabled clusters.

• Fixed a race condition during the support bundle report command.

• CFK allows zip files with query parameters as valid connector plugin URLs.

• Fixed broker ID calculation for the cluster shrink workflow in multi-region clusters (MRC).

• Internal issues were resolved, including critical security and vulnerability issues.

Known issues

• When deploying CFK to Red Hat OpenShift with Red Hat’s Operator Lifecycle Manager (that is, 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.

• 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) 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 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, do not set spec.tls, and do not set spec.authentication in the ClusterLink CR on the destination cluster if the source cluster has mTLS authentication.

  Instead, in the Destination mode ClusterLink CR, under the spec.configs section, set:

  • local.security.protocol: SSL for mTLS.

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

  For details about configuring the destination cluster for source-initiated Cluster Linking, see Configure the source-initiated cluster link on the destination 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.

• You cannot upgrade to CFK 2.9.0 if you have a Confluent Platform deployment that is configured with Control Center (Legacy) single sign-on (SSO).

  The issue is fixed in the CFK 2.9.1 release.

• CFK Blueprints 2.9 installation fails due to a missing GLIBC dependency.

  The issue was fixed in CFK Blueprints 2.11.0 release.

Known gaps from Confluent Platform 7.7

CFK 2.9 does not support the following Confluent Platform 7.7 functionality:

• Kafka authentication mechanisms: Kerberos and SASL/Scram

Known gaps in CFK Blueprints

CFK Blueprints 2.9 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