Best Kafka UI tools for Red Hat AMQ Streams (Streams for Apache Kafka on OpenShift)

Tools compared

Rank	Tool	Total (out of 100)	Out of the data path	mTLS, SCRAM and OAuth sign-in	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 listeners; OAuth needs the -strimzi image	Temporary policies, staged approvals, masking	Names the person, includes data reads	Tenants per team	Helm chart, one pod; UBI image tag	$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	Streams for Apache Kafka Console	62	Console and operator, no database	Reads the listener and KafkaUser from the Kafka resource	OIDC roles, no approvals or masking	None documented	Roles per cluster and resource	Operator and a Console resource	$2,880 beyond the subscription
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	AMQ Streams resources with oc and Grafana	58	Nothing new to deploy	Defines users; reads no records	OpenShift RBAC on resources	API server audit, no data reads	Projects and ACLs	OpenShift 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 AMQ Streams	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 Red Hat AMQ Streams

What teams on Red Hat AMQ Streams (Streams for Apache Kafka on OpenShift) need

Red Hat AMQ Streams is Red Hat’s supported distribution of Strimzi for OpenShift. Red Hat describes it as the component that makes Apache Kafka OpenShift native through operators, and has since renamed it Red Hat Streams for Apache Kafka; Kpow’s own Docker Hub page lists it as Red Hat Streams for Apache Kafka (formerly AMQ Streams). A team declares the cluster, its topics, its users and its Kafka Connect clusters as custom resources, and the operators make the brokers match. That gives a platform team GitOps for the cluster and a Red Hat support contract behind it. It does not decide who may read the records in a topic, and OpenShift 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 AMQ Streams. The upstream project is scored on the best Kafka UI tools for Strimzi (Kafka on Kubernetes) page, Kafka run without an operator on the best Kafka tools for self-managed Apache Kafka page, and Confluent’s operator on the best Kafka management tools for Confluent Platform page.

Out of the data path. Where a tool runs decides whether it adds anything to the path producers and consumers take. A tool that runs as one more pod and connects to the brokers the way any Kafka client does adds nothing to it. 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 inside the OpenShift cluster the operators keep reconciling. Kpow is one container with no external database, installed in your own environment and out of the data path. 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.

Red Hat’s own product draws the same line. Streams for Apache Kafka includes a proxy, and Red Hat’s guide to deploying Streams for Apache Kafka Proxy on OpenShift describes a Kafka protocol-aware proxy that sits between clients and the cluster and exposes a virtual cluster that clients connect to; its Record Encryption filter is where record values are encrypted at rest. The proxy is built on Kroxylicious, which describes itself as a stand-alone component deployed between applications and the cluster, with applications connecting to it instead of to the brokers, and which publishes its own overhead: about 0.2 ms of added average publish latency as a passthrough with no filters, and with record encryption about a 26 percent throughput reduction per partition and 15 to 40 ms of added p99 latency below saturation. Those figures are the cost of putting a control in the data path, measured by the project that makes the proxy. Red Hat’s architecture keeps that component separate from the console its customers use to look at the cluster, and a Kafka UI fits the same split. With record encryption on, a tool that connects to the brokers directly reads values as they are stored, encrypted, and one that should show them decrypted connects through the proxy like any other client.

mTLS, SCRAM and OAuth on AMQ Streams. The 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 keystore, or its SCRAM password, to a Secret of its own, as Strimzi’s deployment documentation describes. A tool on OpenShift should mount those Secrets rather than hold copies, and for OAuth a Java tool needs Strimzi’s OAuth client library or an equivalent. Kpow publishes a Strimzi guide for all three mechanisms and a build that bundles the OAuth library, and AKHQ bundles the same library. Red Hat’s console takes the listener and the KafkaUser from the Kafka resource. Redpanda Console documents the three mechanisms for Kafka in general, while Kafbat UI and Lenses document SSL and SCRAM but not OAuth.

OAuth on AMQ Streams usually means Red Hat build of Keycloak, and it often decides more than sign-in. The Streams for Apache Kafka 3.1 release notes describe OAuth 2.0 token-based authorization through Red Hat build of Keycloak Authorization Services, which moves Kafka permissions out of ACLs and into Keycloak. That authorization is decided for the principal that connects, and a shared tool connects as one client, so Keycloak sees one identity however many engineers are behind it. The per-person layer then has to sit in the tool, which can sign people in through the same Keycloak: Kpow takes people’s sign-in from Keycloak over SAML and applies its own roles to each of them.

