リリース

Strimzi 1.1.0 is a feature release adding Kafka 4.3.0 and 4.2.1 support while dropping Kafka 4.1.x, along with several capability additions. Operators should act on two breaking changes before upgrading: the entity-operator healthcheck port renames and the TLS truststore format switch in KafkaBridge and KafkaMirrorMaker2.

• breakingEntity-operator healthcheck ports renamed

  The entity-operator healthcheck port `healthcheck` has been renamed to `healthcheck-to` (topic-operator) and `healthcheck-uo` (user-operator). Any custom PodMonitor, ServiceMonitor, NetworkPolicy, or similar resources that reference the old port name must be updated before or immediately after upgrading.

• breakingKafka 4.1.x support removed

  Kafka 4.1.x is no longer supported in 1.1.0. Clusters running Kafka 4.1.x must be upgraded to 4.2.1 or 4.3.0 before moving to this Strimzi version.

• breakingTLS truststore format changed to PEM for KafkaBridge and KafkaMirrorMaker2

  KafkaBridge and KafkaMirrorMaker2 now use PEM files instead of P12/JKS for TLS authentication and truststore. Review any tooling or external systems that expect P12/JKS formats from these components.

• breakingCRD v1 only — older API versions unsupported

  CRD API versions v1beta2, v1beta1, and v1alpha1 are not supported since 1.0.0. If you have not already converted your resources to v1, do so before upgrading to 1.1.0.

Strimzi 1.0.1 patches two CVEs and disables cross-namespace Entity Operator watching by default. The v1-only CRD API requirement from 1.0.0 remains enforced — no v1beta2/v1beta1/v1alpha1.

• securityPatch two CVEs — upgrade promptly

  CVE-2026-55225 and CVE-2026-55226 are fixed in 1.0.1. Details are in the Strimzi security advisories. Given both are fixed in the same patch release, treat this as a security-motivated upgrade and prioritize it over waiting for a convenient maintenance window.

• breakingEnable cross-namespace watching explicitly if you use watchedNamespace

  If your Kafka CR's Entity Operator section has watchedNamespace set to a namespace different from the Kafka cluster's namespace, the Topic or User Operator will stop watching it after upgrading. Before or immediately after upgrading, set STRIMZI_ENTITY_OPERATOR_WATCHED_NAMESPACE_ENABLED=true in your Cluster Operator deployment. Check all Kafka CRs across namespaces — missing this will silently break topic/user reconciliation.

• breakingComplete CRD migration to v1 before upgrading

  Strimzi 1.0.1 (like 1.0.0) only accepts v1 CRDs. If you skipped the migration step when moving to 1.0.0, or if you are upgrading from an older release directly, run the CRD conversion procedure documented in the Strimzi 1.0.1 deploying guide before applying the new operator manifests. Applying the operator without converted CRDs will cause reconciliation failures.

Strimzi 1.0.0 drops all pre-v1 CRD APIs — this is a hard requirement before upgrading. Also adds Kafka 4.1.2 support, TLS on the HTTP Bridge, and environment-variable-based rack awareness.

• breakingConvert all CRDs to v1 API before upgrading — no exceptions

  Strimzi 1.0.0 flat-out removes v1beta2, v1beta1, and v1alpha1. If any of your custom resources still use those API versions, the operator will not reconcile them after upgrade. Run the CRD conversion procedure documented by Strimzi before touching anything else. This applies to KafkaTopic and KafkaUser resources too, which had their own v1alpha1/v1beta1 versions. Skipping this step will break your cluster management silently.

• enhancementSwitch rack awareness to environment-variable type to drop ClusterRoleBindings

  The new type: environment-variable rack awareness reads topology from env vars rather than querying the Kubernetes API, which means it no longer needs ClusterRoleBindings. If you're running in environments with tight RBAC policies or multi-tenant clusters, this is worth migrating to. Review your Kafka CR's rack configuration and update the type field — no other infrastructure changes needed.

• enhancementUseConnectBuildWithBuildah is now on by default — verify your Connect build pipelines

  This feature gate moving to beta means Buildah is now the default build tool for Kafka Connect connector builds. If you've been relying on Kaniko-specific behavior or have custom build configurations, test your Connect builds in a non-production environment after upgrading. The Buildah image is pinned in the release, so the toolchain is stable, but behavioral differences in layer caching or registry auth handling could surface.

Strimzi 0.45.2 is the final patch release for the 0.45.x branch, focusing on critical CVE fixes and Kafka 3.9.2 support while serving as the last version supporting ZooKeeper-based clusters.

• securityApply patch immediately for CVE fixes

  This release addresses multiple high-priority CVEs in ZooKeeper, JWT libraries, and networking components. Upgrade to 0.45.2 immediately to patch these vulnerabilities, especially if you handle sensitive data or run internet-facing services.

• breakingMigrate to KRaft before upgrading beyond 0.45.x

  This is your last chance to run ZooKeeper-based Kafka clusters in Strimzi. Plan your KRaft migration now since Strimzi 0.46+ will only support KRaft mode. Follow the official KRaft migration guide and test thoroughly in non-production first.

• breakingHandle Kafka 3.9.2 annotation issue for future upgrades

  If you're using Kafka 3.9.2, upgrading to Strimzi 0.46-0.51 will require manually updating pod annotations. Save the provided kubectl command for when you upgrade: it updates the Kafka version annotation on pods to prevent operator failures.

Strimzi 0.51.0 addresses critical CVEs and drops support for Kubernetes versions below 1.30, while adding Kafka 4.2.0 support and moving ServerSideApplyPhase1 to beta.

• securityUpgrade immediately for CVE fixes

  Two critical CVEs affect Strimzi 0.47.0 and newer versions. Review the security advisories to determine if your deployment is affected, then upgrade to 0.50.1 or 0.51.0 immediately. The CVE numbers appear to be from 2026, which suggests these may be embargoed vulnerabilities with delayed disclosure.

• breakingVerify Kubernetes compatibility before upgrading

  Strimzi 0.51.0 requires Kubernetes 1.30+. Check your cluster version before upgrading. If running Kubernetes 1.27-1.29, upgrade your cluster first or remain on an earlier Strimzi version until cluster upgrade is possible.

• breakingUpdate CRDs and KafkaUser resources during upgrade

  Manually upgrade CRDs as part of the Strimzi upgrade process, especially when using Helm. For clusters upgrading from 0.48 or older, update KafkaUser resources to use the new `.spec.authorization.acls[]operations` field format before upgrading.

Strimzi 0.50.1 is a critical security patch addressing two CVEs affecting versions 0.47.0+, with mandatory CRD upgrades and final support for Kubernetes 1.27-1.29.

• securityImmediate upgrade required for CVE fixes

  If running Strimzi 0.47.0 or newer, immediately review the CVE advisories and upgrade to 0.50.1. These are critical security vulnerabilities that require urgent patching in production environments.

• breakingUpdate KafkaUser resources before upgrading

  Before upgrading, update all KafkaUser resources to use .spec.authorization.acls[]operations field instead of the deprecated .spec.authorization.acls[]operation field to avoid compatibility issues.

• breakingPlan Kubernetes upgrade for Strimzi 0.51+

  This is the final version supporting Kubernetes 1.27-1.29. Plan to upgrade your clusters to Kubernetes 1.30+ before upgrading to Strimzi 0.51.0 or newer to maintain compatibility.