Best Kafka UI tools for Strimzi (Kafka on Kubernetes)

Tools compared

Rank	Tool	Total (out of 100)	Out of the data path	mTLS, SCRAM and OAuth on Strimzi	Production access on request	Audit trail per person	Many teams, shared clusters	Runs on Kubernetes	Cost a year, one cluster (modelled)
1	Kpow	90	One container, no external database, not a proxy	All three documented for Strimzi; OAuth needs the -strimzi image	Temporary policies, staged approvals, masking	Names the person, includes data reads	Tenants per team	Helm chart, one pod mounting Strimzi Secrets	$7,380
2	Kafbat UI	63	One container	SSL and SCRAM published; no OAuth guide	RBAC, no approvals or expiry	Audit topic, no view	Roles per resource	Helm chart; UI cluster add fails on Kubernetes	$8,640
3	StreamsHub Console	62	API, UI and operator, no database	Reads the listener and KafkaUser from Strimzi	OIDC roles, no approvals or masking	None documented	Roles per cluster and resource	Operator and a Console resource	$8,640
4	AKHQ	60	One container	Strimzi OAuth client bundled	Regex groups, no approvals	Opt-in topic, no reads	Regex groups	Helm chart; memory reports	$8,640
5	Strimzi resources with kubectl and Grafana	58	Nothing new to deploy	Defines users; reads no records	Kubernetes RBAC on resources	Kubernetes API audit, no data reads	Namespaces and ACLs	Kubernetes itself	$11,520
6	Lenses	54	HQ on PostgreSQL plus an agent per cluster	SSL and SCRAM; OAuth not documented	Global masking, no approvals	In-product audit log	Group roles only	Helm charts plus PostgreSQL	$20,882 before EC2 charges
7	Redpanda Console	51	One container	Documented generally, nothing for Strimzi	Behind a paid Enterprise licence	Not documented	Licence-gated roles	Container and Helm chart	$8,640 plus an unpublished licence for RBAC
8	Conduktor	62	Console on PostgreSQL; Gateway, a proxy, for data-level controls	Java client properties; SCRAM documented	Masking exemptions, owner approvals	70+ event types in the UI	Groups; Virtual Clusters need Gateway	Kubernetes deployments plus PostgreSQL	$32,880; $122,880 with Gateway Core and Protect

The tools, ranked for Strimzi

What teams on Strimzi (Kafka on Kubernetes) need

Strimzi runs Kafka on Kubernetes through operators and custom resources: a team declares the cluster, its topics, its users and its Kafka Connect clusters as YAML, and the operators make the brokers match. That gives a platform team GitOps for the cluster itself. It does not give engineers a way to read the records in a topic, and Kubernetes RBAC decides who may change a custom resource, not who may read a record or reset a consumer group. Everything on this page is about what a tool adds on top of Strimzi, not about replacing it. For Kafka that is not run by an operator, see the best Kafka tools for self-managed Apache Kafka, and for the broader field of Kafka tools on any distribution, see the best Kafka management tools.

mTLS, SCRAM and OAuth on Strimzi. The first requirement is signing in the way the listeners are configured. Strimzi listeners authenticate clients with mTLS, SCRAM-SHA-512 or OAuth 2.0. The Cluster Operator keeps the Cluster CA public key in a <cluster>-cluster-ca-cert Secret, and the User Operator writes each KafkaUser’s PKCS #12 keystore and its password, or its SCRAM password, to a Secret of its own, as Strimzi’s deployment documentation describes. A tool on Kubernetes should mount those Secrets rather than hold copies, and for OAuth it needs a client that can fetch a token from the identity provider, which for Java tools is usually Strimzi’s own OAuth client library. Kpow publishes a Strimzi guide for all three mechanisms and a build that bundles the OAuth library, and AKHQ bundles the same library. StreamsHub Console takes the listener and the KafkaUser straight from Strimzi’s resources. Redpanda Console documents the three mechanisms for Kafka in general, while Kafbat UI and Lenses document SSL and SCRAM but not OAuth.