Where the tool runs also decides how it reaches the brokers. Inside OpenShift it uses the internal listener and its bootstrap service, and nothing new is exposed. Outside OpenShift, for example a single Kpow instance that also manages clusters elsewhere, it uses an external listener, and on OpenShift that is usually a route listener. Strimzi’s documentation on accessing Kafka using OpenShift routes explains that it creates a route and a service for the bootstrap and for each broker, that the port is always 443, and that routes use TLS passthrough with SNI, so TLS is always on and the brokers present certificates from the internal cluster CA, not the router’s. A tool connecting through routes therefore needs the cluster CA in its truststore and the route bootstrap address on port 443, the same as any external client.

Working with the operators. The Topic Operator reverts configuration changes made outside a KafkaTopic resource for any topic that has one, and leaves topics without one alone. With KafkaConnector resources switched on for a Kafka Connect cluster, changes made through the Connect REST API are reverted too, and the User Operator manages the ACLs and credentials of the users it owns. On AMQ Streams a Kafka UI is mostly where engineers read data, watch consumer groups, reset offsets and act on resources that no custom resource owns, while changes to operator-managed topics and connectors stay in Git. Every tool on this page is in the same position. The best tools to manage Kafka topics at scale and best tools to manage Kafka ACLs pages score the operators against the other ways of doing this.

The Kafka version also comes from the operator. The 3.1 release notes state that from Kafka 4.0 ZooKeeper is no longer supported and clusters run in KRaft mode, and that Streams for Apache Kafka 2.9, a long-term support release, is the last version compatible with ZooKeeper-based clusters. The 3.2 release notes put 3.2 on Apache Kafka 4.2 and Strimzi 0.51 as a long-term support release, tested on OpenShift 4.16 to 4.21 except 4.17. A team upgrading off 2.9 moves to KRaft, and a UI that still reads cluster metadata from ZooKeeper loses its connection in the move; tools that use only the Kafka Admin API, Kpow among them, carry on.

Production access on request. 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. The alternative is handing out credentials. On AMQ Streams the credential that reads a topic is a Secret in the Kafka cluster’s project, and the KafkaUser’s ACLs that it carries have no end date, so giving an engineer the console consumer and a KafkaUser of their own means a Git change to grant access and another to remove it. Red Hat’s console improves on that with OIDC sign-in and roles that grant GET, LIST or UPDATE per cluster and resource type, but its guide describes no expiry, approval step or masking, so a role granted for an incident stays until someone edits the Console resource. Kpow’s temporary policies end at a set time.

Audit trail per person. OpenShift records requests to its API server, which 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 that never reach the Kubernetes API server’s audit log. 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. OpenShift projects separate applications, but a Kafka cluster is one set of topics shared by every team that uses it, and the operators keep the KafkaTopic and KafkaUser resources for that cluster in the namespaces they watch rather than in each team’s project. 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.

Runs on Kubernetes and OpenShift. OpenShift adds a check that plain Kubernetes does not. Its restricted security context constraint, the default for most workloads, requires that a pod run as a user in a pre-allocated range of UIDs assigned to its project, and a pod that asks for a fixed user ID outside that range is not admitted; the nonroot SCC allows any non-root UID instead. A tool built for Kubernetes often sets a fixed user ID, and the Kpow chart’s defaults set runAsUser: 1001, so on OpenShift the team either clears that value and lets the SCC assign the user, or grants the tool’s service account nonroot. The base image is the other check. Many OpenShift shops admit only images built on Red Hat’s Universal Base Image, and Kpow publishes a -rh-ubi tag with each release built on UBI 9 with OpenJDK 25. Red Hat’s console avoids both questions because it ships with the product and installs through its own operator.

Who runs Kpow on Red Hat AMQ Streams (Streams for Apache Kafka on OpenShift)

