Most Kafka ACL guides show you how to grant a single user access to a single topic. That's fine for learning, but production ACL management at scale requires patterns.
Pattern 1: Service Account per Application
Every application gets its own service account. No sharing. This makes audit trails meaningful and revocation surgical.
kafka-acls --bootstrap-server kafka:9092 \
--add --allow-principal User:app-orders \
--operation Read --operation Write \
--topic orders --group orders-consumer-groupPattern 2: Prefix-Based ACLs
Use topic naming conventions and prefix ACLs to grant access to topic families:
kafka-acls --bootstrap-server kafka:9092 \
--add --allow-principal User:analytics-team \
--operation Read \
--topic analytics- --resource-pattern-type prefixedThis grants read access to all topics starting with analytics- without needing per-topic ACLs.
Pattern 3: Deny-First for Sensitive Topics
For PII or regulated data topics, start with a deny-all and whitelist specific principals:
# Deny all first
kafka-acls --bootstrap-server kafka:9092 \
--add --deny-principal User:* \
--operation All --topic pii-customers
# Then allow specific services
kafka-acls --bootstrap-server kafka:9092 \
--add --allow-principal User:gdpr-service \
--operation Read --topic pii-customersThe Matrix Approach
Maintain your ACLs in a YAML matrix and apply them via automation. Manual kafka-acls commands don't scale past 10 topics.
acls:
- principal: app-orders
topics: [orders, orders-dlq]
operations: [Read, Write]
groups: [orders-cg]
- principal: analytics-team
topics_prefix: analytics-
operations: [Read]
groups_prefix: analytics-This is what the Kafka Security course on AiOpsOne teaches in the ACL module.