The tools differ most on OAuth 2.0, because fetching a token needs code in the client. Strimzi’s own components, Kafka Connect, MirrorMaker 2 and the HTTP Bridge, sign in with the login callback handler from Strimzi’s OAuth library, and its documentation notes that Strimzi does not decide which OAuth 2.0 flow a client uses, which depends on the authorization server and the client. A Java tool can follow Strimzi’s recipe only when that library is inside its image, which is why Kpow publishes a separate -strimzi build and AKHQ ships the library in its standard image. Recent Apache Kafka clients also include a production OAUTHBEARER implementation of their own, which fetches a token from a token endpoint with the client credentials grant, so a Java tool on a current client library has a second route that uses no Strimzi code. That route has to be tested against the token settings on the listener, and the scores on this page go to the recipes each tool documents.

mTLS on Strimzi comes with a renewal date. The cluster CA and clients CA certificates are valid for 365 days by default, and renewal starts 30 days before they expire. When the clients CA is renewed the User Operator regenerates every user certificate, and Strimzi’s documentation states that the operators do not manage client applications, which have to be using the renewed credentials before the old ones expire or they can no longer connect. A Kafka UI is one of those clients. Where its truststore and keystore are mounted from the Secrets as volumes, Kubernetes updates the mounted files after a Secret changes, except for a Secret mounted through subPath, which does not receive the update. A tool whose certificates were copied into its own configuration keeps the old ones. The renewal therefore belongs in the runbook of every tool on this page that connects over TLS. Mount the Secrets instead of copying them, and restart the tool’s pod after each renewal. Strimzi’s maintenance time windows let a team choose when the renewal itself runs, so the restart can be planned for the same window. A listener that presents a certificate from the organisation’s own CA is a separate case, because the tool then has to trust that CA, which is not the one in Strimzi’s cluster CA Secret; Strimzi’s documentation on custom listener certificates covers the configuration.

Working with the operators. The second is working with the operators rather than against them. Strimzi’s Topic Operator reverts configuration changes made outside a KafkaTopic resource for any topic that has one, and leaves topics without one alone. With the strimzi.io/use-connector-resources annotation on a Kafka Connect cluster, changes made through the Connect REST API are reverted too. The User Operator manages the ACLs, quotas and SCRAM credentials of every user it is not told to ignore, so ACL changes for those users also belong in their KafkaUser resources. The best tools to manage Kafka topics at scale and best tools to manage Kafka ACLs pages score the Topic and User Operators against the other ways of doing this. So on Strimzi a Kafka UI is mostly where engineers read data, watch consumer groups, reset offsets and act on resources that are not owned by a custom resource, while changes to operator-managed topics and connectors stay in Git. Every tool on this page is in the same position here; none of them writes KafkaTopic resources for you. StreamsHub Console at least marks which topics and connectors the operators manage.

On Kafka Connect, Strimzi’s documentation on limiting access to the Kafka Connect API states that when KafkaConnector resources are not in use, the default Kubernetes RBAC rules do not limit access to the Connect REST API, and it describes how someone with that access could point a connector at a database of their own to capture its credentials. On a Connect cluster run that way, the roles in the tool people use become the per-person control over connectors, because Kubernetes RBAC does not provide one. With KafkaConnector resources switched on, Strimzi can also restart failed connectors and tasks itself: autoRestart retries with a growing back-off and, by default, indefinitely unless maxRestarts is set. What an operator needs from a tool there is the state of each task and the stack trace of the failure, since the restart is already handled.

Strimzi’s releases also decide which Kafka versions a cluster can run. Strimzi 0.46 added Kafka 4.0 and removed support for ZooKeeper-based clusters in the same release, so every cluster on a current Strimzi runs in KRaft mode, and a UI that still reads ZooKeeper for metadata has nothing to connect to.

Production access on request. The third is the governance Kubernetes leaves open. When twenty engineers share one tool, the KafkaUser the tool connects as is the tool’s own, so per-person roles, production access that is granted on request and expires, masking of sensitive fields and an audit trail of who read or changed what have to come from the tool.

