Best Kafka UI tools for Google Cloud Managed Service for Apache Kafka

Tools compared

Rank	Tool	Total (out of 100)	Governance beyond IAM	Out of the data path	Google IAM sign-in	On-prem and cloud together	Registry and Managed Connect	Inspecting topic data	Cost a year, one cluster (modelled)
1	Kpow	84	RBAC, staged approvals, temporary access, masking, tenants, audit	One container, no external database, not a proxy	OAUTHBEARER and PLAIN documented; separate Google build	One deployment across environments	Google registry yes; Managed Connect not yet	kJQ search, data inspect, replay	$7,380
2	Kafbat UI	65	RBAC, global masking, opt-in audit	One container	OAUTHBEARER, library built in; guide mounts a key file	Many clusters, per-cluster settings	Neither documented	Message browsing	$8,640
3	Google Cloud console and Cloud Monitoring	61	Per-user IAM roles, Cloud Audit Logs, time-limited grants	Nothing to deploy	Your Google identity	Google clusters only	Both managed in the console	Topic configuration, no records	$11,520
4	Lenses	57	SSO and RBAC from Team tier, audit	HQ on PostgreSQL plus an agent per cluster	Supported per its forum; no Google guide	One HQ, agent per cluster	Neither documented	SQL over topics	$2,880 plus a quoted licence
5	AKHQ	57	Group roles, no masking	One container	Not documented; library not bundled	Many clusters from one file	Neither documented	Message browsing	$8,640
6	Redpanda Console	55	Behind a paid Enterprise licence	One container	Not documented	One cluster per deployment	Neither documented	Message browsing	$8,640 plus an unpublished licence for RBAC
7	Conduktor	62	Strong; data-level controls through Gateway	Console on PostgreSQL; Gateway, a proxy, for data-level controls	SASL/PLAIN with a key or token	Many providers and on-prem	Neither documented	Message browsing	$32,880; $122,880 with Gateway Core and Protect

The tools, ranked for Google Cloud Managed Kafka

What teams on Google Cloud Managed Service for Apache Kafka need

Google Cloud Managed Service for Apache Kafka runs the brokers for you. It does not give engineers a way to read the records in a topic, and once several teams share a cluster it leaves the question of who may do what to IAM roles and Kafka ACLs written per principal. Google called the service Apache Kafka for BigQuery until it was renamed in August 2024, so older guides and forum answers use that name. Everything on this page is about what a tool adds on top of the service, not about replacing it.

Three things come up once a team is running the service in production. The tool has to sign in the way the cluster expects without a long-lived key in its configuration. It has to work with the services Google runs around the cluster, the managed schema registry and Managed Kafka Connect, because otherwise engineers see undecoded bytes and connectors they cannot reach. And it has to answer the governance questions IAM leaves open, because IAM authorises the principal that connects, and when twenty engineers share one tool that principal is the tool’s service account.

Google IAM sign-in. Google documents three ways to authenticate to the brokers. OAUTHBEARER is the one it recommends inside Google Cloud: a Java client adds Google’s Kafka auth library and its GcpLoginCallbackHandler, which takes short-lived tokens from Application Default Credentials, so the tool runs as the service account attached to its VM or pod. Every connection needs the Managed Kafka Client role on the project. SASL/PLAIN takes a service account email and a base64-encoded key, or an access token, as username and password, which Google describes as useful for early development and, for a key file used from outside Google Cloud, generally discouraged for production workloads. Mutual TLS, on port 9192 for clusters created after 24 June 2025, derives the principal from the certificate, and those principals are authorised by Kafka ACLs only. Kpow and Kafbat UI document OAUTHBEARER with Google’s library, Kafbat UI with a mounted service account key file; Conduktor documents SASL/PLAIN; Lenses has said it supports the service without publishing Google-specific setup; AKHQ and Redpanda Console publish no Google-specific guidance.

Which of those routes a tool documents decides whether it can be deployed at all in a newer Google Cloud organisation. Google’s security baseline enforces a constraint that disables service account key creation on every organisation created on or after 3 May 2024, and Google’s SASL guide warns that a reader who cannot create a service account key may find key creation disabled for the organisation. In those organisations the key-file routes, SASL/PLAIN with an encoded key or a mounted JSON key file, need a security administrator to relax an organisation policy before the tool can connect. The other SASL/PLAIN route, an access token as the password, avoids the key, but Google cautions that access tokens are short-lived and that the client has to present a valid token each time it opens a new Kafka connection, which a long-running tool configured with a pasted token cannot do once that token has expired.