One Kpow customer has a public record of running Kafka on Red Hat AMQ Streams: Transpower, which owns and operates New Zealand’s national grid and runs the wholesale electricity market. The evidence is Red Hat’s own case study, which describes AMQ Streams on OpenShift providing the streaming data behind Transpower’s real-time electricity pricing; it does not mention Kpow, so the card below is public context about Transpower’s Kafka rather than a description of how it uses Kpow. The best Kafka management tools for energy and utility companies page covers the rest of that sector.

How a team runs Red Hat AMQ Streams (Streams for Apache Kafka on OpenShift) 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 a project on the same OpenShift cluster as the brokers or any cluster that can reach a listener. Where the cluster admits only UBI images it sets the image tag to the -rh-ubi build, for example factorhouse/kpow:96.5-rh-ubi; for OAuth through Strimzi’s callback handler it uses the -strimzi build instead. On OpenShift the values file also clears the chart’s fixed user ID so that the restricted SCC can assign one, and enables the chart’s ephemeralTmp volume so the container has a writable temporary directory. The chart’s values, published in the helm-charts repository, take volumes, volumeMounts and envFromSecret, which is how the cluster CA, the KafkaUser’s Secret and the licence reach the pod. Kpow is designed to run as a single instance, and teams that want a standby use the active/passive model in the deployment notes.

A values file for OpenShift and 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-rh-ubi"           # UBI 9 base; use 96.5-strimzi for OAuth 2.0
securityContext:
  runAsUser: null              # let the restricted SCC assign the UID
ephemeralTmp:
  enabled: true                # writable /opt/factorhouse/tmp
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

Factor House does not publish an OpenShift guide, so a team should check this file against its own SCC policy before production; the alternative to clearing runAsUser is granting the Kpow service account the nonroot SCC with oc adm policy add-scc-to-user nonroot -z <service-account>.

Signing in to the cluster. The team creates a KafkaUser for Kpow with the ACLs listed in Kpow’s minimum ACL permissions, including those for the internal topics Kpow creates on its first cluster, 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. 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 recipe for Keycloak behind an internal CA. A Kpow instance outside OpenShift connects through the route listener on port 443 with the same truststore.

Signing people in. Engineers sign in to Kpow through SAML, including Okta, Microsoft Entra ID and Keycloak, 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 an AMQ Streams 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. Red Hat’s release notes point Streams for Apache Kafka teams to Red Hat build of Apicurio Registry as the central store for schemas, and 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 the 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 the broker metrics in OpenShift’s monitoring stack.

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 OpenShift API audit log does not see: who read which topic and who reset which consumer group.

Running AMQ Streams 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 an AMQ Streams cluster beside the others a team runs, under the same roles and audit trail; the best Kafka UI tools for Amazon MSK page covers the MSK side.

Kpow is not the strongest option on every point: Red Hat’s console ships with the product, connects straight from the Kafka resource and needs no SCC or base-image decisions, and Lenses has the stronger query model with SQL over topics. Kpow has no OpenShift operator or install guide, OAuth needs its separate -strimzi image, and like every tool here it cannot change topics or connectors the operators own without those changes being reverted. It governs people working through Kpow, so applications keep their own KafkaUser credentials, ACLs or Keycloak permissions.

Kpow live demo

See Kpow before it goes into your OpenShift cluster

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

For platform teams running Kafka with Red Hat AMQ Streams.

Try the Kpow demo→

FAQ

What is the best Kafka UI for Red Hat AMQ Streams?

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 Red Hat’s Streams for Apache Kafka Console.

Does Red Hat AMQ Streams have a console?

Yes. Red Hat ships the Streams for Apache Kafka Console with the product, version 0.12 in release 3.2, installed through its own operator. It shows brokers, topics and messages, consumer groups with offset resets, KafkaRebalance resources and Kafka Connect, and signs people in through an OIDC provider with roles per cluster and resource. Red Hat’s guide to it describes no audit trail, masking or approval step.

Is AMQ Streams the same as Streams for Apache Kafka?

Yes. Red Hat renamed AMQ Streams to Red Hat Streams for Apache Kafka, and older documentation and case studies use the earlier name. Both are Red Hat’s supported distribution of Strimzi on OpenShift, so tools that document Strimzi listeners and resources apply to it.

Does Kpow run on OpenShift?

