Strimzi 1.3.0: New Operational Defaults and Security Options

A hand carefully adding a wooden block to an existing structure in warm sunlight — Review the existing deployment, then evaluate Strimzi 1.3.0's changed defaults and new options one step at a time.

Strimzi, the Operator that manages Kafka deployments on Kubernetes, released version 1.3.0 on October 12, 2026 (October 13 in Korea). It raises the minimum Kubernetes version, changes defaults for Connect builds and rolling updates, and adds options for internal security and certificate issuance.

When planning an upgrade, start with changes that affect existing deployments. Internal security configuration and cert-manager integration are still Early Access and belong in separate test environments. This article uses the release notes and documentation from the 1.3.0 tag to explain what changed and what to check before adopting it.

Changes to check first

Area	Change in 1.3.0	What to review
Platform	Kubernetes minimum rises to 1.32	Clusters on 1.30 or 1.31
Connect builds	Buildah reaches GA; Kaniko is removed	Strimzi’s built-in image builds
Rolling updates	Background Pod deletion enabled by default	CNI and graceful shutdown behavior
Internal security	Encryption and authentication options in Early Access	Internal connection requirements
Certificates	Early Access cert-manager integration	Issuance and renewal workflows

The full list is available in the 1.3.0 changelog.

Check Kubernetes and Kafka versions separately

The minimum Kubernetes version is 1.32, with an official tested range of 1.32–1.37. Strimzi 1.2.0 listed 1.30–1.36, so installations on Kubernetes 1.30 or 1.31 need a platform upgrade first.

Kafka 4.2.2 support is new. The full supported set is 4.2.0, 4.2.1, 4.2.2, 4.3.0, and 4.3.1. Kafka 4.3.1 was already supported by Strimzi 1.2.0. Official compatibility table

Record the current configuration before planning changes. These commands only read resources; replace the kafka namespace with your own.

kubectl version -o yaml
kubectl get kafka -n kafka \
  -o custom-columns='NAME:.metadata.name,KAFKA:.spec.kafka.version,IMAGE:.spec.kafka.image'
kubectl get kafkaconnect -n kafka \
  -o custom-columns='NAME:.metadata.name,KAFKA:.spec.version,IMAGE:.spec.image'

An empty IMAGE column means there is no explicit image override in that field. Check actual Pod images and the Operator’s image mappings too. Recording the Operator version, Kafka version, and base version of each custom image makes subsequent changes easier to trace.

For installations coming from 0.x, the v1-only CRD API requirement dates from 1.0.0. Review the migration procedure for your starting version and convert older resources and CRDs before crossing that boundary. Release API migration notice

Built-in Connect builds now use Buildah exclusively

UseConnectBuildWithBuildah reaches general availability (GA), making Buildah the fixed choice for Strimzi’s Connect image builds. Kaniko is removed, and a feature gate can no longer restore it. The change applies to images built with plugins through KafkaConnect.spec.build. 1.3.0 changelog

Rebuild an existing plugin set in a test environment. Check build Pod creation, plugin downloads, registry authentication and push, and connector loading from the resulting image. Remove an explicit -UseConnectBuildWithBuildah setting if it was used to retain Kaniko.

For custom images, verify startup scripts and JMX configuration too. Follow a successful build with checks that Connect starts and metrics are collected correctly.

Rolling updates use a different Pod deletion policy

UseBackgroundPodDeletion moves to Beta and is enabled by default. During rolling updates, the Operator uses background deletion propagation for Pods.

Some Kubernetes network plugins (CNIs) remove networking too early during Pod deletion, interrupting Kafka’s shutdown communication. The change aims to preserve networking until that communication completes. During rolling update tests, compare shutdown logs, controller communication, and in-sync replica (ISR) recovery time alongside Pod readiness. See the feature documentation for the motivation.

It can still be disabled through the Cluster Operator’s environment configuration. This is a container environment fragment; preserve other entries in an existing feature gate list.

env:
  - name: STRIMZI_FEATURE_GATES
    value: "-UseBackgroundPodDeletion"

Documentation discrepancy: As of October 14, 2026, the individual feature description in the deployment guide still says it is disabled by default. The release notes and 1.3.0 FeatureGates.java agree that it is enabled. This article follows the tagged implementation.

Internal encryption and authentication become configurable

The strimzi.io/internal-cluster-security annotation selects internal encryption and authentication. Without it, the default remains TLS encryption with certificate-based mutual authentication (mTLS). Security for the client listeners that applications connect to is configured separately.

One new option authenticates internal components through Kubernetes ServiceAccount tokens instead of certificates. This feature is Early Access, and its annotation is a temporary interface. Check the required permissions (RBAC) and token issuer prerequisites before experimenting. Internal security configuration

Changing an existing cluster’s internal security configuration requires downtime. Editing the annotation alone conflicts with .status.clusterSecurity and fails the Operator’s state reconciliation. The documented procedure includes pausing reconciliation, stopping the cluster, and resetting its recorded security state. Schedule this as a separate maintenance operation. Security migration procedure

cert-manager can issue component certificates

Strimzi can integrate with cert-manager to issue component certificates. The release explicitly says this Early Access integration is not recommended for production. Release notice

Set the CA type to cert-manager and generateCertificateAuthority to false. Provide a reference to the issuing Issuer or ClusterIssuer, along with the trusted CA certificate.

Users issue client certificates through cert-manager and configure KafkaUser authentication as tls-external. Test that clients also load renewed certificates. Switching an existing cluster triggers a multiphase rolling restart. cert-manager configuration procedure

A known issue leaves existing Certificate resources behind when switching from a cert-manager CA to a custom CA; manual cleanup is required. Include rollback and leftover-resource inspection in the experiment. 1.3.0 known issues

Other operational changes

Review these items from the 1.3.0 changelog according to the components you use.

Projected ServiceAccount tokens: Strimzi-managed Pods can mount them. Mounting a token does not automatically change Kafka authentication. The source currently supported in additional projected volumes is a ServiceAccount token.
PKCS12 deprecation: It is not removed in this release. A future release will default STRIMZI_PKCS12_KEYSTORE_GENERATION to false. Inventory clients and scripts that consume .p12 files.
Kafka Exporter 1.10.0 and HTTP Bridge 1.2.0: Include metrics collection and HTTP integration checks where applicable.
Grafana examples: New panels cover fenced brokers, offline replicas, and ISR shrink, expand, and failed updates. Compare imported dashboards with the new examples before incorporating changes.

An upgrade review sequence

The following sequence separates compatibility work from optional feature adoption:

Verify Kubernetes, CRD API, Kafka, and custom image compatibility.
Find Buildah disablement and explicit Pod deletion overrides in feature gate settings.
Test Connect builds and Kafka rolling updates; compare shutdown time, recovery time, and client errors.
Review PKCS12 dependencies and Exporter, Bridge, and dashboard changes.
Evaluate internal security changes and cert-manager in separate experiments.

Follow the Strimzi 1.3.0 upgrade documentation for the actual installation-specific procedure. These are review criteria; this article does not report a live cluster upgrade test.