On Strimzi the credential that reads a topic is a Kubernetes Secret. By default only Kubernetes cluster administrators can view, create, edit or delete Strimzi resources until someone is given the strimzi-view or strimzi-admin role, and Kubernetes’ own good practices for Secrets say to restrict get, watch and list access to Secrets for people. An engineer who is handed a KafkaUser Secret so that they can run the console consumer holds everything in that user’s ACLs for as long as the credential is valid, because the ACLs are declared in the KafkaUser resource and nothing in them expires. Creating a KafkaUser for each engineer produces one long-lived certificate or password per person, and a Git change to give access followed by another to take it away. A tool that connects as one KafkaUser and signs people in through the identity provider keeps the Secrets out of people’s hands, and its grants can carry an end time, which a KafkaUser’s ACLs do not have.

Audit trail per person. Kubernetes has an audit log, and it has to be switched on. The Kubernetes auditing documentation states that the API server logs no events unless it is started with an audit policy file. Where a policy is in place, the log shows who changed a KafkaTopic or KafkaUser resource, and Git shows the same change as a commit. Neither record covers Kafka clients, because reading a topic, resetting a consumer group’s offsets and producing a test message are Kafka protocol requests made under the tool’s KafkaUser and never pass through the Kubernetes API. A record of which engineer made them exists only where the tool writes one, with the person’s name from the identity provider and the reads included.

Many teams, shared clusters. Kubernetes namespaces look like the boundary between teams, and Strimzi’s operators do not use them that way. A Topic Operator watches a single namespace, and so does a User Operator, by default the namespace of the Kafka cluster. The KafkaTopic and KafkaUser resources of every team on a shared cluster therefore sit together in one namespace, where a Role scoped to a team’s own namespace does not reach them. What separates teams on the cluster is the convention in Apache Kafka’s multi-tenancy guidance, topic names that begin with the team’s prefix, with each KafkaUser’s ACLs declared against the same prefix. A tool gives a team a view of its own when its scoping can follow those prefixes, which is how Kpow tenants are defined, by including or excluding topics and groups by name, prefix or suffix. Quotas work per KafkaUser as well. Strimzi sets quotas in the KafkaUser resource so that a user does not overload the brokers, and because the tool connects as one KafkaUser, a quota on that user caps what people’s searches can take from a cluster that applications share.

Out of the data path. One requirement cuts across all three: where the tool runs. A tool that runs as one more pod in the cluster and connects to the brokers the way any Kafka client does adds nothing to the path producers and consumers take. A tool whose controls are enforced by a proxy that every client connects through becomes part of that path, and it has to be sized, kept available and kept in step with every client upgrade, and a tool with a database of its own is one more stateful workload in the cluster. On Strimzi that workload would sit in the same Kubernetes cluster the operators keep reconciling, with its own storage, upgrades and failure modes. Kpow is one container with no external database, installed in your own environment and out of the data path. It connects to the listeners with the same configuration as a Kafka producer or consumer and keeps its state in topics on the same cluster, so applications keep talking to the brokers directly and there is no second stateful workload to run. Those topics have no KafkaTopic resource, and Strimzi’s Topic Operator does not interfere with topics managed outside its resources, so the operator leaves them alone once Kpow’s KafkaUser has the ACLs to create and use them. Conduktor Console also connects to the brokers directly, with a PostgreSQL database of its own; Conduktor’s data-level controls, such as encryption, masking of the data itself and virtual clusters, run in Conduktor Gateway, a Kafka proxy that client applications connect through.

Strimzi’s own account of how clients reach Kafka on Kubernetes explains what running beside the cluster means in practice. A Kafka client connects directly to the broker that leads each partition, so a Kubernetes Service can carry only the first bootstrap connection and every broker needs an address of its own. A tool that runs in the cluster uses the internal listener and its bootstrap service, and nothing new is exposed outside Kubernetes. A proxy has to solve that per-broker routing again for every application that connects through it, which makes it a component to deploy and run in its own right. Kroxylicious, the open-source Kafka proxy, describes itself as a stand-alone component deployed between the applications and the cluster, with applications connecting to it instead of to the brokers. Strimzi also creates a NetworkPolicy for every listener, which allows connections from all namespaces by default; a team that restricts a listener with networkPolicyPeers adds the tool’s pod as one more permitted peer and changes nothing for its applications.