Google IAM sign-in is also something a tool has to implement for Google specifically. Amazon MSK’s IAM authentication and Google’s are both delivered as SASL OAUTHBEARER login handlers, but they are different libraries that produce different tokens, so support for one does not carry over to the other. The data processing project Feldera recorded this in an issue on its Kafka connector in August 2026: its OAUTHBEARER path supported only Amazon MSK, so a pod on GKE with valid Google credentials could not authenticate to Google’s managed Kafka until a Google token path was added. For a Java tool the work is adding Google’s library to the classpath. For a tool that is not written in Java, Google’s documented route is a local authentication server run beside the client, and a Google Developer forums thread that began in June 2025 shows engineers working in Go, Node.js and Python unable to get OAUTHBEARER accepted, the first of them reporting that only SASL/PLAIN with an access token worked. Redpanda Console is written in Go, so the local authentication server is the route open to it, and Redpanda’s documentation does not cover that setup.

On GKE the identity a tool runs as comes from Workload Identity Federation for GKE, and Google’s SASL guide attaches two conditions to using it with managed Kafka: the cluster has to run GKE version 1.31.1-gke.1241000 or later, and the Kubernetes service account needs the annotation iam.gke.io/return-principal-id-as-email: "true". Fleet workload identity is not supported for the Kafka API, and the alternative Google gives is to link the Kubernetes service account to an IAM service account. These are properties of the pod and its service account, not of any one tool, so they apply to every UI installed from a Helm chart, and they are the first things to check when a tool on GKE is refused at sign-in.

Kpow’s separate Google build comes from how the registry client loads its authentication. As the open issue on Google’s auth library sets out, Confluent’s schema registry client instantiates every bearer token provider it finds on the classpath, and Google’s GcpBearerAuthCredentialProvider creates Google credentials in its constructor, so a general image that carried it would fail for any team with no Google credentials in its environment. Google support therefore ships as its own build, published with every Kpow release since 95.1.

Registry and Managed Connect. The managed schema registry, still in Preview when read on 1 October 2026, implements the Confluent Schema Registry REST API for Avro and Protobuf; it does not support JSON schemas. It accepts Google bearer tokens rather than a username and password, so a tool needs Google’s GcpBearerAuthCredentialProvider or an equivalent to reach it. Kpow is the only third-party tool here that documents that connection. Managed Kafka Connect became generally available on 1 October 2025 and is run through the console, gcloud, Terraform and the Managed Kafka API, without the Kafka Connect REST endpoint that UI tools use, so none of the third-party tools on this page manages it, Kpow included.

Supporting a schema registry has two parts: the serializers and deserializers that read and write records, and the API that manages subjects and versions. Because Google’s registry implements the Confluent Schema Registry REST API, the standard Confluent serializers work against it, and what differs is authentication. Compatibility does not extend to the whole API, because Google’s list of unsupported features includes the JSON schema format, the ListSchemas method at /schemas, the deletedOnly parameter when listing subjects and versions, the READONLY_OVERRIDE mode and the normalize and alias configuration values. A UI written against Confluent’s registry that depends on any of those, such as a view that asks only for soft-deleted subjects, behaves differently on Google’s, so registry support has to be tested against Google’s registry and cannot be assumed from the shared API. JSON topics on a Google cluster have no registered schema at all and are inspected as plain JSON.

Managed Kafka Connect differs from self-managed Kafka Connect in what it will run as well as in how it is reached. Google’s connector list has seven built-in types: the BigQuery, Cloud Storage and Pub/Sub sinks, the Pub/Sub source, MirrorMaker 2.0 and two PostgreSQL sources built on Debezium. Its Kafka Connect overview states that custom connector plugins cannot be uploaded. A team that needs any other connector, a JDBC sink or a MySQL source for instance, runs its own Kafka Connect workers on GKE or Compute Engine beside the managed ones, and those workers expose the Connect REST API that Kpow and the open-source UIs manage. A mix of the two is therefore the likely state on Google Cloud, with managed connectors in the Google Cloud console and the rest in the team’s own tool.

Managed connectors also fail differently from what a team used to the Connect REST API expects. Google’s default task restart policy is to never restart a failed task; restart with exponential backoff, with a minimum above 60 seconds and a maximum below 7,200, is the policy it recommends for most production workloads. The connector page in the console reports one state for the connector and charts task error count and active task count, so a connector left on the default policy keeps its failed task until someone reads the chart or an alert on that metric fires.