Kpow runs on OpenShift from its Helm chart, and its documentation lists Red Hat AMQ Streams among the distributions it has been tested with. Factor House publishes a -rh-ubi image tag built on Red Hat’s Universal Base Image with each release. There is no OpenShift operator or OpenShift install guide, so a team clears the chart’s fixed runAsUser for the restricted SCC or grants the service account the nonroot SCC.

How does a Kafka UI connect to AMQ Streams 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. From outside OpenShift, connect to the route listener’s bootstrap address on port 443.

Which Kafka UI works with OAuth 2.0 and Red Hat build of Keycloak on AMQ Streams?

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

Will a Kafka UI conflict with the AMQ Streams Topic Operator?

On topics that have a KafkaTopic resource, yes: the operator reverts configuration changes made outside the resource, whichever tool makes them. Topics without a KafkaTopic resource are left alone, and 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.

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

No. Kpow runs as one pod, connects to the 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. Red Hat’s own data-level control, record encryption, runs in Streams for Apache Kafka Proxy, which applications connect through, and Conduktor’s data-level controls run in Gateway, a Kafka proxy, while Conduktor Console connects directly.

Is there a free Kafka UI for AMQ Streams?

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. Kafbat UI and AKHQ are open source, and Red Hat’s console comes with the Streams for Apache Kafka subscription. RBAC, masking, staged approvals and the audit log need Kpow Enterprise. More free options are compared in the best free Kafka UI tools.

How these tools were scored

Five of the six criteria start from AMQ Streams and Strimzi documentation or from what OpenShift 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. AMQ Streams runs Strimzi’s listeners and resources, so every tool scored on the Strimzi page keeps its scores here; Red Hat’s console and the oc option take the scores of their Strimzi counterparts on the same kind of evidence.

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 the AMQ Streams resources themselves. 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 sign-in (counts twice). AMQ Streams listeners authenticate clients with mTLS, SCRAM-SHA-512 or OAuth 2.0, and the operators keep the certificates and passwords in Secrets. A tool scores well here when it documents all three against Strimzi listeners, including how to reach an identity provider behind an internal CA, and 10 when it takes its connection straight from the Kafka resource. 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). OpenShift 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 API server’s 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). An AMQ Streams 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 an AMQ Streams team should install from a maintained Helm chart or operator, 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 the AMQ Streams resources score 10. The OpenShift-specific steps, the restricted SCC and base-image policy, are described above for each tool where its documentation covers them and do not move a score, because no tool other than Red Hat’s console documents them.

Costs are modelled for one production AMQ Streams cluster and 25 engineers at $120 per engineer hour, using the same hours per tool class as Factor House’s other comparison pages, and none includes the Red Hat subscription for AMQ Streams itself. Tools with a licence carry the published price plus 2 hours a month to run, and Red Hat’s console, supported under the subscription the team already pays, carries the same 2 hours, $2,880 a year. The open-source UIs, Kafbat UI, AKHQ 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. The AMQ Streams 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 AMQ Streams features in the figure below.

F1 From AMQ Streams feature to what a Kafka tool has to do

What AMQ Streams does What the tool has to do

Listener authentication Listeners authenticate clients with mTLS, SCRAM-SHA-512 or OAuth 2.0, often against Red Hat build of Keycloak Sign in the way the listener is configured, including with a token from the identity provider

Route listeners An external route listener creates one OpenShift route per broker, on port 443 with TLS passthrough Use the internal listener when it runs inside OpenShift, or trust the cluster CA and use TLS when it connects through the routes

Security context constraints The restricted SCC runs each pod as a user from a UID range allocated to its project Run as a non-root user without needing a fixed UID, or document the SCC it needs

KafkaTopic and KafkaConnector resources The operators revert changes made outside a resource that owns the topic or connector Let people act on unmanaged topics, and leave operator-managed ones to the resource in Git

OpenShift 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 Applications connect to the brokers directly, or through Streams for Apache Kafka Proxy where record encryption is on 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 sign-in 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 on AMQ Streams runs its own Kafka in its own OpenShift 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. OpenShift 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 fit with Kubernetes and OpenShift 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 Strimzi (Kafka on Kubernetes)
• Best Kafka tools for self-managed Apache Kafka
• Best Kafka management tools for Confluent Platform
• Best Kafka UI tools for Amazon MSK
• Best Kafka management tools for energy and utility companies
• Best tools for Kafka SSO integration