Best tools for Kafka role-based access control (RBAC)
ComparisonsApache Kafka has no role-based access control. Its standard authorizer checks every request against ACLs, allow or deny rules written per principal, so roles have to come from a layer added on top: a replacement broker authorizer, a proxy, or a management UI.
That leaves eleven realistic options, from staying on native ACLs through Apache Ranger, OPA, Strimzi with Keycloak, Klaw and Confluent’s RBAC, to the UI-layer RBAC in Kpow, Kafbat UI, AKHQ, Conduktor and Lenses. The page sits inside the complete Kafka guide and the Kafka stream governance topic.
At a glance
Eleven options are scored here on this page's six weighted criteria, 80 points in all. The rubric is weighted: Change and audit counts three times, and Enforcement layer, Resource coverage, Identity source, Topology fit and Works on any Kafka count once. The five listed first, of eleven, each out of 80: Kpow 65, which takes its best score on Resource coverage (9 out of 10) and its lowest on Enforcement layer (4 out of 10); Klaw 53; Apache Ranger 49; Kafbat UI 48; AKHQ 47.
Does Apache Kafka support RBAC?
No. The Apache Kafka authorization documentation describes a pluggable framework set with authorizer.class.name, and a default implementation that stores ACLs in the cluster metadata log. On a KRaft cluster that is:
authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizerEach ACL takes the form “Principal P is Allowed or Denied Operation O from Host H on any Resource R matching ResourcePattern RP”. There is no role object and no group object in that model. A resource with no matching ACL is closed to everyone except the principals listed in super.users, unless you set allow.everyone.if.no.acl.found=true. Clusters still on ZooKeeper run the older AclAuthorizer with the same rule format. The full syntax, with copy-paste kafka-acls.sh commands, is on the Kafka ACL page.
Two Apache features stop ACLs from growing one rule per topic. KIP-290 added prefixed resource patterns, so one ACL can cover every topic that starts with payments-. And the principal a connection authenticates as can be reshaped with ssl.principal.mapping.rules or a custom principal.builder.class. Neither turns a directory group into a set of permissions. To get that you either keep writing ACLs per principal, or you replace or wrap the authorizer.
The enterprise distributions take the second route. Confluent’s documentation (“Use role-based access control (RBAC) for authorization in Confluent Platform”) describes predefined roles bound to users and groups from LDAP or an OIDC provider, stored in a Metadata Service (MDS) that runs on Confluent Server brokers, with the Confluent Server Authorizer evaluating both role bindings and ACLs. Apache Ranger, OPA and Strimzi’s Keycloak authorizer do the same job on open-source Kafka by plugging into authorizer.class.name.
If you are still deciding whether roles are worth the migration at all, RBAC for Kafka: implementation and considerations walks through the ACL-versus-role trade-off with a working lab.
The options
Grouped by the layer they enforce at, which is the grouping that matters most.
- Broker level, every client bound: native Kafka ACLs, Confluent RBAC, Apache Ranger, the OPA authorizer plugin, and Strimzi with the Keycloak authorizer.
- Proxy level, every client routed through it bound: Conduktor Gateway in its Gateway-managed mode.
- Request workflow on top of broker ACLs: Klaw, which grants roles for requesting and approving changes and then writes ordinary Kafka ACLs.
- UI and control-plane level, only tool users bound: Kpow, Kafbat UI, AKHQ, Conduktor Console and Lenses.
Kafka RBAC tools compared
Same six fields for every option, taken from each tool’s own documentation or source code.
| Rank | Tool | Enforcement layer | Who it binds | Resources covered | Identity source | Change control and audit | Source |
|---|---|---|---|---|---|---|---|
| 1 | Kpow | UI and API, through Kpow’s RBAC | People using Kpow | Clusters, topics, groups, brokers, Connect, Schema Registry and ksqlDB | Roles from SAML, OpenID or LDAP | Allow, Deny or Stage per action, every action in an audit log | Kpow RBAC docs |
| 2 | Kafbat UI | UI, enforced in its backend | People using Kafbat UI | Cluster config, topics, consumers, schemas, Connect, connectors, KSQL and ACLs | OAuth, Google, GitHub, Cognito, LDAP and Active Directory subjects | Optional audit to a Kafka topic or console. No approval step | Kafbat UI RBAC docs |
| 3 | Klaw | Workflow layer that writes Kafka ACLs | Clients, once approved ACLs land on the broker | Topics, ACLs, Avro schemas and connectors, as requests | Klaw users and teams | Every topic, ACL, schema and connector change goes through a request and approval | Klaw on GitHub |
| 4 | AKHQ | UI and API, through groups and roles | People using AKHQ | Topics, topic data, groups, Connect, schemas, nodes, ACLs and ksqlDB | Basic auth, LDAP, OIDC, GitHub or header auth, mapped to groups | Opt-in audit events to a Kafka topic. No approval step | AKHQ groups docs |
| 5 | Confluent RBAC | Broker, through the Confluent Server Authorizer and MDS | Every client of an MDS-managed Confluent Platform cluster | Kafka plus Connect, ksqlDB, Schema Registry and Flink across the Confluent Platform | Users and groups from LDAP or an OIDC provider | Role bindings held centrally in MDS | Confluent documentation, RBAC overview |
| 6 | Apache Ranger | Broker, through RangerKafkaAuthorizer | Every client of the cluster | Kafka resources, managed as Ranger policies | Users, groups and roles managed in Ranger | Central policy administration and access auditing in Ranger | Ranger Kafka plugin source |
| 7 | OPA authorizer plugin | Broker, through OpaAuthorizer calling an OPA instance on each broker | Every client of the cluster | Any Kafka operation you write Rego policy for | Whatever your policy reads from the principal and request | Policy lives in code, so review happens in version control | opa-kafka-plugin |
| 8 | Strimzi with Keycloak | Broker, through KeycloakAuthorizer | Every client of the Strimzi cluster | Kafka resources mapped to Keycloak Authorization Services | Permissions from Keycloak Authorization Services, identities from OAuth 2.0 tokens | Permissions administered in Keycloak | Strimzi docs |
| 9 | Lenses | UI and API, through Lenses IAM | People and service accounts using Lenses | Actions on Lenses-managed resources, scoped by policy | Groups that carry roles. Roles cannot be assigned to individuals | Allow or deny effects per policy | Lenses documentation, Security page |
| 10 | Native Kafka ACLs | Broker, through StandardAuthorizer | Every client that authenticates to the cluster | Topics, groups, cluster, transactional IDs and delegation tokens. Not Connect REST, Schema Registry or ksqlDB | The authenticated principal only. No groups or roles | No approval step. Changes are made with kafka-acls.sh or the Admin API | Apache Kafka docs |
| 11 | Conduktor | Console RBAC for UI users, plus optional Gateway ACLs at the proxy | Console users, and clients that connect through Gateway | Topics, groups, subjects, connectors and cluster ACL and broker settings | Users and groups | Permissions per user or group across clusters | Conduktor documentation, Kafka RBAC and Gateway authentication pages |
Each option in detail
Every entry has the same four parts: what it is, where it enforces, the strongest case for it, and where it falls short.
Rank 1 Kpow
65 out of 80 Total
Try Kpow in the live demo No signup needed.
- Layer
- UI and API, Kpow RBAC
- Edition
- RBAC in Enterprise, not Community
- Deployment
- Self-hosted only
- Enforcement layer
- 4 out of 10
- Resource coverage
- 9 out of 10
- Identity source
- 8 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Topology fit
- 9 out of 10
- Works on any Kafka
- 8 out of 10
Why these scores for Kpow
- Enforcement layer 4 out of 10
- It enforces in the UI and API and binds people using Kpow, since “A developer who also holds cluster credentials is bound by Kafka ACLs, not by Kpow.” That places it below the broker layer and Conduktor’s proxy.
- Resource coverage 9 out of 10
- It has “The widest resource coverage of the UI tools”, covering clusters, topics, groups, brokers, Connect, Schema Registry and ksqlDB, but sits below Confluent RBAC, which covers the most ground on the page.
- Identity source 8 out of 10
- Roles come from SAML, OpenID or LDAP, mapped in a YAML file. That sits below Confluent, which the page scores highest on identity.
- Change and audit 9 out of 10
- The page says “Kpow scores highest on resource coverage and change control”, with Allow, Deny or Stage per action, staged actions approved by an admin, and every action in the audit log.
- Topology fit 9 out of 10
- Criterion 5 asks for scoped visibility, not just scoped permissions; “tenants restrict which resources a role can see at all”, the only option the page shows doing this.
- Works on any Kafka 8 out of 10
- The page’s summary puts it as “Like the open-source UIs it runs against MSK, Confluent, Aiven or self-managed clusters alike.”
What it is. Factor House’s Kafka management UI and API, with RBAC, multi-tenancy and audit logging in the Enterprise edition.
Where it enforces. In Kpow. A user’s roles decide what they can do through Kpow, and Kpow reaches the cluster with its own connection, which needs the minimum Kafka ACLs if the cluster has ACLs enabled.
Strongest case. The widest resource coverage of the UI tools, with policies over clusters, Schema Registry, Connect and ksqlDB in one taxonomy. A Stage effect turns a risky action into a request an admin approves, and tenants restrict which resources a role can see at all. Every action lands in the audit log. It also gives you a management interface for the broker-level layer, with ACL create, clone and delete recorded in the same log.
Where it falls short. Its RBAC governs actions taken through Kpow. A developer who also holds cluster credentials is bound by Kafka ACLs, not by Kpow. It is self-hosted only, and RBAC is not in the Community edition.
Staying patched. Kpow’s release notes name the CVEs each release remediates, and the 96.4 image built on 5 August 2026 bundles 311 dependencies of which one carries a high or critical advisory, none of them published before that release. That is not a claim to patch faster than a community project: Kpow’s own dependency remediation has run from 14 to 128 days, and the current image still ships CVE-2026-75595 in netty, a 9.1 critical public since 19 August 2026, unpatched. What a licence buys here is not a different deployment model, because Kpow is self-hosted too. It is a company contracted to ship the fix. Every dependency figure on this page was read on 24 September 2026 from the published artefacts and from nvd.nist.gov.
Rank 2 53 out of 80 Total
- Layer
- Workflow that writes Kafka ACLs
- Type
- Self-service portal
- Enforcement layer
- 6 out of 10
- Resource coverage
- 6 out of 10
- Identity source
- 3 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 8 out of 10
- Topology fit
- 6 out of 10
- Works on any Kafka
- 8 out of 10
Why these scores for Klaw
- Enforcement layer 6 out of 10
- It is a workflow layer that writes Kafka ACLs, so clients are bound once approved ACLs land on the broker, and Klaw’s own roles bind only who requests and approves.
- Resource coverage 6 out of 10
- It reaches topics, ACLs, Avro schemas and connectors as requests, with no ksqlDB, and the connector and schema reach is over requests, not runtime access.
- Identity source 3 out of 10
- Identities are Klaw users and teams, and the page names no directory or identity provider it reads roles from, so this is a best guess from thin evidence.
- Change and audit 8 out of 10
- Every topic, ACL, schema and connector change goes through a request and approval, recording “who asked for this access and who approved it”. That places it below Kpow, which the page says scores highest on change control.
- Topology fit 6 out of 10
- Organises access by team, with roles for “users of various teams of an organization”, but it does not scope what anyone can see.
- Works on any Kafka 8 out of 10
- Writes ordinary Kafka ACLs through the Admin client, the same path native ACLs use, so it is not tied to one vendor’s brokers.
What it is. An open-source self-service portal for topics, ACLs, schemas and connectors. Its README describes it as automating those changes “by introducing roles/authorizations to users of various teams of an organization.”
Where it enforces. Klaw’s roles govern who may request and approve a change. What reaches the broker is an ordinary Kafka ACL written through the Admin client, so enforcement stays with the broker authorizer.
Strongest case. It fixes the process problem that makes ACLs painful, who asked for this access and who approved it, without replacing the authorizer.
Where it falls short. It does not add roles to the broker. A client’s access is still exactly the ACLs Klaw wrote, and Klaw is not an operations console for inspecting data or resetting offsets.
Staying patched. Klaw is Apache-2.0 under Aiven, with a published security policy and the patch record to match it. Three CVEs, and the fix shipped the same day for CVE-2026-25999 in February 2026 and the next day for the two published in May 2026. Seven releases in two years, most recently v2.10.6 in September 2026. Community-maintained is not the same as unmaintained, and this is the end of that range where it shows.
Rank 3 Apache Ranger
49 out of 80 Total
- Layer
- Broker, RangerKafkaAuthorizer
- Policies
- Managed in Ranger, not kafka-acls.sh
- Enforcement layer
- 8 out of 10
- Resource coverage
- 2 out of 10
- Identity source
- 7 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 7 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 6 out of 10
Why these scores for Apache Ranger
- Enforcement layer 8 out of 10
- It sits in the broker as RangerKafkaAuthorizer and binds every client of the cluster.
- Resource coverage 2 out of 10
- It covers Kafka resources managed as Ranger policies, and nothing on Connect, Schema Registry or ksqlDB.
- Identity source 7 out of 10
- Users, groups and roles are managed in Ranger, which the page describes as “Ranger with synced groups”.
- Change and audit 7 out of 10
- Ranger holds central policy administration and access auditing, giving “one policy store and one audit trail”, though no approval step is described.
- Topology fit 5 out of 10
- Policies scope permissions; the page describes no scoped visibility.
- Works on any Kafka 6 out of 10
- Plugs into authorizer.class.name on open-source Kafka, but you take on running Ranger, and ACL-editing tools cannot manage access on that cluster.
What it is. The Apache project for centralized security administration across the Hadoop ecosystem, with a Kafka plugin.
Where it enforces. In the broker. RangerKafkaAuthorizer implements Kafka’s Authorizer interface. Its createAcls, deleteAcls and acls methods throw “not supported by Ranger for Kafka”, so policies are managed in Ranger rather than with kafka-acls.sh.
Strongest case. One policy store and one audit trail if you already run Ranger for HDFS, Hive or other data platforms. The Ranger project page lists role-based and attribute-based access control among its goals.
Where it falls short. Because the ACL APIs are unsupported, any tool that lists or edits ACLs, including Kpow’s ACL screens, cannot manage access on a Ranger-authorized cluster. You also take on running Ranger itself.
Staying patched. Apache Ranger is Apache-2.0 and actively developed, with a published security policy, and it carries the exposure of a large, long-lived project: an NVD keyword search returns 36 CVEs across its history. It publishes tags rather than GitHub releases, so the build you run is one you cut and patch yourself.
Rank 4 Kafbat UI
48 out of 80 Total
- Layer
- UI, enforced in its backend
- Type
- Open-source Kafka UI
- Enforcement layer
- 4 out of 10
- Resource coverage
- 8 out of 10
- Identity source
- 8 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 8 out of 10
Why these scores for Kafbat UI
- Enforcement layer 4 out of 10
- It is enforced in its own backend at the UI layer and binds people using Kafbat UI, “UI users only, like every tool in this group”.
- Resource coverage 8 out of 10
- It reaches cluster config, topics, consumers, schemas, Connect, connectors, KSQL and ACLs, which the page calls “broad resource coverage”, still below Kpow, the widest of the UI tools.
- Identity source 8 out of 10
- Subjects come from OAuth, Google, GitHub, Cognito, LDAP and Active Directory, and regex subjects match a family of IdP roles in one rule.
- Change and audit 5 out of 10
- Audit is optional, to a Kafka topic or console, with no approval step, which the page calls “weaker audit and no approvals”.
- Topology fit 5 out of 10
- Roles scope permissions per resource; the page describes no scoped visibility.
- Works on any Kafka 8 out of 10
- One of the open-source UIs the page says run against any cluster, as Kpow does.
What it is. An open-source Kafka web UI.
Where it enforces. In Kafbat UI’s backend, through its access control service, for people using the UI.
Strongest case. Free, broad resource coverage, including ACLs and KSQL, and regex subjects that can match a whole family of IdP roles in one rule.
Where it falls short. UI users only, like every tool in this group. Audit is optional and writes to a topic or the console, and there is no approval workflow.
Staying patched. Kafbat UI released v1.5.0 in April 2026 and has not shipped since. In the 157 days since, at least 20 high or critical advisories have been published against libraries that release bundles, including the same netty critical CVE-2026-75595 that the current Kpow image carries. Only 150 of its 266 bundled jars resolved to a Maven coordinate, so that count is a floor and the state of the release itself is unmeasured. Kafbat does publish a security policy, which AKHQ and Kafdrop do not, and the one CVE filed against its own code, CVE-2025-49127, was already fixed in the release that preceded the advisory. Six releases in two years.
Rank 5 AKHQ
47 out of 80 Total
- Layer
- UI and API, groups and roles
- Caveat
- UI-only if the JWT secret is unset
- Enforcement layer
- 3 out of 10
- Resource coverage
- 8 out of 10
- Identity source
- 8 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 8 out of 10
Why these scores for AKHQ
- Enforcement layer 3 out of 10
- It enforces in the UI and API and binds people using AKHQ, but without the JWT signature secret “the restriction is in the UI only”, so it scores below the other UIs.
- Resource coverage 8 out of 10
- It covers topics, topic data, groups, Connect, schemas, nodes, ACLs and ksqlDB, below Kpow, the widest of the UI tools.
- Identity source 8 out of 10
- Identity comes from basic auth, LDAP, OIDC, GitHub or header auth, mapped to groups in YAML configuration.
- Change and audit 5 out of 10
- Audit events are opt-in to a Kafka topic with no approval step, which the page calls “weaker audit and no approvals”.
- Topology fit 5 out of 10
- Roles combine resource types with regex patterns on names and clusters, which scopes permissions; no scoped visibility described.
- Works on any Kafka 8 out of 10
- One of the open-source UIs the page says run against any cluster, as Kpow does.
What it is. An open-source Kafka UI with a group and role model rewritten in version 0.25.0.
Where it enforces. In AKHQ’s UI and API, with one caveat from its own documentation: if the JWT signature secret is not set, “the API will not enforce the group role, and the restriction is in the UI only.”
Strongest case. Free, GitOps-friendly YAML configuration, and roles that combine resource types with regex patterns on names and clusters.
Where it falls short. Misconfigure the secret and the restriction becomes cosmetic. Audit is opt-in, and there is no approval step.
Staying patched. AKHQ has no CVE filed against its own code, and that is the wrong number to plan against. Release 0.28.0, cut on 6 August 2026, bundles 270 libraries and 18 of them carry a high or critical advisory. Sixteen were already public, with fixed versions already on Maven Central, on the day it shipped, and five are netty advisories Kpow had remediated three weeks earlier in 96.2: CVE-2026-44249, CVE-2026-45416, CVE-2026-45674, CVE-2026-47691 and CVE-2026-50010. The oldest has been open 108 days. That is exposure and remediation latency rather than a working attack, and every figure resolves against the published jar and nvd.nist.gov. Four releases in two years, and no security policy at any path GitHub reads.
Rank 6 Confluent RBAC
confluent.io
42 out of 80 Total
- Layer
- Broker, Confluent Server Authorizer and MDS
- Requires
- Confluent Server brokers and MDS
- Enforcement layer
- 8 out of 10
- Resource coverage
- 10 out of 10
- Identity source
- 9 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 1 out of 10
Why these scores for Confluent RBAC
- Enforcement layer 8 out of 10
- Enforcement sits at the broker, through the Confluent Server Authorizer and MDS, binding every client of an MDS-managed cluster.
- Resource coverage 10 out of 10
- The page says “Confluent RBAC scores highest on resource coverage”, since it is the only option extending the same bindings to Connect, ksqlDB, Schema Registry and Flink.
- Identity source 9 out of 10
- Users and groups come from LDAP or an OIDC provider, and the page’s summary says “Confluent RBAC scores highest on resource coverage and identity”.
- Change and audit 3 out of 10
- Role bindings are held centrally in MDS, but the page describes no action audit and no approval step.
- Topology fit 5 out of 10
- Role bindings scope permissions per user and group; the page describes no scoped visibility.
- Works on any Kafka 1 out of 10
- Needing Confluent Server brokers and MDS, it does not carry over to MSK or self-managed Apache Kafka, which the page scores “Lowest on distribution dependence”.
What it is. Confluent’s role-based authorization for Confluent Platform. Confluent Cloud documents its own RBAC for its managed clusters.
Where it enforces. At the broker. Confluent’s documentation says every Kafka broker in the MDS-managed cluster must be configured to use that MDS instance, and that RBAC “serves as an additional authorization enforcement layer on top of ACLs”.
Strongest case. It is the only option here that puts predefined roles directly into the broker and extends the same bindings to Connect, ksqlDB, Schema Registry and Flink. If your whole topology is Confluent Platform, it covers the most ground of any option on this page.
Where it falls short. It needs Confluent Server brokers and MDS, so it does not carry over to MSK, self-managed Apache Kafka or another provider’s clusters.
Rank 7 OPA authorizer plugin
42 out of 80 Total
- Layer
- Broker, OpaAuthorizer
- Requires
- Kafka 3.8.0 or later
- If OPA is down
- Requests fail closed by default
- Enforcement layer
- 8 out of 10
- Resource coverage
- 2 out of 10
- Identity source
- 5 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- Topology fit
- 6 out of 10
- Works on any Kafka
- 6 out of 10
Why these scores for OPA authorizer plugin
- Enforcement layer 8 out of 10
- Enforcement happens in the broker, through OpaAuthorizer calling OPA on each broker, so it binds every client of the cluster.
- Resource coverage 2 out of 10
- It covers any Kafka operation you write Rego policy for, still Kafka protocol operations only, with nothing on Connect REST, Schema Registry or ksqlDB.
- Identity source 5 out of 10
- Identity is “whatever your policy reads from the principal and request”, so the group-to-role mapping is code you write, not configuration.
- Change and audit 5 out of 10
- Policy lives in code, so review happens in version control and policy changes get code review, but the page describes no user-action audit or approval of individual actions.
- Topology fit 6 out of 10
- Roles, team ownership and naming conventions are whatever your Rego says, which gives permissions only, with no scoped visibility described.
- Works on any Kafka 6 out of 10
- Plugs into authorizer.class.name on open-source Kafka 3.8.0 or later, and OPA becomes part of every broker’s request path.
What it is. An open-source authorizer that sends each Kafka authorization decision to an Open Policy Agent instance running on the broker host.
Where it enforces. In the broker, set with authorizer.class.name=org.openpolicyagent.kafka.OpaAuthorizer. The README lists Kafka 3.8.0 or later, a decision cache, and opa.authorizer.allow.on.error defaulting to false, which means requests fail closed if OPA is unreachable.
Strongest case. Complete freedom. Roles, team ownership, naming conventions or time windows are whatever your Rego policy says, reviewed like any other code.
Where it falls short. You write and test the policy language yourself, and OPA becomes part of every broker’s request path.
Staying patched. Open Policy Agent is Apache-2.0, actively maintained, with a published security policy and three repository advisories, most recently CVE-2025-46569 in May 2025, a high-severity Rego injection through the Data API path. The project has produced its own fixes, but nobody is contracted to produce the next one.
Rank 8 Strimzi with the Keycloak authorizer
35 out of 80 Total
- Layer
- Broker, KeycloakAuthorizer
- Requires
- Strimzi on Kubernetes, OAuth-capable clients
- Enforcement layer
- 8 out of 10
- Resource coverage
- 2 out of 10
- Identity source
- 8 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 3 out of 10
Why these scores for Strimzi with the Keycloak authorizer
- Enforcement layer 8 out of 10
- KeycloakAuthorizer runs at the broker and binds every client of the Strimzi cluster.
- Resource coverage 2 out of 10
- Kafka resources are mapped to Keycloak Authorization Services, with nothing on Connect, Schema Registry or ksqlDB.
- Identity source 8 out of 10
- Permissions come from Keycloak Authorization Services and identities from OAuth 2.0 tokens, with roles and groups in Keycloak, “which many platform teams already run”.
- Change and audit 3 out of 10
- Permissions are administered in Keycloak, and the page describes no action audit and no approval step.
- Topology fit 5 out of 10
- Keycloak permissions scope what each client can do; the page describes no scoped visibility.
- Works on any Kafka 3 out of 10
- The page says “It assumes Strimzi on Kubernetes and OAuth-capable clients.”
What it is. Strimzi’s OAuth 2.0 support for Kafka on Kubernetes, with an authorizer that reads permissions from Keycloak Authorization Services.
Where it enforces. In the broker. The Strimzi deployment guide configures authorization.type: custom with authorizerClass: io.strimzi.kafka.oauth.server.authorizer.KeycloakAuthorizer, and a strimzi.authorization.delegate.to.kafka.acl setting controls whether failed authorization checks are passed on to Kafka’s built-in ACL authorizer. The same guide notes that the older oauth and keycloak authentication types are deprecated in favour of the custom type.
Strongest case. Role and group management in Keycloak, which many platform teams already run, enforced at the broker for every client. The OAuth library is open source in strimzi-kafka-oauth.
Where it falls short. It assumes Strimzi on Kubernetes and OAuth-capable clients, and Keycloak permission modelling is its own skill to learn.
Staying patched. Strimzi is community-maintained under the CNCF and it answers the patching question better than most vendors do. Thirty-eight releases in two years, six published CVEs, each with a coordinated-disclosure advisory, and on the last three batches the fixed release shipped the same day the advisory was published: 0.49.1 in December 2025, 0.50.1 in February 2026 and 1.0.1 in June 2026. Open source is not the risk here. The absence of a contract is, and Strimzi shows how little that has cost so far.
Rank 9 Lenses
lenses.io
35 out of 80 Total
- Layer
- UI and API, Lenses IAM
- Roles
- Assigned to groups only
- Type
- Commercial
- Enforcement layer
- 4 out of 10
- Resource coverage
- 5 out of 10
- Identity source
- 6 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 6 out of 10
Why these scores for Lenses
- Enforcement layer 4 out of 10
- It applies in the UI and API through Lenses IAM and binds people and service accounts using Lenses, so “it binds Lenses users only”.
- Resource coverage 5 out of 10
- It governs actions on Lenses-managed resources, scoped by policy, and the page does not list which resources, so this is a best guess from thin evidence.
- Identity source 6 out of 10
- Roles are carried by groups, never individuals, and group-only assignment “forces the discipline roles are meant to bring”, with no identity provider named.
- Change and audit 3 out of 10
- Effects are allow or deny per policy, and the page describes no audit log and no approval step, so this is a best guess from thin evidence.
- Topology fit 5 out of 10
- Policies scope permissions for people and service accounts in one model; the page describes no scoped visibility.
- Works on any Kafka 6 out of 10
- The page does not say which distributions Lenses supports. Neutral best guess.
What it is. A commercial Kafka platform with a built-in IAM model.
Where it enforces. In Lenses, for users and service accounts. Its Security page says permissions come from roles attached to groups, and that roles cannot be assigned directly to an individual account.
Strongest case. Group-only assignment forces the discipline roles are meant to bring, and service accounts sit in the same model as people.
Where it falls short. UI-layer enforcement, so it binds Lenses users only.
Rank 10 Native Kafka ACLs
27 out of 80 Total
- Layer
- Broker, StandardAuthorizer
- Managed with
- kafka-acls.sh or the Admin API
- Enforcement layer
- 8 out of 10
- Resource coverage
- 2 out of 10
- Identity source
- 1 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 1 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 8 out of 10
Why these scores for Native Kafka ACLs
- Enforcement layer 8 out of 10
- It applies at the broker through StandardAuthorizer and binds every client that authenticates, including the service accounts of every other tool on this page.
- Resource coverage 2 out of 10
- Coverage runs to topics, groups, cluster, transactional IDs and delegation tokens, but not Connect REST, Schema Registry or ksqlDB, which criterion 2 scores as stopping at topics and groups.
- Identity source 1 out of 10
- It knows the authenticated principal only, with no groups or roles, and principal mapping rules reshape the name but “neither turns a directory group into a set of permissions”.
- Change and audit 1 out of 10
- There is no approval step and changes are made with kafka-acls.sh or the Admin API, and criterion 4 quotes the jumpbox with no audit log.
- Topology fit 5 out of 10
- Prefixed ACLs let teams share a cluster by topic prefix (KIP-290), but the page describes scoped permissions only, not scoped visibility.
- Works on any Kafka 8 out of 10
- Ships with Apache Kafka and needs nothing installed; “Every production cluster needs it whatever else you add.”
What it is. The authorizer that ships with Apache Kafka, managed with kafka-acls.sh or the Admin API.
Where it enforces. In the broker, for every request from every client. On KRaft, admin requests forwarded from a broker are authorized on the active controller with the original client principal, per the Apache docs.
Strongest case. Nothing to install, and it binds everything, including the service accounts of every other tool on this page. Every production cluster needs it whatever else you add.
Where it falls short. Rules attach to principals, not roles, so onboarding a person or a service means writing rules. Prefixed patterns help with topic sprawl, but not with people sprawl.
Rank 11 Conduktor
conduktor.io
38 out of 80 Total
- Layer
- Console UI, plus Gateway proxy
- Type
- Commercial
- Enforcement layer
- 6 out of 10
- Resource coverage
- 7 out of 10
- Identity source
- 5 out of 10
- Change and audit ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Topology fit
- 4 out of 10
- Works on any Kafka
- 7 out of 10
Why these scores for Conduktor
- Enforcement layer 6 out of 10
- Console RBAC covers UI users and optional Gateway ACLs sit at the proxy, making it “the one to beat if you also want a proxy that governs client traffic, a layer Kpow does not have”. The proxy binds only routed traffic, so it sits below the broker layer.
- Resource coverage 7 out of 10
- It covers topics, groups, subjects, connectors and cluster ACL and broker settings, with no ksqlDB named.
- Identity source 5 out of 10
- Identity is users and groups, and the page names no identity provider, so this is a best guess from thin evidence.
- Change and audit 3 out of 10
- Permissions are set per user or group across clusters, and the page describes no audit log and no approval step, so this is a best guess from thin evidence.
- Topology fit 4 out of 10
- Permissions per user or group, but “a user in several groups inherits the most permissive grant”, which weakens isolation between teams.
- Works on any Kafka 7 out of 10
- Gateway governs client traffic “without touching broker configuration” and Console works across clusters. The page does not list supported distributions. Best guess.
What it is. A commercial platform with two products that matter here, Console, a web UI, and Gateway, a Kafka protocol proxy.
Where it enforces. Console RBAC applies to Console users, per user or group, across topics, consumer groups, subjects, connectors and cluster settings. Gateway, in its Gateway-managed mode, handles authentication and ACLs at the proxy for clients that connect through it, according to Conduktor’s Gateway authentication page.
Strongest case. The only commercial option on this page that offers both a UI layer and a proxy layer from one vendor, so client traffic can be governed without touching broker configuration.
Where it falls short. Proxy enforcement only covers traffic routed through Gateway, and Conduktor’s RBAC page notes that a user in several groups inherits the most permissive grant.
Compare Conduktor vs Kafbat UIConduktor vs LensesConduktor review
Which layer to choose
Scored against the six criteria, no single tool wins, because the first criterion splits the field in two.
For enforcement over every client, the broker layer is the only option. Confluent RBAC scores highest on resource coverage and identity if you are all-in on Confluent Platform, and lowest on distribution dependence. Strimzi with Keycloak is the strongest open-source choice on Kubernetes. Ranger fits if Ranger is already your policy store, though it leaves ACL-editing tools unable to manage access on that cluster. OPA suits teams that want policy as code and can own it. Klaw adds the approval process that native ACLs lack without changing the authorizer. If you stay on ACLs, the Kafka ACL management tools comparison scores the ways to keep them under control.
For people, the UI layer is where roles save the most time, because humans are the principals that change most often. Kpow scores highest on resource coverage and change control, with the Stage effect and tenant-scoped views, and like the open-source UIs it runs against MSK, Confluent, Aiven or self-managed clusters alike. Conduktor is the one to beat if you also want a proxy that governs client traffic, a layer Kpow does not have. The two free options, Kafbat UI and AKHQ, handle the basics with weaker audit and no approvals.
The usual end state for a regulated team is two layers: broker ACLs, often managed through one of the tools above, for every service account, and UI RBAC for the humans who debug production.
How Factor House approaches Kafka RBAC
Kpow’s RBAC is a YAML file set with RBAC_CONFIGURATION_FILE. Each policy names a resource, an effect and a list of actions, for a role that comes from your identity provider. The Kpow RBAC documentation has the full model. Three rules shape how it behaves:
- Where no policy matches, the effect is an implicit deny.
- Where policies conflict on one resource, Deny takes precedence.
- Stage makes the action a request that an admin confirms, covered in the staged mutations docs.
Resources follow a taxonomy such as ["cluster", "*", "topic", "tx-*"], with glob wildcards anywhere in the name, so one policy can cover every dead letter topic ending in -dlq. Multi-tenancy sits in the same file and answers a different question, what a role can see. A tenant presents a consistent view of only its topics, groups, connectors and subjects, which is what lets several teams share one cluster without splitting it by governance domain. The Kafka multi-tenancy page shows the two working together, and the data governance docs cover the audit log that records every user action.
Kpow’s RBAC governs what people do through Kpow. It does not replace Kafka ACLs for your applications, and Tom’s rule still holds: roles authorize the user’s request to Kpow, and ACLs authorize Kpow’s connection to Kafka. Pair it with broker ACLs, or one of the broker-level authorizers above, for every client that is not a person in a browser. For the temporary-access case, where someone needs production data for an hour during an incident, temporary policies grant a time-boxed permission instead of a standing one.
If you are designing the roles themselves, RBAC roles covers role definitions and resource patterns across the ecosystem, and multi-tenant architecture covers quotas, naming and isolation for shared clusters.
Kpow live demo
Try role-based access in a Kafka UI
Explore Kpow in a live environment and judge the everyday workflows that role-based access and staged approvals would govern.
For platform and security teams who have to show who can do what.
Try the Kpow demoFAQ
Does Apache Kafka support RBAC natively?
No. Open-source Apache Kafka authorizes with ACLs, per-principal allow and deny rules evaluated by the StandardAuthorizer on KRaft clusters. Roles come from a replacement authorizer such as Ranger, OPA or Strimzi’s Keycloak authorizer, from Confluent’s commercial RBAC, or from a management UI.
Does Kpow RBAC replace Kafka ACLs?
No. Kpow’s RBAC decides what a user can do through Kpow, and Kafka ACLs decide what Kpow’s own connection, and every other client, can do on the cluster. Run both.
Can Kafka ACLs use LDAP or Active Directory groups?
Not with the standard authorizer, which matches ACLs against the authenticated principal. Group-based rules need an authorizer that understands groups, such as Confluent’s RBAC with LDAP, Ranger with synced groups, or Keycloak roles through Strimzi.
What is the difference between RBAC in a Kafka UI and RBAC at the broker?
Broker RBAC binds every client that connects to the cluster. UI RBAC binds only the people using that UI, and does nothing about someone who reaches the cluster with their own credentials.
How these tools were scored
Six criteria, in the order they tend to decide the choice. Most of them come from questions Factor House engineers have had to answer for customers.
1. Enforcement layer. The first question is where the rule is evaluated, because that decides who it binds. A broker authorizer binds every client. A proxy binds every client routed through the proxy. A UI binds the people using that UI and nobody else. Tom Crowley, Factor House’s founding engineer, put the split precisely when a team asked whether Kpow’s RBAC and Kafka ACLs could run together: “Kpow does not use Kafka ACLs to authorize a user’s request, instead we use our RBAC permissions to authorize requests.” In his summary, RBAC is “assigned to a user through their roles, determining how they are authorized when making requests to Kpow”, while ACLs are “assigned to Kpow’s AdminClient connection, determining how Kpow is authorized when making Kafka AdminClient calls.” Every UI tool on this page works that way, and the table says so row by row.
2. Resource coverage beyond topics. Kafka ACLs govern Kafka protocol resources. They say nothing about who can restart a connector through the Connect REST API, which the Apache Kafka Connect guide warns “is unsecured and allows anyone that can access it to start and stop connectors” by default. Tom made the same point about Kpow’s policies, which “work across all resources configured (ksql, connect, schema etc) - unlike Kafka’s ACLs.” The pattern shows up in real requirements. Derek Troy-West, Factor House’s co-founder and CEO, relayed one customer’s list that included stopping teams from reaching other teams’ connectors, with permissions keyed to their LDAP. Score each tool on whether its roles reach Connect, Schema Registry and ksqlDB, or stop at topics and groups.
3. Identity source. Roles only reduce work if they come from the directory you already run. Check which identity providers each tool reads group or role claims from (LDAP, SAML, OIDC), and whether the mapping is configuration or code. The Kafka SSO tools comparison scores the sign-in half of this on its own.
4. Change control and audit. An auditor asks who changed what, and when. Tom described the usual state of production access in 2021: the jumpbox “generally has full access to the Kafka cluster, and there is no audit log recording the actions being committed.” Score each tool on whether it records user actions somewhere you can query, and whether a risky action can require approval rather than being all-or-nothing. The Kafka audit logging tools and destructive operations tools comparisons go deeper on each.
5. Topology fit. Some teams answer an access problem by splitting clusters along team or data-domain lines. In the Q&A of the Kafka operational issues talk Chad Harris argued against that: “governance domains change all the time”, so a cluster-per-domain topology ends up with clusters that no longer match the organisation, and “you probably want to look at better governance and audit controls” instead. A tool scores well here if it lets several teams share one cluster safely, with scoped visibility and not just scoped permissions.
6. Distribution dependence. Some RBAC layers only work on one vendor’s brokers. That matters if you run MSK in one region and self-managed Kafka in another, or expect to change provider. Score each tool on whether it works against any Apache Kafka-compatible cluster.
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: Enforcement layer counts once, Resource coverage counts once, Identity source counts once, Change and audit counts three times, Topology fit counts once and Works on any Kafka counts once, for a total out of 80. Change and audit counts three times here, because a role model nobody can change safely and nobody can reconstruct afterwards fails the review it was built for. Enforcement layer, resource coverage, identity source, topology fit and working on any Kafka count once, and the first of those is where every console tool on this page is weakest. 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 65 out of 80. The other options follow by total. Conduktor is listed last whatever its total; on its total of 38 it would place eighth.