Runs on Kubernetes. The tools here divide on whether they talk to Kubernetes at all. StreamsHub Console gets its Strimzi-native connection by reading Strimzi’s resources through the Kubernetes API, and the ClusterRole in its install files lets the console get, watch and list Kafka, KafkaTopic, KafkaUser and KafkaConnector resources, patch Kafka and KafkaRebalance resources, and list pods. Those permissions are what let it mark operator-managed topics and pause reconciliation, and a platform team reviews them like any other grant on the Kubernetes API. A tool that connects only as a Kafka client needs no Kubernetes API access. The Kpow chart’s default values set automountServiceAccountToken: false, so the pod carries no Kubernetes API credential, and they run the container as a non-root user with privilege escalation off and all capabilities dropped, three of the controls in the Kubernetes restricted Pod Security Standard. The restricted profile also requires a seccomp profile, which the chart leaves to the team’s podSecurityContext.

Who runs Kpow on Strimzi (Kafka on Kubernetes)

Two Kpow customers have described in public running their own Kafka on Kubernetes with Kpow beside it: Claritev, on Rancher Kubernetes and moving to Oracle Kubernetes Engine, and NORD/LB, on Confluent’s Kubernetes operator rather than Strimzi; the best Kafka management tools for Confluent Platform page scores the options for that setup. Each card is tagged with the rubric criteria its evidence speaks to, and the grey tags name the other things the source covers.

How a team runs Strimzi (Kafka on Kubernetes) with Kpow

Installing it in the cluster. A team adds the Factor House chart repository and installs Kpow with the Helm charts, the kpow chart for Enterprise or kpow-ce for Community Edition, into the same Kubernetes cluster as the brokers or any cluster that can reach a listener. For OAuth it sets the image tag to the -strimzi build, for example factorhouse/kpow:96.5-strimzi. The chart’s values, published in the helm-charts repository, take volumes, volumeMounts and envFromSecret, which is how the Strimzi Secrets and the licence reach the pod. Kpow is designed to run as a single instance, and the chart sets one replica with autoscaling that stops at one, because only one instance may write Kpow’s internal topics on its primary cluster; teams that want a standby use the active/passive model in the deployment notes. The chart is listed on Artifact Hub under a verified publisher, where a security report from a scan of the container image is published for each chart version. A cluster with a read-only root filesystem policy enables the chart’s ephemeralTmp volume, since Snappy compression needs one writable directory. Docker Hub also lists a -rh-ubi tag, built from Red Hat’s Universal Base Image, for clusters that only admit UBI-based images; it is a separate tag from the -strimzi build.

A values file for mTLS. The Cluster Operator writes ca.p12 and ca.password to the <cluster>-cluster-ca-cert Secret, and the User Operator writes user.p12 and user.password to a Secret named after the KafkaUser. Mount both read-only, point Kpow at the files, and put the two passwords and the licence in a Secret of your own that envFromSecret loads:

image:
  tag: "96.5-strimzi"          # only needed for OAuth 2.0
envFromSecret: kpow-secrets    # licence, SSL_TRUSTSTORE_PASSWORD, SSL_KEYSTORE_PASSWORD
env:
  BOOTSTRAP: "my-cluster-kafka-bootstrap.kafka.svc:9093"
  SECURITY_PROTOCOL: "SSL"
  SSL_TRUSTSTORE_TYPE: "PKCS12"
  SSL_TRUSTSTORE_LOCATION: "/strimzi/cluster-ca/ca.p12"
  SSL_KEYSTORE_TYPE: "PKCS12"
  SSL_KEYSTORE_LOCATION: "/strimzi/user/user.p12"
volumes:
  - name: cluster-ca
    secret:
      secretName: my-cluster-cluster-ca-cert
  - name: kpow-user
    secret:
      secretName: kpow           # the KafkaUser's name
volumeMounts:
  - name: cluster-ca
    mountPath: /strimzi/cluster-ca
    readOnly: true
  - name: kpow-user
    mountPath: /strimzi/user
    readOnly: true

Both Secrets are mounted as whole volumes with no subPath, so when Strimzi renews the cluster CA or the user certificate the new files reach the pod, and a kubectl rollout restart of the Kpow deployment after the renewal loads them.

