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).
answer
- ops x resource-type table
- Create on Cluster OR Topic-prefix (KIP-277)
- AlterConfigs vs DescribeConfigs on Topic
- ClusterAction = broker-internal only
- Streams = producer+consumer+Create internal topics
- Describe implied by Read/Write/Alter/Delete
basics
~20 sDifferent 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.
solid answer
~40 sACLs are an operation x resource-type matrix. Examples: creating a topic requires `Create` on the **Cluster** resource, or `Create` on a **Topic** (literal/prefixed) since KIP-277; deleting a topic needs `Delete` on the Topic; changing topic configs needs `AlterConfigs` on the Topic and reading them needs `DescribeConfigs`; listing topics needs `Describe` on each Topic; broker-internal actions (leader/ISR, controlled shutdown, replica fetch) need `ClusterAction` on the Cluster. A Kafka Streams app is a producer+consumer plus it creates internal repartition/changelog topics, so it needs Read/Write on its topics, Read on its Group, and `Create` to make internal topics (or pre-create them and grant Describe). Many read paths get `Describe` implicitly from Read/Write/Alter/Delete, so you rarely grant Describe alone. The discipline at scale is mapping each service archetype to its exact matrix cells and granting nothing more.
go deeper
Know that admin actions like create/delete/alter map to specific operations on Topic or Cluster.
Map the common cases: Create topic, Delete topic, AlterConfigs/DescribeConfigs on Topic, Describe on Group.
Handle the Streams composite and the Create-on-Cluster-vs-prefix tradeoff, plus implicit Describe.
Define per-archetype ACL templates over a naming convention and automate least-privilege provisioning and auditing.
## The matrix mindset Authorization in Kafka is fundamentally a table: rows are **operations** (Read, Write, Create, Delete, Alter, Describe, AlterConfigs, DescribeConfigs, ClusterAction, IdempotentWrite, All) and columns are **resource types** (Topic, Group, Cluster, TransactionalId, DelegationToken). Each API call the broker handles checks one or more (operation, resource) cells. ## Worked mappings **Create a topic:** - `Create` on **Cluster**, OR (since KIP-277) `Create` on the **Topic** name/prefix. Granting Create on a Topic prefix lets a team self-serve topics inside its namespace without cluster-wide create rights. **Delete a topic:** `Delete` on the **Topic**. **Read topic configs / describe configs:** `DescribeConfigs` on the **Topic** (or Cluster/Broker for broker configs). **Change topic configs (retention, etc.):** `AlterConfigs` on the **Topic**. **List/describe topics, partitions, offsets:** `Describe` on the **Topic** — but note Read/Write/Alter/Delete each *imply* Describe, so a producer/consumer already has it. **Consumer group admin:** `Describe` on **Group** to view a group; `Delete` on **Group** to delete it; `Read` on **Group** for normal membership/commit. **Broker/internal protocol:** `ClusterAction` on **Cluster** — used for inter-broker replication, leader-and-ISR, controlled shutdown. Regular clients never need this. **Idempotent / transactional producer:** `IdempotentWrite` on **Cluster** (older brokers) and `Write`/`Describe` on **TransactionalId**. ## Kafka Streams (the composite case) A Streams application is the trickiest because it wears several hats: - **Consumer**: Read on source Topics + Read on the application Group. - **Producer**: Write on sink Topics. - **Internal topics**: Streams auto-creates repartition and changelog topics named `<application.id>-...`. It therefore needs `Create` (cluster or a `<application.id>-` Topic prefix) plus Read/Write/Describe on those internal topics. A common least-privilege pattern: grant `Create`, `Read`, `Write`, `Describe` on PREFIXED `<application.id>-`, and Read on Group `<application.id>`. - **EOS (exactly_once_v2)**: add Write/Describe on TransactionalId (Streams derives transactional ids from the application id). ## Implicit Describe — don't over-grant Because Describe is implied by Read, Write, Alter, and Delete, granting standalone Describe is usually unnecessary and a sign of an over-broad or redundant ACL. Conversely, Describe alone never grants data access. ## Principal-level discipline At org scale, the win is treating each *service archetype* (plain producer, plain consumer, Streams/EOS app, admin tool, broker) as a template of matrix cells, expressed with prefixed ACLs over a strict naming convention, and provisioned by automation — so audits reduce to "does this principal hold exactly its template?"
- Two ways to let a team create its own topics — which is least privilege?Create on Cluster grants cluster-wide topic creation; Create on a PREFIXED Topic (e.g. team-a-) is least privilege, confining self-serve creation to the team's namespace (enabled by KIP-277).
- What ACLs are unique to a Kafka Streams app versus a plain consumer?Beyond Read on source topics + group, Streams needs Create plus Read/Write/Describe on its internal repartition/changelog topics (prefixed by application.id), and TransactionalId Write/Describe under EOS.
- Which operation authorizes inter-broker replication and controlled shutdown?ClusterAction on the Cluster resource. It's for broker-internal protocols and should never be granted to application clients.
saying these in an interview costs you the question
- Granting Create only on Cluster when a prefixed Topic Create would be least privilege.
- Granting ClusterAction to application clients — it's broker-internal.
- Forgetting Streams needs Create + Read/Write on internal (repartition/changelog) topics.
- Adding standalone Describe ACLs that are already implied by Read/Write.
- Confusing AlterConfigs (change configs) with Alter (alter the resource, e.g. partitions/ACLs).