When Apache Kafka on OpenShift makes sense and what it asks of your platform team
Running Apache Kafka on OpenShift means hosting a self-managed Kafka cluster inside your own OpenShift platform, usually with the Strimzi operator managing brokers, controllers and their configuration as Kubernetes resources. It fits when your platform team already runs OpenShift as the standard place for stateful workloads, and when you want Kafka handled through the same change, access and recovery processes as the rest of the estate. Apache Kafka is licensed under the Apache License 2.0 and the Apache Software Foundation project offers no paid edition, so the software cost is zero and the costs you pay for are infrastructure, operations and any partner work. Kafka 4.x runs only in KRaft mode, so there is no ZooKeeper ensemble to host alongside the brokers, which simplifies the component list your team must support.
The platform team takes on more than the operator install. You need to confirm which Strimzi release matches the Kafka version you plan to run, which OpenShift version it supports, and whether your subscription or support contract covers the build you choose, since community Strimzi and vendor builds carry different support terms. Your team must also own storage classes for persistent volumes, security context constraints that allow the pods Strimzi creates, network exposure for clients outside the cluster, and the certificates and authentication settings that Kafka uses for clients, brokers and tools. Each of these is a decision with a cost and an owner. Confirm them with your OpenShift administrators and the Strimzi documentation before you commit to a design.
Ask early whether the cluster will serve one team or many, because that decides how much quota, topic governance and access control you must build before go-live. Kafka's authorization model stores ACLs in the cluster metadata, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so a shared platform needs ACL ownership defined from day one. If you cannot name the people who will patch the operator, rotate certificates and respond to broker failures on a weekend, the platform is not ready for Kafka yet, regardless of how well the install goes.
Which exposure, storage and security options fit your environment
Clients outside the OpenShift cluster need a listener that the broker advertises with a reachable address. Routes are the OpenShift-native way to publish an HTTP-based or TLS-passthrough endpoint, but Kafka's binary protocol and per-broker advertised addresses make the choice more involved than exposing a web service. Strimzi supports several listener types, and you should confirm in the current Strimzi documentation which ones suit your network, whether a Route-based listener is available for your Strimzi version, and how each broker gets its own address.
- Route-based listeners: Keep traffic on the OpenShift ingress path that your platform team already operates, which simplifies firewall and certificate ownership.
- Load balancer or node-port listeners: Often used where external clients need stable addresses outside the router tier, with more firewall and DNS work.
- Internal-only listeners: Suitable when every producer and consumer runs inside the cluster, and they remove external exposure entirely.
- Per-broker addressing: Every broker must be reachable at the address it advertises, so plan DNS names for each broker before testing clients.
- Client and network paths: Confirm that firewalls, proxies and any gateway permit the long-lived connections Kafka clients keep open.
Confirm the listener types and their version support in the Strimzi documentation before you commit to a topology, because the answer determines DNS, certificate and firewall work.
Kafka writes its log segments and, in KRaft mode, its metadata to the volumes you attach to each broker and controller. The storage class decides the disk performance, the failure behavior and whether a volume follows a pod to another node. Choose the class with the platform storage team, because the Kafka settings for retention and replication assume the disk can absorb sustained sequential writes and recover after a node failure.
- Local versus network-attached storage: Local disks give strong throughput but tie data to a node, while network-attached volumes survive node loss at the cost of latency and shared-array contention.
- Separate volumes for logs and metadata: Keeping controller metadata on its own volume protects it from broker log growth, which is easier to plan when node pools are separated.
- Volume expansion and reclaim policy: Confirm that the storage class allows expansion and that the reclaim policy will not delete data when a claim is removed by mistake.
- Replication versus storage redundancy: Kafka replicates partitions across brokers, so layering storage mirroring under it can multiply disk use without a matching gain.
- Snapshot and backup support: Confirm whether your CSI driver offers snapshots, and do not treat them as a substitute for tested topic-level recovery.
Ask the storage team for the throughput and latency characteristics of each class and test recovery after a simulated node loss before production use.
Kafka's security model is optional and layered. You can run unsecured listeners, but production clusters should authenticate clients and brokers and encrypt traffic. The documented options are SSL, which uses client certificates, and SASL mechanisms including GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Pick the mechanism that matches the identity system your organization already runs, and remember that each listener can use different settings.
- TLS with client certificates: Strong mutual authentication that fits well with an internal certificate authority, but certificate rotation becomes an ongoing operational task.
- SCRAM-SHA-512: Username and password credentials stored in the cluster, with simple onboarding for teams but a separate credential lifecycle to manage.
- OAUTHBEARER: Token-based access that integrates with an external identity provider, which suits organizations with central single sign-on, though it requires token validation configuration.
- Kerberos (GSSAPI): Fits environments already built on Active Directory or FreeIPA, with keytab management and time synchronization as dependencies.
- Authorization with ACLs: Authentication alone does not limit what a client can do, so define ACLs for each principal in the KRaft metadata log and avoid relying on the allow-everyone default.
Confirm with your identity team which mechanism they will support long term, and check how the chosen mechanism is configured for Strimzi listeners in the version you deploy.
Key configuration choices and when each one fits
This table compares the settings your team decides before installing Kafka on OpenShift: listener type, authorization default, storage class and Java version. Read each row as a decision with a condition under which it fits, and confirm the platform-specific details with your Strimzi and OpenShift versions before committing.
| Setting | Option and when it fits | Trade-off to check |
|---|---|---|
| Listener type | Internal listeners with TLS or SASL for pods inside the cluster. Use an external listener only when clients outside OpenShift must connect. | Each external listener adds a Route or load balancer path to secure and monitor. Confirm the Route or ingress options your OpenShift version supports. |
| Authentication mechanism | SSL or SASL. Kafka documents GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Choose the one your identity provider can issue credentials for. | Security is optional in Kafka, so an unsecured listener can remain if it is not explicitly removed. Disable plaintext listeners in the design. |
| Authorization model | StandardAuthorizer, which stores ACLs in the cluster metadata log. Fits KRaft clusters where ACLs must be managed with the cluster itself. | Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Keep it false or unset for least privilege. |
| Allow.everyone.if.no.acl.found | Leave at the default for production. Set to true only for a short, documented test where open access is intended. | Setting it to true opens resources that lack ACLs to all authenticated principals. Confirm the setting in your Strimzi-managed configuration. |
| Storage class | Use a block storage class that gives each broker and controller its own persistent volume. Choose a class with the performance and reclaim behavior your data needs. | Storage class behavior varies by OpenShift provider. Confirm volume binding, expansion and reclaim policy with your storage team. |
| Java version | Java 17 for brokers and Connect on Kafka 4.0 and later, as the Kafka upgrade notes require. Clients and Streams applications need at least Java 11. | Keep the JVM on a current patch level so security fixes are applied. Confirm the Java image Strimzi uses for your release. |
| Upgrade starting point | Clusters on KRaft older than 3.3.x should move to 3.9.x before 4.x. ZooKeeper-based clusters must migrate to KRaft first. | Plan the upgrade path before choosing an operator version, because the Kafka version must match what the operator supports. |
| Controller and broker layout | Dedicated controller and broker node pools fit clusters that need independent scaling. Combined roles fit small test clusters. | Dedicated pools add more resources to manage. Confirm the node pool features in your Strimzi version. |
Setup sequence from operator install to a verified external listener
This sequence takes a Kafka cluster on OpenShift from a checked platform to a running KRaft cluster that an external client can reach through a Route and use to produce and consume a test message. Each step ends with a check so the next step starts from a known state.
Confirm OpenShift and Kubernetes version support
Before anything is installed, the platform team confirms that the OpenShift release in your environment and the Kubernetes version beneath it are supported by the Strimzi release you plan to run, and that the Kafka version you intend to deploy is listed on the Apache Kafka downloads page as supported. Ask your vendor or the Strimzi documentation to confirm the compatibility matrix for your exact versions, since this is not a detail to assume. Done means you have a written version record for the platform, the operator and Kafka, signed off by the platform owner.
Install the Strimzi operator into a dedicated namespace
A cluster administrator or a user with rights to create operators installs the Strimzi operator, usually through OperatorHub or a subscription managed by your platform team, into a dedicated namespace. Decide whether the operator watches one namespace or several, because that choice sets its permissions. Done means the operator pod is running and healthy, and the Strimzi custom resource definitions for Kafka and KafkaNodePool are registered in the cluster.
Define KafkaNodePool resources for controllers and brokers
The platform team writes KafkaNodePool resources that separate controller roles from broker roles, each with its own replica count, roles and storage. Keeping the pools distinct lets you scale brokers without touching the KRaft quorum. Apply the manifests in the Kafka namespace and check that the pods are scheduled. Done means the node pool resources are accepted by the operator and their pods are pending or starting, ready for storage binding.
Configure storage classes for each node pool
Map each node pool to a storage class that the cluster provides, using persistent volumes sized and performance-rated for log and metadata directories. Confirm with your storage team that the class supports the volume mode and access pattern the pods need, and that reclaim behavior matches your retention policy. Done means the persistent volume claims bind to volumes and show the Bound state for every broker and controller.
Grant the security context constraints the pods need
Strimzi pods run with a restricted security context by default, but some storage or image settings may require an additional grant. Review the pods that fail to start, identify the constraint they match, and grant only the specific security context constraint or role binding needed to the Kafka service account, rather than a broad privileged grant. Done means all Kafka pods reach the Running state and the events show no admission rejections.
Create the Kafka cluster in KRaft mode
Apply the Kafka custom resource that references the node pools, sets the Kafka version, configures the internal listener with TLS or SCRAM as your security design requires, and defines the planned replication and retention defaults. The operator bootstraps the KRaft quorum and brokers. Done means the Kafka resource reports Ready, all controllers form a quorum, and the brokers register with it.
Expose an external listener through a Route
Add an external listener of type route to the Kafka resource with the TLS and authentication settings your access model requires, and confirm the advertised hostnames that the Route generates for each broker. Clients outside the cluster connect to those hostnames, so mismatched advertised addresses are a common cause of failed connections. Done means the bootstrap Route and broker Routes exist and resolve from the network where external clients will run.
Verify with a test producer and consumer
From a machine outside the cluster, a platform engineer runs a Kafka producer and consumer against the bootstrap address through the Route, using a test topic created through the Kafka custom resource or admin tooling. The consumer must receive the message the producer sent, over the authenticated and encrypted listener. Done means the round trip succeeds, the test topic appears in the cluster metadata, and the result is recorded with the versions tested.
Security controls to set on the OpenShift side and the Kafka side
A Kafka cluster on OpenShift is secured in two places: the platform decides what a broker pod may do and where secrets live, and Kafka decides who may connect and what they may touch. Gaps usually appear at the seam between the two, so set and verify both layers together before any client connects.
Security context constraints and pod security
Kafka pods need a non-root user, a read-only root filesystem where possible, and writable volumes only for the log and metadata directories. Confirm which security context constraint your cluster assigns to the Strimzi-managed pods, and whether it permits privilege escalation or host paths. Avoid granting a broad built-in constraint to the whole namespace just to get pods scheduled. Review the pod security settings against the Pod Security Standards before go-live.
TLS on every listener
Kafka encrypts traffic between clients, brokers and tools with SSL/TLS, but security is optional, so a listener left as plaintext will accept connections silently. Define one internal listener for inter-broker traffic and one or more external listeners for clients, and mark each with its own TLS setting. Decide which certificate authority issues broker certificates and how renewal is handled. Verify that no plaintext listener is exposed through a Route.
SASL mechanism selection
Kafka supports GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER for SASL authentication. Choose the mechanism that matches your identity source, for example OAUTHBEARER where an OpenShift or external identity provider issues tokens, or SCRAM where credentials are managed inside Kafka. Avoid PLAIN on any listener that carries credentials without TLS. Confirm that the chosen mechanism is supported by the client libraries your application teams use.
ACLs and the default deny rule
In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log. Resources without ACLs are limited to super users unless allow.everyone.if.no.acl.found is set to true, so leave that setting false in production. Grant each application principal read or write rights only on the topics and consumer groups it uses. Record which principals are super users and keep that list short.
Least-privilege RBAC for Kafka custom resources
Strimzi resources such as Kafka, KafkaNodePool, KafkaTopic and KafkaUser define the cluster, and anyone who can edit them can change listeners, storage and access. Bind edit rights on these resources only to the platform team, and give application teams read access or a self-service path through reviewed templates. Restrict who can read secrets generated for users, since those hold client credentials. Audit changes to these resources in the cluster logs.
Secrets stored unencrypted by default
Kubernetes stores Secrets unencrypted in etcd by default, and the broker keystores, user credentials and client passwords created for Kafka live there. Configure encryption at rest for etcd on your OpenShift control plane and confirm it with the platform team. Limit list and watch access to these Secrets with RBAC, and consider an external store through the Secrets Store CSI Driver for certificate material. Rotate broker and user credentials on a schedule you document.
Community Strimzi versus vendor builds: what support actually covers
The support difference between community Strimzi and a vendor-packaged build is not something you can infer from the Kafka project, so confirm it with each vendor in writing before you choose. Apache Kafka is licensed under the Apache License 2.0 and the project itself has no paid edition. The supported Kafka releases listed on the downloads page are 4.3.1, 4.2.2 and 4.1.2, and earlier versions are archived. Those release lines describe what the Kafka project maintains, not what an operator or a vendor will support on your OpenShift cluster. A community Strimzi deployment relies on the Strimzi project's own release and patch cadence, and any commercial packaging adds a contract with its own terms.
Ask each vendor four specific questions and get the answers in the contract or a signed support statement. First, what is the patch cadence, and how far behind upstream Kafka and Strimzi releases do their builds run? Second, what is the CVE response: which severities are covered, what is the target time to a fix or workaround, and who notifies you? Third, which OpenShift versions appear in their support matrix, and what happens when you upgrade OpenShift before they certify the next version? Fourth, which Kafka versions, including the 4.x lines, are covered, and does the coverage extend to the Kafka Connect and Java images you run alongside the brokers? Write down the dates the vendor commits to, because a support matrix without dates is hard to hold them to.
Map each answer to your own change process before the build starts. A vendor build that lags the Kafka release you need can push you into a version you cannot upgrade from later, so check the rolling upgrade path against the Kafka upgrade notes and your planned Strimzi release. Confirm who owns the image pipeline in an air-gapped or restricted network, since a vendor image pulled into an internal registry may need a separate mirroring process. Your team should also decide who receives vendor security bulletins and who can approve an out-of-cycle patch, because a support commitment that depends on a mailing list nobody reads does not reduce your exposure. Quotes for vendor support are separate from any implementation scope, so ask for both as separate line items.
Limits to confirm for your OpenShift and Kafka versions
Several limits on a Strimzi-based Kafka platform depend on versions that move on their own schedules. Operator, OpenShift, Kubernetes, Java and Kafka releases each constrain the others, so confirm them together before you commit to a build. The cards below cover the checks that most often change the plan.
Operator and OpenShift compatibility
Each Strimzi operator release supports a specific range of OpenShift and Kubernetes versions and specific Kafka releases. Check the compatibility matrix for the exact operator version you plan to install, not the latest one. Kubernetes itself has a limited support window, and the Kubernetes release page lists the three most recent minor releases as maintained. Ask the vendor or project which OpenShift versions your chosen operator build has been tested against, and plan your cluster upgrade order around that answer.
Rolling upgrade paths
Kafka supports rolling upgrades from each release in the past year, which is the last three releases, to the latest version. A cluster several releases behind may need intermediate steps, and the operator version can limit which Kafka versions it will manage. Map your current Kafka version to the target through each step before scheduling maintenance windows. Confirm the path in the release plan and the upgrade notes for each release you pass through.
Java 17 for brokers
Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, while clients and Kafka Streams applications need at least Java 11. Container images built for older Java runtimes will not start the broker, so check the base image you plan to use in the Strimzi build. Clients running on OpenShift may use a different Java level from the brokers, and that difference should be recorded in your platform standards. Ask which Java version the image you pull ships with and how patch updates reach it.
ZooKeeper to KRaft migration
Apache Kafka 4.0 supports only KRaft mode, and ZooKeeper-based clusters must migrate to KRaft before upgrading to 4.x. The upgrade notes also recommend that KRaft clusters older than 3.3.x first move to 3.9.x. If you are moving an existing cluster onto OpenShift, record the current metadata mode and version before choosing the operator release. Ask your team or partner to confirm the migration sequence against your current version, since this step cannot be skipped by a later upgrade.
Multi-site needs beyond one cluster
A single OpenShift cluster does not provide cross-site disaster recovery for Kafka by itself. If your recovery targets need a second site, decide early between one cluster per site with mirroring, an aggregate view, or a stretched layout. MirrorMaker 2 replicates topics, configuration, consumer group offsets and ACLs between clusters, which can serve as the basis for that design. Confirm the network latency, data residency rules and recovery objectives for each site before the cluster count is fixed.
Questions teams ask before running Kafka on OpenShift
What drives the cost of running Kafka on OpenShift?
The cost is mostly people time and infrastructure, and both depend on the scope you set. Apache Kafka itself is licensed under the Apache License 2.0, so there is no license fee from the project. The recurring costs are the OpenShift capacity for brokers and controllers, the storage classes you back them with, the network between sites or zones, and the staff time to operate the cluster. Ask any partner for a quote built from a written scope that lists the Strimzi version, the number of node pools, the authentication model, the external listener design and the backup approach. Those choices move the price more than anything else.
Can our platform team run Kafka on OpenShift without outside help?
Yes, many teams do, provided they already operate OpenShift and have people who understand Kafka's replication, storage and security model. The harder parts are the first deployment, the security context constraints that match the Strimzi pods, the Route design for external clients and the upgrade sequence. Assess your team against those four areas before deciding. A fixed-scope engagement from DeployOpen can cover the build and hand over runbooks, or a retainer can cover upgrades and testing afterward. Either way, confirm the handover terms in writing.
What determines how long an OpenShift Kafka build takes?
Duration follows the number of decisions still open when work starts. Teams that have already settled the topology, storage, identity provider and certificate authority usually move faster than teams that are still choosing them. Other drivers include whether the cluster must run in a restricted network, how many external clients need Routes, whether Kafka Connect or other integrations are in scope, and how many environments you need for testing. No duration is given here because it depends on those inputs. Ask for a timeline as part of the written scope, with the assumptions listed.
What does the work need from the OpenShift platform team?
The platform team provides the cluster, the rights to install operators, and the storage and networking decisions that Kafka depends on. Expect to supply a project or namespace model, a storage class with suitable performance, the Ingress domain for Routes, and a way to issue and rotate TLS certificates. Security context constraints must be reviewed with the cluster administrators, since Strimzi pods need settings that the default policy may block. Confirm early who has cluster-admin access during the build and how changes move through your change process.
Does a vendor build of Strimzi change the support model?
Yes. Community Strimzi is an open-source project with its own release cadence and community support, and the Kafka project itself does not sell support. A vendor build may add contractual support, a different release schedule, supported image tags or certified combinations with OpenShift. Those terms are set by the vendor, not by the Apache Kafka project, so read the support agreement before you choose. Ask which Kafka versions and Strimzi versions are covered, how security patches are delivered, and whether DeployOpen's work on your cluster is affected by the vendor's terms.
Which Kafka version should we pick for an OpenShift deployment?
Pick a version that appears on the Kafka downloads page as supported and that your Strimzi release documents as compatible. The downloads page currently lists 4.3.1, 4.2.2 and 4.1.2 as supported releases. Kafka 4.0 and later run only in KRaft mode, and Java 17 is required for brokers, so confirm the Java runtime in the container image you plan to use. Check the Kafka upgrade notes before you choose a starting version, and plan the upgrade path so you can move between supported releases.
What compliance evidence should we plan for an OpenShift Kafka cluster?
Plan for evidence that shows how the cluster is configured, who can reach it, and how it is backed up and patched. Useful artifacts include the Strimzi and Kafka versions in use, the authorization model, TLS settings, the storage and backup design, change records and test results. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations, so ask them early which evidence they expect.
How upgrades for Kafka and OpenShift interact over time
Kafka upgrade paths, Kubernetes version skew and OpenShift release timing have to be planned as one schedule, not three. On OpenShift, the Strimzi operator sits between the two: its version determines which Kafka versions it can deploy and manage, and the Kubernetes API it calls determines which OpenShift releases it runs on. Before you upgrade anything, record the current Kafka version, the Strimzi operator version, the OpenShift version and the planned target for each. Confirm the Strimzi compatibility matrix for your operator release and the OpenShift lifecycle dates with Red Hat, since those dates are not part of the facts available to this page. Kafka itself is not upgraded by the operator alone; the operator rolls the brokers, but the version you move to must be one the operator supports.
Kafka supports rolling upgrades from each release in the past year, which the time-based release plan describes as the last three releases, to the latest version. Plan your Kafka hops against that rule. A cluster older than that window needs intermediate steps, and any ZooKeeper-based cluster must already be on KRaft before the move to 4.x. Kafka 4.x supports KRaft only, so a Strimzi-managed cluster still on ZooKeeper cannot simply take a 4.x image. The current supported releases are 4.3.1, 4.2.2 and 4.1.2 on the Kafka downloads page, so check that your target appears there at the time of the change window.
The Kubernetes version skew policy is the constraint that most often blocks an OpenShift change. In plain terms, the API server moves first, one minor version at a time, and kubelets on worker nodes may run up to three minor versions behind it. That gives you room to upgrade the control plane before the nodes, but it does not let you skip minor versions. Schedule the OpenShift cluster upgrade so that the Strimzi operator remains supported at every step, and rehearse the full sequence in a non-production cluster. Ask Red Hat or your platform team to confirm the exact skew behavior for your OpenShift release, because managed OpenShift products may impose stricter sequencing than the upstream policy.
How DeployOpen scopes and delivers a Kafka deployment on OpenShift
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including OpenShift clusters you control. For Kafka on OpenShift, we start from a written scope that fixes the Strimzi version, node layout, Routes, storage and access model before any cluster is built.
How we scope
- Written scope covers the OpenShift cluster, Strimzi operator version, node pools, storage classes and security context constraints.
- Scope lists which clients connect from outside the cluster, and which Routes, listeners and TLS settings that requires.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We install the operator and deploy KRaft-mode clusters with dedicated controller and broker node pools.
- Build includes listener and Route configuration, authentication and ACLs, and the retention and partition plan you approved.
- We test failover, rolling restarts and client connectivity from inside and outside the cluster before sign-off.
How we hand over
- You receive runbooks for scaling pools, rotating certificates, operator upgrades and restoring from failure.
- Documentation records versions, configuration decisions, network paths and the evidence produced during testing.
- Handover includes a walkthrough with your platform and security teams so they can operate the cluster unaided.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope is set in writing, covering Strimzi and Kafka upgrade planning against the supported release lines you run.
- Confirm with your own team which support model fits your change control and who owns OpenShift platform updates.