Signing in to the cluster. The team creates a KafkaUser for Kpow with the ACLs listed in Kpow’s minimum ACL permissions, then mounts the <cluster>-cluster-ca-cert Secret as the truststore and the KafkaUser’s Secret as the keystore for mTLS, or passes the SCRAM-SHA-512 password. Kpow creates its internal topics on the first cluster it connects to, so that KafkaUser’s ACLs include creating, reading and writing those topics, which the same page lists. For OAuth 2.0, Kpow’s Strimzi documentation sets SASL_MECHANISM=OAUTHBEARER with Strimzi’s JaasClientOauthLoginCallbackHandler and reads the client id, secret and token endpoint from environment variables, with a second recipe for Keycloak running on Kubernetes behind an internal CA.

Signing people in. Engineers sign in to Kpow through SAML, including Okta, Microsoft Entra ID and Keycloak, the same identity provider many Strimzi clusters use for broker OAuth, through OpenID Connect, or through LDAP, so access follows the company directory rather than the KafkaUser the pod connects as. The options for people’s sign-in are compared in best tools for Kafka SSO integration.

Connect and schemas. Kpow reaches a Strimzi Kafka Connect cluster through its REST service, configured as described in Kafka Connect configuration, and shows connector and task state in its Kafka Connect view. Where the Connect cluster uses KafkaConnector resources, the team reads state in Kpow and changes connectors in Git, because the operator reverts REST changes there. Where those resources are off, Kpow’s CONNECT_CREATE and CONNECT_EDIT permissions decide who may add or change a connector, which matters because Kubernetes RBAC does not limit the Connect REST API in that mode. Kpow connects to Apicurio Registry and other Confluent-compatible registries, per its schema registry documentation, so data inspect shows records decoded, and engineers filter them across topics with kJQ.

Watching lag and brokers. Kpow shows each consumer group down to partition level and resets, clears or skips offsets from the same view, and its brokers view shows broker configuration and detects under-replicated partitions. Kpow can also alter partition reassignments and elect partition leaders from the topic view, while Strimzi’s KafkaRebalance resource drives Cruise Control; the best tools to reassign Kafka partitions page compares the two approaches. Kpow’s own metrics, including consumer group lag, are exported to Prometheus, so they sit beside Strimzi’s broker metrics and Grafana dashboards. Strimzi’s own route to lag is Kafka Exporter, which its documentation says relies on data from the __consumer_offsets topic and so on consumer groups that are actively committing offsets, and which delivers lag as a Prometheus metric for a dashboard. Kpow shows the figure beside the group’s members and the offset reset, so the engineer who sees the lag can act on it under their own role.

Giving teams their own view of a shared cluster. Tenants limit which topics, groups and connectors each role can see, RBAC sets what each person may do, staged mutations hold an offset reset or topic deletion for approval, temporary policies grant production access that expires at a set time, and data policies mask sensitive fields in data inspect results on the server.

Keeping the record. The audit log records each action with the user from the identity provider, and a webhook sends those records to Slack, Microsoft Teams or any endpoint. That covers what the Kubernetes API audit log does not see: who read which topic and who reset which consumer group.

From the terminal. Engineers who already work in kubectl and k9s can use the Factor House terminal UI, in beta, for cluster health, lag, connector state and a quick look at data; it needs Kpow 96.5 or later with the API enabled. Changes made from the terminal go through the same staged approvals as the web UI. In the September 2026 product update it was described as the answer to what k9s for Kafka would look like.

Running Strimzi beside other clusters. Kpow’s documentation lists Strimzi among its Kafka providers, alongside Amazon MSK, Confluent, Aiven, Redpanda and self-managed Apache Kafka, so one instance can manage a Strimzi cluster beside the others a team runs, and a team moving workloads from a managed service to Strimzi keeps the same tool, roles and audit trail on both sides of the move; the Kafka UI tools for Amazon MSK page covers the MSK side.

No tool here leads on every criterion. OAuth against Strimzi needs Kpow’s separate -strimzi image, and like every tool here it cannot change topics or connectors that Strimzi’s operators own without those changes being reverted. It governs people working through Kpow, so applications keep their own KafkaUser credentials and ACLs. StreamsHub Console reads its connection straight from Strimzi’s resources and shows which topics the operators manage, Lenses has the stronger query model with SQL over topics, and Strimzi’s own resources need nothing new deployed at all.

Kpow live demo