Governance beyond IAM. Google Cloud already governs engineers who work in the console or gcloud under their own identities. IAM roles are granted per user or group, Cloud Audit Logs record each administrative action, such as a topic deletion or a consumer group update, under the identity that made it, and Privileged Access Manager can grant a role for a limited time after approval. None of that reaches inside the Kafka protocol once a shared tool connects: the brokers see the tool’s own service account, so reads, offset resets and produced records made through the tool are attributed to the tool, record contents are never masked, and nothing records which engineer looked at which message. Those are what a shared tool has to add once more than one team works on the same cluster, and many teams on Google Cloud also run Kafka somewhere else, on-prem or on another cloud, and want the same controls on every cluster. The audit layers are compared in Kafka audit logging tools.

The IAM check on a Kafka client is narrower than the role names suggest. Google’s Kafka ACL documentation says that standard Apache Kafka clients are only subject to a cluster-level IAM check for the initial connection, the managedkafka.clusters.connect permission, and that clusters run with allow.everyone.if.no.acl.found set to true, so every authenticated principal has access to any topic or consumer group that has no ACL of its own. IAM Conditions can narrow a role to one cluster or topic for calls to the Managed Kafka API, which the console and gcloud use, while access inside the cluster over the Kafka protocol is decided by Kafka ACLs; Google’s own example of stopping a principal from editing topics needs a denied API permission and a Kafka ACL together. A shared tool connects over the Kafka protocol, so on a cluster with no ACLs its service account can read, alter and delete everything, and a tool with no roles of its own passes that access to each person who opens it, the opposite of the least privilege a security review asks for.

Kafka ACLs on Google also cannot be granted to a team, because Google states that an ACL principal must be a user, a service account or an individual IAM principal, not a group or principal set, and that Kafka ACLs do not resolve group memberships for Google Cloud principals. The workaround it documents is a proxy service account that holds the ACLs and that members of a Google group are allowed to impersonate. A shared tool is the same arrangement in practice, one service account holding Kafka permissions on behalf of many people, so the roles inside the tool, taken from the identity provider, are where one engineer is limited to reading two topics while another may reset offsets. ACL bindings on Google cannot be restricted by host either, because the service translates client network addresses and supports only *.

Cloud Audit Logs follow the same split between the two APIs. The audited methods Google lists are calls to the Managed Kafka API, the schema registry API and the Connect API, plus one entry for the Kafka protocol, AuthenticateConnection, written when a client authenticates. That entry is a Data Access log, and Google’s logging documentation says Data Access audit logs are disabled by default for all services except some in BigQuery, so it exists only once a team has switched it on. A topic deleted in the console is recorded under the engineer’s identity, while an offset reset or a search across a topic made through a tool over the Kafka protocol appears in Cloud Audit Logs, at most, as that tool’s service account connecting.

Privileged Access Manager is limited in the same way, because an entitlement grants IAM roles, optionally with IAM conditions, to the principal that requests them for a maximum duration. For a Kafka client the only IAM permission is the connection, so a grant can time-box who may connect or who may use the console, and it cannot express inspect access to one topic for one hour through a shared tool, whose service account holds its role permanently.

The masking that Google’s documentation describes applies to data moving through Kafka Connect, where its connectors overview suggests a transformation to mask sensitive data as it moves between a topic and an external system, which changes what a sink such as BigQuery receives. Nothing in the service masks a field for an engineer reading the topic itself, so that has to happen in the tool that shows the record.

Out of the data path. One requirement cuts across all of these: where the tool runs. A tool that runs as a container in your own VPC, next to the cluster, and connects the way any Kafka client does, adds nothing to the path your 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. Kpow is one container with no external database, installed in your own environment and out of the data path. Conduktor Console also connects 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.

On a managed service a proxy is also the one component in the path that Google does not run. Google provisions, patches and replaces the brokers and adds brokers automatically as a cluster is scaled up, while a Kafka proxy in front of them is deployed, sized and kept available by the customer. Kai Waehner’s review of Kafka proxies lists the costs as an extra network hop, a high-availability requirement and operational overhead, set against what a proxy can enforce for every client without application changes.

Where a tool can run is settled largely by Google’s networking. The service deploys clusters in a tenant project, in a private VPC that is not reachable through public IP addresses, and exposes them through Private Service Connect endpoints in the subnets a team connects, so a self-hosted tool in a connected subnet reaches the brokers at the same bootstrap address as the applications. A console hosted outside that network needs the cluster made public. Google lets a cluster be made public with allowed source IP ranges, and the same documentation notes that security administrators can prohibit public clusters with the constraints/managedkafka.managed.restrictPublicClusters organisation policy constraint, in which case only a tool inside a connected network can reach the cluster.

