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-group

Pattern 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 prefixed

This 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-customers

The 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.

Technical guides for platform engineers

Why Your YARN Containers Keep Getting OOM-Killed

Kafka ACL Patterns That Actually Work in Production