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. Kpow is Factor House’s product, and I work at Factor House as a Solutions Architect, so it is scored on the same rubric and the same sources as every other option. The page sits inside the complete Kafka guide and the Kafka stream governance topic.
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 our 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.
How to score a Kafka RBAC tool
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, our 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, our 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 our Kafka operational issues talk I 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.
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.
| Tool | Enforcement layer | Who it binds | Resources covered | Identity source | Change control and audit | Source |
|---|---|---|---|---|---|---|
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
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
47 out of 60 Total
Listed first because it is our product. Scores are unadjusted.
- 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
- 9 out of 10
- Topology fit
- 9 out of 10
- Works on any Kafka
- 8 out of 10
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.
Rank 2 Kafbat UI
38 out of 60 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
- 5 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 8 out of 10
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.
Rank 3 37 out of 60 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
- 8 out of 10
- Topology fit
- 6 out of 10
- Works on any Kafka
- 8 out of 10
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.
Rank 4 AKHQ
37 out of 60 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
- 5 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 8 out of 10
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.
Rank 5 Confluent RBAC
confluent.io
36 out of 60 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 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 1 out of 10
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 6 Apache Ranger
35 out of 60 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
- 7 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 6 out of 10
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.
Rank 7 OPA authorizer plugin
32 out of 60 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
- 5 out of 10
- Topology fit
- 6 out of 10
- Works on any Kafka
- 6 out of 10
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.
Rank 8 Conduktor
conduktor.io
32 out of 60 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 out of 10
- Topology fit
- 4 out of 10
- Works on any Kafka
- 7 out of 10
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
Rank 9 Strimzi with the Keycloak authorizer
29 out of 60 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 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 3 out of 10
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.
Rank 10 Lenses
lenses.io
29 out of 60 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 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 6 out of 10
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 11 Native Kafka ACLs
25 out of 60 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
- 1 out of 10
- Topology fit
- 5 out of 10
- Works on any Kafka
- 8 out of 10
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.
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. Our 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.