Google’s limitations also rule out one common way of monitoring a cluster, because JMX APIs for metrics are not supported. A tool that reads broker JMX has nothing to read on this service, so its broker and topic figures have to come from Cloud Monitoring or be computed from the Kafka API. Kpow has no dependency on JMX, because it snapshots the cluster through the Kafka Admin API every minute, computes its metrics from those snapshots and keeps its snapshots, metrics and audit log in internal topics on the cluster, which its system requirements put at up to 10 GB of replicated disk at the default one-week retention. Keeping no database has a cost of its own on Google Cloud: those topics are billed as cluster storage, and Google’s pricing charges for data moved between a client and a broker in a different zone and not within a zone, so the records a tool reads are billed like any other consumer’s.

On-prem and cloud together. A team on Google Cloud usually has more than one cluster to manage even before another provider is counted. Google’s overview says that a cluster is regional, that the service does not protect against a regional or dual-zone failure, and that applications needing that protection should run two separate regional clusters kept in step with MirrorMaker 2.0. With development, staging and production added, several clusters is the starting point, and a tool that covers one cluster for each install breaks the audit trail at every cluster boundary.

The sign-in method decides how portable the client configuration is. Google describes SASL as inherently tied to IAM principals and mutual TLS as the provider-agnostic option, suited to on-premises, multi-cloud and existing PKI setups. Mutual TLS carries its own conditions on Google: client certificates have to chain to a CA pool in Google’s Certificate Authority Service, a cluster trusts at most 10 CA pools, and mTLS principals are authorised by Kafka ACLs only. A team that standardises on certificates so that the same clients work on-premises and on Google therefore manages every permission as a Kafka ACL, which makes ACL management in the tool part of daily work.

Kpow’s provider documentation covers Google Cloud’s managed Kafka beside self-managed Kafka, Amazon MSK, Confluent and other distributions, and one instance manages up to 12 clusters with the same roles, masking and audit log. Google clusters need the Google build, so a team that mixes Google with other clouds in one instance should test that configuration. The options for many clusters are compared in Kafka multi-cluster management tools. Teams arriving from a bundled platform should expect one gap, because Google’s service runs open-source Apache Kafka and adds no view of topic data, and the Migrating to open source Kafka session reports that what such teams miss is the UI and the view of their data, since not every user is comfortable on the command line.

Inspecting topic data. The absence of a record view in the Google Cloud console matches how the console reaches the cluster. It works through the Managed Kafka API, which acts inside the cluster as Google’s service agent, and Google’s Kafka ACL documentation says that agent is given permissions similar to a super user’s except for read and write operations. Reading a record is left to a Kafka client, and the route Google’s own quickstart takes is a client VM in the cluster’s region and VPC, an SSH session to that VM, and the Kafka command-line tools running as the VM’s service account. Everyone who can open that SSH session acts as the same service account, on a cluster with no ACLs that account can read every topic, and Cloud Audit Logs record the connection and not the topics read.

Google’s other route to topic data is a BigQuery sink connector, which streams a topic into a table and suits questions about data already collected. Finding one message by key during an incident, checking whether a record a team reports as missing is on the topic, and replaying a dead-lettered record are jobs for a tool that reads the topic directly, with the schema registry attached so that Avro and Protobuf records are decoded.

No tool here leads on every criterion. Kpow does not manage Managed Kafka Connect, which the Google Cloud console does; the separate build is one more image tag to track; and Google’s schema registry it connects to is itself still in Preview. It governs people working through Kpow, so applications keep their own service accounts or certificates, and IAM roles or Kafka ACLs stay the control for them. Lenses has the stronger query model with SQL over topics, and the Google Cloud console needs nothing deployed at all. Engineers who work in the Google Cloud console are already recorded under their own identities in Cloud Audit Logs; Kpow’s per-person record matters for the work done through a shared tool.

Who runs Kpow on Google Cloud Managed Service for Apache Kafka

No Kpow customer has yet described in public how it runs Kpow on Google Cloud Managed Service for Apache Kafka, so the public record is Factor House’s own. Support for the service arrived in Kpow release 94.2 in May 2025, support for Google’s managed schema registry followed in release 94.3 in July 2025, and since release 95.1 in December 2025 Google support ships in its own build. That build exists because of an issue a Factor House engineer raised on Google’s Kafka auth library in November 2025, “GcpBearerAuthCredentialProvider: eager GoogleCredentials initialization breaks multi-cloud deployments”, which is still open. The step-by-step guides are Set up Kpow with Google Cloud Managed Kafka and Integrate Kpow with Google Managed Schema Registry.

Teams that run Kpow on other managed Kafka services and have said so in public are on the Amazon MSK page, where Belong describes masking and replay on MSK, and on the banking page, where TD Bank describes production access granted for an hour or two through the Kpow API and a Kpow tenant for each onboarded team.