See Kpow before it goes into your Kubernetes cluster

The live Kpow demo runs on two Amazon MSK clusters rather than Strimzi, and shows the same brokers, topics, consumer groups, Kafka Connect and schema registry views a team gets on Strimzi, with no signup. Switch the cluster picker to MSK Primary to see its Kafka Connect cluster.

For platform teams running Kafka with Strimzi.

Try the Kpow demo→

FAQ

What is the best Kafka UI for Strimzi?

On this page’s rubric, Kpow, with 90 of 100 points: it documents mTLS, SCRAM-SHA-512 and OAuth 2.0 against Strimzi listeners, installs from a Helm chart as one pod with no database, adds time-boxed production access, staged approvals, tenants and an audit log that names the person, and stays out of the data path. Kafbat UI is the highest-scoring free option, one point ahead of StreamsHub Console, the open-source console built for Strimzi-managed clusters.

Does Strimzi have a Kafka UI or console?

Strimzi’s own documentation describes no web UI for Kafka data. It manages Kafka through custom resources and kubectl, publishes example Prometheus configuration and Grafana dashboards, and offers Kafka Exporter for consumer group lag. The closest thing to a Strimzi console is StreamsHub Console, a separate Apache 2.0 project whose repository describes it as a web console for Kafka clusters managed by the Strimzi Cluster Operator; it browses topics and consumer groups, shows KafkaUser and KafkaRebalance resources and can pause reconciliation. Kpow, Kafbat UI and AKHQ connect to a Strimzi cluster as ordinary Kafka clients.

How does a Kafka UI connect to Strimzi over mTLS?

Create a KafkaUser with tls authentication, then mount the <cluster>-cluster-ca-cert Secret as the truststore and the KafkaUser’s Secret, which holds user.p12 and user.password, as the keystore. Kpow’s Strimzi documentation gives the exact settings, and AKHQ and Kafbat UI take the same values as ordinary Kafka client properties. StreamsHub Console instead names the KafkaUser in its Console resource and reads the credentials itself.

Which Kafka UI works with Strimzi’s OAuth 2.0?

Kpow documents OAuth 2.0 against Strimzi with Strimzi’s callback handler, in its -strimzi image, including an identity provider behind an internal CA. AKHQ bundles Strimzi’s OAuth client and documents a Keycloak example. Redpanda Console documents OAUTHBEARER for Kafka in general, without Strimzi-specific guidance; Kafbat UI and Lenses publish no OAUTHBEARER guide.

Will a Kafka UI conflict with Strimzi’s Topic Operator?

On topics that have a KafkaTopic resource, yes: Strimzi reverts configuration changes made outside the resource, whichever tool makes them. Topics without a KafkaTopic resource are left alone. The same applies to connectors when KafkaConnector resources are switched on. Teams use a UI such as Kpow to read data, watch consumer groups and reset offsets, and keep changes to operator-managed resources in Git.

Is there a free Kafka UI for Strimzi?

Kpow Community Edition is free on up to 3 clusters and 10 users and connects over mTLS or SCRAM-SHA-512 with standard Kafka client settings; Docker Hub lists the -strimzi build, which carries the OAuth libraries, for the Enterprise factorhouse/kpow image. Kafbat UI, AKHQ and StreamsHub Console are open source. RBAC, masking, staged approvals and the audit log need Kpow Enterprise. More free options are compared in the best free Kafka UI tools.

Can a Kafka UI manage Strimzi KafkaUser ACLs?

It can read them, and it can change ACLs for users the User Operator does not manage. Strimzi’s User Operator manages the ACLs, quotas and SCRAM credentials of every user it is not configured to ignore, so for those users the KafkaUser resource stays the place to change them. Kpow’s ACL management lists, clones, creates and deletes ACLs on the cluster, and StreamsHub Console shows each KafkaUser’s authentication type and ACLs.

How much memory does Kpow need on Kubernetes?

The Kpow Helm chart requests 2 CPUs and 8 GiB by default, with requests equal to limits for Guaranteed QoS, which is sized for an instance managing several clusters. For one Strimzi cluster the Helm documentation gives 1 CPU and 2 GiB as the suggested minimum. Kpow keeps its state in Kafka topics, so it needs no database.

