RBAC vs ACLs in Apache Kafka: Choosing the Right Access Control Strategy

Controlling access to Kafka resources requires deciding between network barriers, Access Control Lists (ACLs), and Role-Based Access Controls (RBAC). The choice depends on two factors: what type of entity needs access (humans vs applications), and whether those entities are trusted or untrusted.

This article covers the two most viable protection strategies for Apache Kafka and how trust levels affect your auth decisions.

Network Barriers: Simple but Limited

Network barriers include firewalls, internal IPs, and air-gapped systems. For Kafka, disconnecting from the network is straightforward but doesn't scale for user access control. Because data distribution is Kafka's core use case, firewall rules become complex and unmaintainable fast.

Access Control Lists: Granular but Unmanageable

ACLs are simple rules governing access to individual objects by individual entities. A basic Kafka ACL might look like:

ANONYMOUS has NO ACCESS to topic="book_topic";

Bob has WRITE access to topic="book_topic";

Alice has READ access to topic="book_topic";

Mitch has READ AND WRITE access to topic="book_topic";

Kafka ACLs go beyond READ and WRITE. They also cover consumer group creation, topic configuration, cluster administration, and broker operations.

The problem: ACLs grow large, become hard to debug, and require constant maintenance. Teams end up building a poor substitute for RBAC that doesn't scale.

Role-Based Access Controls: The Scalable Solution

RBAC abstracts ACL permissions into manageable groups. Instead of assigning permissions per user, you create roles with defined permissions, then assign users to roles.

This approach lets you define permissions once and reuse them across your organization. Adding a new team member means assigning them to the right group, not creating dozens of individual ACL rules.

Control Plane Security Challenges

Implementing RBAC and ACL security for Kafka UIs creates a specific problem: each end-user needs their own Kafka broker identity to maintain consistent security. This becomes impractical at scale.

Creating individual Kafka clients per user is resource-intensive. As users grow, maintaining separate connections creates performance bottlenecks. Distinct connections per user also complicate session management and hurt user experience.

The solution: use the same RBAC source for both control and data planes.

Groups manage access to resources through identity and access control associations. The data plane (Kafka) handles data processing while the control plane manages it. Both planes share RBAC.

Use RBAC From Day One

RBAC should be the default for any Kafka deployment, regardless of maturity. Defining rules once and reusing them reduces overhead and complexity.

Conduktor implements granular RBAC down to the topic level. You can import your existing third-party auth source directly.