How a team runs Google Cloud Managed Service for Apache Kafka with Kpow

Installing it in the project. A team installs Kpow on GKE with the Helm charts, runs the Docker image on a Compute Engine VM, or runs the JAR directly, using the Google build in each case: the temurin-ubi image tag or kpow-java17-gcp-standalone.jar. The VM or GKE cluster sits in the same VPC as the Kafka cluster, the path Kpow’s guide documents (Google also lets a cluster be made public), and its service account carries the Managed Kafka roles Kpow needs. The full walkthrough is Set up Kpow with Google Cloud Managed Kafka. On GKE the pod’s Google identity comes from Workload Identity Federation for GKE, under the version and annotation conditions set out above, and the Helm charts are open source and listed on Artifact Hub, which publishes a security report for each chart version. Kpow is priced per cluster, which suits a service where a team chooses vCPUs and memory and Google decides how many brokers to provision, a number its sizing guide says never decreases.

Signing in to the cluster. Kpow connects over SASL_SSL with OAUTHBEARER and Google’s GcpLoginCallbackHandler, so it fetches short-lived OAuth tokens from the Google metadata server for the service account attached to its host and holds no key file. SASL/PLAIN with a service account key or access token is the alternative. Both are in Kpow’s Google cluster documentation, with a one-command quickstart. Because the OAUTHBEARER route needs no key, it works in organisations where service account key creation is disabled. Kpow’s setup guide attaches the Managed Kafka Admin role to that service account; the permission Google requires for the Kafka connection itself is managedkafka.clusters.connect, which the narrower Managed Kafka Client role also carries, so a team applying least privilege can test Kpow with the narrower role and Kafka ACLs.

Signing people in. Engineers sign in to Kpow through any standard OpenID Connect provider, Okta, GitHub, SAML or LDAP, so access follows the company directory rather than everyone sharing the tool’s service account.

Reading Avro and Protobuf topics. Kpow connects to the managed schema registry with Google’s bearer token provider and manages its subjects, versions and compatibility settings. Data inspect shows Avro and Protobuf records decoded against it, and engineers filter them across topics with kJQ.

Managing Kafka ACLs. Google authorises SASL principals with IAM roles or Kafka ACLs, and mutual TLS principals with Kafka ACLs only. Kpow creates, clones and deletes those ACLs from its UI, by principal, topic or consumer group, and records each ACL action in its audit log. Google’s recipe for default-deny is to give an administrator principal an ACL on every resource, after which any principal without an ALLOW entry is refused, Kpow’s service account included, so that account needs its minimum ACLs before the change is made. Because ACL principals on Google cannot be groups, each application’s service account or certificate name gets its own entries, and cloning an existing principal’s ACLs in Kpow is the quick way to set up the next one.

Running connectors. Managed Kafka Connect clusters stay in the Google Cloud console, gcloud or Terraform, because Kpow does not yet integrate with Google’s Connect API. A Kafka Connect cluster the team runs itself, on GKE for example, is managed in Kpow through its REST API. That covers every connector outside Google’s seven built-in types, since custom plugins cannot be uploaded to Managed Kafka Connect.

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. Consumer group lag and other computed metrics are exported to Prometheus alongside Cloud Monitoring. Because Google does not support JMX on the brokers, these figures are computed from the Kafka API, in the same way on Google as on any other cluster Kpow manages. Google’s client monitoring guide adds that its server-side error metric misses some failures, a client blocked by a misconfigured authorisation setting among them, and recommends monitoring clients as well as the cluster.

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. Kpow roles come from the identity provider, which gives the team-level access that Kafka ACLs on Google cannot, since those ACLs do not resolve Google groups.

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 HTTP endpoint. The audit log is a topic on the team’s own Google cluster. Once Data Access audit logs are enabled, Cloud Audit Logs show Kpow’s service account connecting and Kpow’s audit log shows which engineer did what through that connection, so the two records are read together.

The public Kpow demo runs on two Amazon MSK clusters, not on Google Cloud, and needs no signup. It shows the same brokers, topics, consumer groups, data inspect and schema registry views; Google sign-in, masking and temporary policies are the things to test in your own project. The audit log is the __oprtr_audit_log topic on MSK Secondary, the cluster the demo opens on.

Kpow live demo

See the Kpow views a Google Cloud team works in

The live Kpow demo runs on two Amazon MSK clusters rather than on Google Cloud, and needs no signup. It shows the same views a team gets on a Google cluster: brokers, topics, consumer groups, data inspect with kJQ, schema registries and the audit log topic.