Can Kpow use Keycloak on Strimzi?

Yes, in two places. Kpow’s Strimzi documentation has an OAuth 2.0 recipe for Keycloak running on Kubernetes behind a self-signed or Strimzi cluster CA, using the -strimzi image, and engineers can sign in to Kpow itself through Keycloak over SAML, so one identity provider covers both the brokers and the people.

Does a Kafka UI need to sit in the data path to govern access on Kubernetes?

No. Kpow runs as one pod, connects to the Strimzi listeners like any Kafka client and applies roles, masking, approvals and the audit trail to the people working through it, so producers and consumers keep connecting straight to the brokers. Conduktor Console also connects directly, while Conduktor’s data-level controls run in Gateway, a Kafka proxy that client applications connect through.

What happens to a Kafka UI when Strimzi renews its certificates?

Strimzi’s cluster CA and clients CA certificates are valid for 365 days by default and are renewed 30 days before they expire, and the User Operator regenerates user certificates when the clients CA is renewed. Strimzi’s documentation on certificate renewal for client applications states that its operators do not manage client applications, which must use the renewed credentials before the old ones expire. A UI that mounts the <cluster>-cluster-ca-cert Secret and its KafkaUser Secret as volumes receives the new files, unless they are mounted with subPath, and should be restarted after the renewal. A UI configured with copied certificates has to be given the new ones by hand.

Does a Kafka UI for Strimzi need access to the Kubernetes API?

Only if it reads Strimzi’s custom resources. StreamsHub Console does, and the ClusterRole in its install files lets it get, watch and list Strimzi resources, patch Kafka and KafkaRebalance resources and list pods. A UI that connects as a Kafka client reads everything through the listeners. Kpow’s Helm chart sets automountServiceAccountToken: false by default, so its pod holds no Kubernetes API token.

Does the Kubernetes audit log show who read a Kafka topic?

No. The Kubernetes API server’s audit log records requests to the Kubernetes API, and only when an audit policy is configured, so it can show who changed a KafkaTopic or KafkaUser resource. Reading records and resetting offsets are Kafka requests made by a client, which on a shared UI is the UI’s own KafkaUser. Kpow records each action, data inspect queries included, with the user from the identity provider.

How these tools were scored

Five of the six criteria start from Strimzi’s documentation or from what Kubernetes leaves open; the sixth is where the tool runs. They are listed here in order of weight. Each criterion is scored 0 to 10: 10 where a tool is the only one here doing it or clearly the best, 8 for a clean documented pass, 5 or 6 for partial support or support that needs work the reader must verify, 1 to 4 for a weak or indirect form, and 0 where it is absent.

1. Out of the data path (counts twice). The tool should run inside your own environment, reach the brokers over the same network your applications use as an ordinary Kafka client, and keep no data outside your own cluster. Scored lower: tools that need an external database of their own, and tools whose controls work only when application traffic passes through a vendor’s proxy. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with several databases or a component on the brokers 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all, here Strimzi’s own resources. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.

2. mTLS, SCRAM and OAuth on Strimzi (counts twice). Strimzi listeners authenticate clients with mTLS, SCRAM-SHA-512 or OAuth 2.0, and Strimzi keeps the certificates and passwords in Kubernetes Secrets. A tool scores well here when it documents all three against Strimzi, including how to reach an identity provider behind an internal CA, and 10 when it takes its connection straight from Strimzi’s own resources. It scores 7 when it documents all three mechanisms for Kafka in general but nothing for Strimzi, or when it takes any Apache Kafka Java client property and Factor House’s review of it records it connected to Strimzi, and 6 when it documents two of the three.

3. Production access on request (counts twice). Kubernetes RBAC controls the custom resources, not who may read production data or act on a consumer group. This criterion scores time-boxed grants, approval steps before destructive actions and masking of sensitive fields, and uses the same scores as the banking page for every tool scored there. Redpanda Console uses the score from the self-managed Apache Kafka page.

4. Audit trail per person (counts twice). The Kubernetes API audit log can show who changed a custom resource, but not who read a topic or reset an offset through a tool. This criterion scores an audit trail that names the person from the directory, covers reads as well as changes, and can be read without building a consumer first. Scores match the banking page for every tool scored there.

