skip to content

Authorization and ACLs

3 roadmaps6 questions

Kafka's ACL model: operations crossed with resource types, prefixed and wildcard rules, and deny beating allow. Interviewers often ask you to name the exact ACLs a producer or a consumer group needs.

part ofApache Kafkaoverview, primer and where to startread it →
on this pageshow

explore

questions

6

What is a Kafka ACL, and what are the fields that make up a single ACL binding?

level: juniorimportance: must knowfreq 70%

answer

  1. 5-tuple: principal, operation, resource, permission, host
  2. User:alice
  3. LITERAL vs PREFIXED pattern type
  4. default = deny, DENY wins
  5. kafka-acls.sh / AdminClient

basics

~20 s

An ACL (access control list entry) is a rule saying a principal (user) is allowed or denied a specific operation (like Read or Write) on a resource (like a topic), optionally from a specific host.

solid answer

~40 s

A Kafka ACL is a single authorization rule. It is a 5-tuple: principal (who, e.g. User:alice), operation (Read, Write, Describe, Create, Delete, Alter, etc.), resource pattern (resource type + name + pattern type — LITERAL or PREFIXED), permission type (ALLOW or DENY), and host (the client IP, or * for any). When a client attempts an action, the authorizer collects every ACL matching that principal/resource/operation and decides. ACLs are managed via the kafka-acls CLI or the AdminClient API and stored by the authorizer (the metadata log under KRaft, or ZooKeeper in legacy clusters). Each ACL is purely additive in the ALLOW case but a single matching DENY overrides any ALLOW.

go deeper

for a junior

Know that an ACL grants or denies a principal an operation on a resource, and that the default is deny.

for a middle

Be able to list all five fields including pattern type (LITERAL/PREFIXED) and the host field, and name the common resource types.

for a senior

Explain implicit Describe, where ACLs are stored per authorizer, and how a decision aggregates matching rules.

for a principal

Reason about ACL modeling at scale — naming conventions for principals/topics that keep the ACL set small and auditable.

## What problem ACLs solve Kafka authentication answers "who are you" (via SASL/SSL). Authorization answers "what are you allowed to do". ACLs (Access Control List entries) are the rules that drive authorization. ## The anatomy of one ACL A single ACL binding is conceptually a 5-tuple: 1. **Principal** — the identity, written as `User:alice` (the type is almost always `User`). This is the authenticated name produced by your SASL/SSL mechanism. 2. **Operation** — the action: `Read`, `Write`, `Create`, `Delete`, `Alter`, `Describe`, `ClusterAction`, `DescribeConfigs`, `AlterConfigs`, `IdempotentWrite`, etc. `All` is a wildcard operation. 3. **Resource pattern** — two parts: a **resource type** (`Topic`, `Group`, `Cluster`, `TransactionalId`, `DelegationToken`) plus a **resource name** and a **pattern type** (`LITERAL` for an exact name, `PREFIXED` for a name prefix). The literal name `*` means "all resources of this type". 4. **Permission type** — `ALLOW` or `DENY`. 5. **Host** — the client source IP the rule applies to, or `*` for any host. ## How a decision is made When a client makes a request, the broker's authorizer takes the (principal, operation, resource, host) of the attempt and scans all stored ACLs that match. The default decision is **deny** (nothing matches → denied). If at least one ALLOW matches and no DENY matches, the action is permitted. A matching DENY always wins. ## Where ACLs live and how they're managed You create ACLs with the `kafka-acls.sh` CLI (or programmatically via `AdminClient.createAcls`). The authorizer implementation persists them: `StandardAuthorizer` writes them into the KRaft metadata log; the legacy `AclAuthorizer` stored them in ZooKeeper. ## Edge note Many operations implicitly require `Describe` — for example a producer needs `Write` on a topic, but `Write` also grants implicit `Describe` so the producer can fetch metadata. This is why you often don't need to add `Describe` separately.

  • If no ACL matches a request, what happens by default?
    The request is denied — Kafka authorization is deny-by-default. (A separate config, allow.everyone.if.no.acl.found, can flip that, but that's a defaults concern, not the ACL binding itself.)
  • What does the host field do?
    It restricts an ACL to a specific client source IP. The default and most common value is * (any host). You can scope an ALLOW to a known producer IP for defense in depth.

saying these in an interview costs you the question

  • Saying an ACL is just principal + operation and forgetting resource type, pattern type, permission type, or host.
  • Claiming ACLs default to allow — they default to deny.
  • Confusing authentication (who you are) with authorization (what you can do).

context

resolving links…

open as a page

What ACLs does a basic producer need to write to a topic, and what does a consumer in a consumer group need to read from it?

level: middleimportance: must knowfreq 75%

basics

~10 s

A producer needs Write on the topic. A consumer needs Read on the topic plus Read on its consumer group. Both implicitly get Describe from Write/Read.

open as a page

Explain Kafka's ACL evaluation precedence — how are ALLOW and DENY rules combined, and what happens when both match?

level: seniorimportance: must knowfreq 65%

basics

~10 s

Kafka is deny-by-default: if nothing matches, access is denied. If any matching DENY exists, access is denied even if an ALLOW also matches. An ALLOW grants only when no DENY matches.

open as a page

How do prefixed and wildcard (literal '*') ACLs differ, and how do you create each with kafka-acls?

level: middleimportance: should knowfreq 55%

basics

~20 s

A wildcard ACL uses the literal name '*' to match all resources of a type. A prefixed ACL matches every resource whose name starts with a given prefix. You select prefixed mode with --resource-pattern-type prefixed.

open as a page

Which authorizer class do you configure for ACLs on a modern KRaft cluster versus a legacy ZooKeeper cluster, and how does ACL storage differ?

level: seniorimportance: should knowfreq 45%

basics

~10 s

On KRaft set authorizer.class.name to StandardAuthorizer; on legacy ZooKeeper clusters use AclAuthorizer (formerly SimpleAclAuthorizer). KRaft stores ACLs in the metadata log; ZooKeeper-based authorizers store them in ZooKeeper.

open as a page

Map common Kafka admin and Connect operations to the operation x resource-type ACLs they require (e.g. creating a topic, describing configs, running Streams).

level: principalimportance: nice to knowfreq 35%

basics

~20 s

Different actions map to specific (operation, resource) pairs: creating a topic needs Create on Cluster (or on the Topic prefix), altering topic configs needs AlterConfigs on the Topic, and listing/describing needs Describe on the relevant resource.

open as a page