For platform teams choosing a Kafka tool for Google Cloud Managed Service for Apache Kafka.

Try the Kpow demo→

FAQ

What is the best Kafka UI for Google Cloud Managed Service for Apache Kafka?

On this page’s rubric, Kpow, with 84 of 100 points: it signs in over OAUTHBEARER with the host’s service account, reads and manages Google’s managed schema registry, adds per-person roles, masking, approvals and an audit trail on top of IAM, and runs as one container in your VPC outside the data path. Kafbat UI is the highest-scoring open-source option, at 65, and the Google Cloud console scores 61 with nothing to deploy.

Does Kpow support Google Cloud Managed Service for Apache Kafka?

Yes. Kpow has supported the service since release 94.2 in May 2025 and Google’s managed schema registry since release 94.3 in July 2025. It connects over OAUTHBEARER with Google’s auth library or over SASL/PLAIN, using the temurin-ubi Docker tag or kpow-java17-gcp-standalone.jar, as set out in Kpow’s Google cluster documentation. Google Managed Kafka Connect is not yet supported.

Is Apache Kafka for BigQuery the same as Google Cloud Managed Service for Apache Kafka?

Yes. Google’s release notes record that Apache Kafka for BigQuery was renamed Google Cloud Managed Service for Apache Kafka on 9 August 2024, before the service became generally available on 12 November 2024. The tools on this page are scored against the current service.

Can I view messages in a Google Cloud Managed Kafka topic from the Google Cloud console?

No. The topic details page shows configuration, partitions, Cloud Monitoring charts and subscribed consumer groups, not the records. Reading or searching messages needs the Kafka command-line tools or a UI such as Kpow, Kafbat UI or AKHQ.

Which Kafka UI tools support Google IAM authentication with OAUTHBEARER?

Kpow and Kafbat UI both document OAUTHBEARER with Google’s GcpLoginCallbackHandler. Kpow’s guide, Set up Kpow with Google Cloud Managed Kafka, takes short-lived tokens from the service account attached to the VM, and Kpow needs its Google build for this. Kafbat UI has bundled the library since v1.3.0, and its guide mounts a service account key file. Conduktor documents SASL/PLAIN with a service account key or access token. Lenses has said on its community forum that it supports the service but publishes no Google-specific setup, and AKHQ and Redpanda Console publish no Google-specific guidance.

Which Kafka UI works with the Google managed schema registry?

Kpow documents it: it connects with GcpBearerAuthCredentialProvider, manages subjects, versions and compatibility, and decodes Avro and Protobuf records in data inspect. The registry does not support JSON schemas. None of the other third-party tools on this page documents a connection to it. Registries beyond Google are compared in Kafka schema registry tools.

Can a Kafka UI manage Google Managed Kafka Connect connectors?

Not the third-party tools on this page. Managed Kafka Connect is run through the Google Cloud console, gcloud, Terraform and the Managed Kafka API, and does not expose the Kafka Connect REST API that UI tools use. Kpow’s documentation says integration will come at a later stage. Kpow does manage Kafka Connect clusters a team runs itself, and Kafka Connect monitoring tools compares the options there.

Why does Kpow need a separate image for Google Cloud?

Google’s GcpBearerAuthCredentialProvider disallows other credential providers on the same classpath, an open issue on Google’s library. Kpow therefore ships Google support in the temurin-ubi Docker tag and kpow-java17-gcp-standalone.jar, released with every version.

Is there a free Kafka UI for Google Cloud Managed Kafka?

Kafbat UI and AKHQ are open source, and Kafbat UI has Google sign-in built in. Kpow’s Google documentation carries both the Community and Enterprise badges, and Kpow Community Edition is free on up to 3 clusters and 10 users; RBAC, masking, staged approvals and the audit log need Kpow Enterprise. More free options are compared in the best free Kafka UI tools.

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

No. Kpow runs as one container in your project, connects 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.

Does a Kafka UI replace IAM roles and Kafka ACLs on Google Cloud?

No. IAM roles, or Kafka ACLs for mutual TLS principals, still control what applications can do. A tool such as Kpow adds per-person roles, masking, approvals and an audit trail for the engineers who work through it, and Kpow also manages the Kafka ACLs themselves.

Does Google Cloud audit logging show which engineer read a Kafka topic?

Not when engineers work through a shared tool. Cloud Audit Logs for Managed Service for Apache Kafka record administrative actions, such as deleting a topic, updating a consumer group or changing an ACL, under the identity that made them, and Data Access logs, which must be enabled, record API reads and the authentication of each Kafka connection. The audited methods include no per-record read, and a tool that connects with its own service account is the identity Google sees. Kpow’s audit log captures the actions users take in Kpow, with the user from the identity provider. The audit options are compared in Kafka audit logging tools.