5. Many teams, shared clusters (counts once). A Strimzi cluster is often shared by several application teams. This criterion scores whether a tool can scope what each team sees, not only what it may do. Scores match the banking page for every tool scored there. The masking options are compared in Kafka data masking tools.

6. Runs on Kubernetes (counts once). A tool for a Strimzi team should install from a maintained Helm chart, run as one pod, take its credentials from Secrets and need nothing else in the cluster. Most tools here pass; tools with recorded Kubernetes problems or a database of their own score lower, problems recorded only when a tool runs beside another vendor’s operator do not count, and Strimzi’s own resources score 10.

Costs are modelled for one production Strimzi cluster and 25 engineers at $120 per engineer hour, using the same hours per tool class as Factor House’s other comparison pages. Tools with a licence carry the published price plus 2 hours a month to run. The open-source UIs, Kafbat UI, AKHQ, StreamsHub Console and Redpanda Console’s free build, carry 6 hours a month, $8,640 a year, to run, secure and keep current. Lenses’ Team licence stops at 15 users on one cluster, so Lenses is priced at its smallest AWS Marketplace listing, $2.055 an hour on t2.large before the EC2 charge; a team running it outside AWS gets a quoted licence instead. Strimzi’s own resources have no licence and nothing new to run, and the Kafka CLI they leave record reading to is modelled like the other tools with no access control of their own, at 8 hours a month, $11,520 a year. Kpow’s $7,380 uses the price of $4,500 per cluster a year with 100 users included. Kpow Community Edition is free for 3 clusters and 10 users, so a 25-engineer team is on Enterprise. For free options compared at any team size, see the best free Kafka UI tools.

The criteria map onto the Strimzi features in the figure below.

F1 From Strimzi feature to what a Kafka tool has to do

What Strimzi does What the tool has to do

Listener authentication Listeners authenticate clients with mTLS, SCRAM-SHA-512 or OAuth 2.0 Sign in the way the listener is configured, including with a token from your identity provider

Certificates and users in Secrets The Cluster CA public key sits in the <cluster>-cluster-ca-cert Secret, and the User Operator writes each KafkaUser's keystore or password to a Secret Mount those Secrets into its pod rather than keeping its own copies of the credentials

KafkaTopic resources Configuration changes made outside a KafkaTopic resource are reverted; topics without one are left alone Let people act on unmanaged topics, and leave operator-managed ones to the resource in Git

KafkaConnector resources With strimzi.io/use-connector-resources set, changes through the Connect REST API are reverted Read connector and task state through REST either way, and change connectors there only where those resources are off

Kubernetes RBAC Decides who may change the custom resources, not who may read a record or reset a consumer group Add per-person roles, production access on request, masking and an audit trail for the people using the tool

Where the tool runs Brokers run as pods, and producers and consumers connect to their listeners directly Run as one more pod and connect as an ordinary Kafka client, not as a proxy that applications route through

Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Out of the data path counts twice, mTLS, SCRAM and OAuth on Strimzi counts twice, Production access on request counts twice, Audit trail per person counts twice, Many teams, shared clusters counts once and Runs on Kubernetes counts once, for a total out of 100. Out of the data path, sign-in, production access and the per-person audit trail count twice. A team that chose Strimzi runs its own Kafka in its own Kubernetes cluster, and a tool that applications connect through, or that brings a database of its own, is one more stateful component inside that cluster to size, secure and keep available. A tool that cannot sign in over the listener's mTLS, SCRAM or OAuth configuration cannot be used at all. Kubernetes RBAC decides who may change a custom resource, not who may read a record in production or who reset a consumer group, so production access granted on request and an audit trail that names the person are the controls the platform does not already give. Shared clusters and Kubernetes fit count once, because most tools here install cleanly from a Helm chart or an operator, and per-team views add less than the per-person controls above. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 90 out of 100. The other options follow by total. Conduktor is listed last whatever its total; on its total of 62 it would place third.

Related reading

• Kafka: the complete guide
• Best Kafka UI tools for Amazon MSK
• Best Kafka management tools for banks
• Best Kafka governance tools for financial services
• How Claritev cut Kafka support costs with Kpow
• Best tools to manage Kafka topics at scale