Can an AI agent manage Google Cloud Managed Service for Apache Kafka?

Google runs a remote MCP server for the service, generally available on its global endpoint, that lets an agent create and manage clusters, topics, consumer groups, ACLs, Connect clusters and connectors with the IAM permissions of the identity it uses. Factor House’s fh CLI, in beta, calls the same REST API as the Kpow web UI and signs in the way the Kpow deployment does, including OpenID Connect, and its Agent Skills let a coding agent answer questions such as which consumers are behind through Kpow; the one skill that changes committed offsets runs only when it is named. The options are compared in the best Kafka MCP servers.

Do Google IAM roles control which topics a Kafka client can read on Managed Service for Apache Kafka?

No. Google’s Kafka ACL documentation says standard Apache Kafka clients are only subject to a cluster-level IAM check for the initial connection. Inside the cluster, access is decided by Kafka ACLs, and clusters run with allow.everyone.if.no.acl.found set to true, so a topic with no ACL is open to every authenticated principal. IAM roles and IAM Conditions govern the Managed Kafka API that the console and gcloud use.

Can a Kafka ACL on Google Cloud Managed Service for Apache Kafka name a Google group?

No. Google states that Kafka ACL principals must be a user, a service account or an individual IAM principal, and that Kafka ACLs do not resolve group memberships. Its documented workaround is a proxy service account that group members impersonate. A tool such as Kpow takes its roles from the identity provider, so team-level access for people is set in the tool.

Can a Kafka UI connect when service account key creation is disabled in the Google Cloud organisation?

Yes, if it signs in over OAUTHBEARER with the identity its workload runs as. Google’s security baseline disables service account key creation in organisations created on or after 3 May 2024, which blocks SASL/PLAIN with a key and any setup that mounts a JSON key file until an administrator relaxes the policy. Kpow’s documented OAUTHBEARER route takes short-lived tokens for the attached service account and needs no key.

Can I run my own connector plugins on Google Managed Kafka Connect?

No. Google’s Kafka Connect overview states that custom connector plugins cannot be uploaded, and its connector list has seven built-in types. Other connectors run on Kafka Connect workers a team hosts itself, which expose the Connect REST API that Kpow manages.

How do I monitor consumer lag on Google Cloud Managed Service for Apache Kafka?

Google’s console shows offset lag by partition on each consumer group’s Monitoring tab, and Cloud Monitoring carries a consumer lag metric to alert on: managedkafka.googleapis.com/consumer_lag. Kpow shows each consumer group down to partition level, resets, clears or skips offsets from the same view, and exports group lag to Prometheus. Other options are compared in Kafka consumer lag monitoring tools.

How these tools were scored

Four of the six criteria start from Google’s documentation for Managed Service for Apache Kafka; the other two are where the tool runs and whether it manages clusters elsewhere too. 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. Governance beyond IAM (counts three times). IAM decides what a principal may do, Cloud Audit Logs record each administrative action under the identity that made it, and Privileged Access Manager can grant a role for a limited time after approval. None of them masks a field in a record, holds an individual topic deletion or offset reset for approval, or records which engineer read which message, and a shared tool’s service account makes the tool the principal. This criterion scores per-person roles, production access granted on request and expiring, masking, directory sign-in, tenants for teams sharing a cluster, and an audit trail that names the person. Third-party tools keep their scores from the Amazon MSK page, because the evidence is each tool’s own feature set rather than the cloud. The Google Cloud console scores 5, as the Confluent Cloud Console does on the Confluent Cloud page, because engineers who work in it do so under their own identities, with per-user roles and an audit record, but it shows no records to mask and approves no individual change. The requirements for regulated teams are covered in Kafka governance tools for financial services, and the masking options are compared in Kafka data masking tools.

2. Out of the data path (counts twice). The tool should run inside your Google Cloud project and VPC, reach the brokers over the same private 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 Google Cloud console. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.

3. Google IAM sign-in (counts twice). Google recommends OAUTHBEARER inside Google Cloud, with tokens from Application Default Credentials, and also accepts SASL/PLAIN with a service account key or access token, which it calls useful for early development, and mutual TLS on clusters created after 24 June 2025. A tool scores 8 when its documentation gives OAUTHBEARER with Google’s library from the identity the workload runs as, so it holds no key; 7 when it documents OAUTHBEARER with Google’s library but has the reader mount a service account key file; 6 when it documents only SASL/PLAIN; 5 when the vendor has said it supports the service without publishing Google-specific setup; and 4 when nothing Google-specific is published and the reader works the configuration out. Kpow scores 8 and not higher because Google support needs its separate build.

4. On-prem and cloud together (counts once). Many teams on Google Cloud also run Kafka on-prem or on another cloud. This scores whether one deployment manages all of those clusters with the same controls. Scores match the banking page, with Redpanda Console’s taken from the multi-cluster comparison; the Google Cloud console shows Google clusters only.

5. Registry and Managed Connect (counts once). Google’s managed schema registry accepts bearer tokens and holds Avro and Protobuf schemas, and Managed Kafka Connect is run through Google’s own API rather than the Kafka Connect REST API. A tool scores well when it documents both. Kpow documents the registry and not Managed Connect, so it scores 6; the Google Cloud console creates and manages both, without decoding records against the registry, so it scores 8; the other tools document neither and score 1, Kafbat UI included, whose OAuth2 client credentials option for registries does not match how Google issues tokens.

6. Inspecting topic data (counts once). The Google Cloud console shows topics, partitions, consumer groups and metrics, but not the records. Reading a message, searching a topic for one key or replaying a record after an incident is the day-to-day job engineers need a tool for. Scores match the Amazon MSK page.

Costs are modelled for one production 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 carry 6 hours a month, $8,640 a year, to run, secure and keep current. The Google Cloud console has no licence and nothing to run, and the Kafka command-line tools it leaves record reading to are 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 its 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. The service’s own charges for brokers, storage and Connect workers are the same whichever tool a team chooses, so they are left out.

The criteria map onto the Google Cloud features in the figure below.

F1 From Google Cloud Managed Kafka feature to what a Kafka tool has to do

What the Google service does What the tool has to do

Google IAM sign-in Clients connect over SASL_SSL with OAUTHBEARER, using Google's GcpLoginCallbackHandler and Application Default Credentials, and the principal needs the Managed Kafka Client role Ship Google's Kafka auth library and take credentials from the attached service account, not from a stored key

SASL/PLAIN A service account email with a base64-encoded key, or a short-lived access token, as username and password Accept it where OAUTHBEARER is not possible, knowing a key file is a long-lived secret to rotate

Mutual TLS Certificate sign-in on port 9192 for clusters created after 24 June 2025, with principals authorised by Kafka ACLs only Connect with ordinary SSL client settings, then manage the Kafka ACLs that authorise each certificate

Schema registry (Preview) Implements the Confluent Schema Registry REST API for Avro and Protobuf, behind Google bearer tokens Send a fresh Google token with every registry call, then decode Avro and Protobuf records for engineers

Managed Kafka Connect Generally available since 1 October 2025, managed through the console, gcloud, Terraform and the Managed Kafka API, with no Kafka Connect REST endpoint Call Google's Managed Kafka API, because a tool that speaks only the Connect REST API cannot reach it

Topic data The console shows topic configuration, consumer groups and Cloud Monitoring charts, and not the records Read, search and decode records, and reset offsets, from one place

Where the tool runs Brokers sit in your VPC, and producers and consumers connect to them directly Run in the same project and VPC 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: Governance beyond IAM counts three times, Out of the data path counts twice, Google IAM sign-in counts twice, On-prem and cloud together counts once, Registry and Managed Connect counts once and Inspecting topic data counts once, for a total out of 100. Governance beyond IAM counts three times because on a shared Google cluster IAM authorises the tool's own service account, so for work done through the tool, per-person roles, production access granted on request, masking, directory sign-in, tenants for shared clusters and a per-person audit trail in the tool are the only record of which engineer did what. Out of the data path and Google IAM sign-in count twice: a tool that clients connect through becomes part of the path every producer and consumer depends on, and one that needs a database of its own is one more component to run and secure in the VPC, while a tool that cannot sign in the way Google recommends ends up holding a service account key. On-prem and cloud together, the schema registry and Managed Kafka Connect, and inspecting topic data count once. 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 84 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
• Kafka-compatible cloud brokers
• Set up Kpow with Google Cloud Managed Kafka
• Integrate Kpow with Google Managed Schema Registry
• Best Kafka UI tools for Amazon MSK
• Best Kafka management tools for banks
• Best Kafka governance tools for financial services
• Kafka multi-cluster management tools
• Best Kafka management tools
• Best Kafka UI tools for Confluent Cloud
• Best Kafka management tools for Confluent Platform
• Best Kafka tools for NetApp Instaclustr managed Kafka
• Best Kafka tools for self-managed Apache Kafka
• Best Kafka tools for Aiven for Apache Kafka
• Best Kafka UI tools for Redpanda
• Best Kafka UI tools for OCI Streaming with Apache Kafka