An access control list (ACL) defines authorization rules by identifying a principal, the resource it can access, permitted or forbidden operations, and the access source. In Kafka, resources include topics, consumer groups, clusters, transaction identifiers, and delegation tokens. section 9.3.4
Principal P is [Allowed/Denied] Operation O From Host H On Resource R.
Use the ACL statement pattern to reason about who may perform which operation on which resource and from which host. section 9.3.4
Designing Kafka ACLs requires accounting for more than the obvious topic operation:
- Grant producers the operations needed to send records, potentially including topic creation, idempotent writes, and transactional identifiers. section 9.3.4
- Grant consumers read access to data topics, plus permission to commit offsets, operate within consumer groups, and describe metadata. section 9.3.4
- Use exact-name or prefix matching, and remember that deny rules take precedence over allow rules. section 9.3.4
- Treat topic-level authorization as a boundary: a client authorized for a topic can access all data in that topic. section 9.2.3
Producer access for card topics
A producer identity such as User:card-service can receive Write and Create permissions on resources beginning with the CARDS prefix. The kafka-acls utility helps express this policy without manually assembling every low-level permission. section 9.3.4
ACLs are one layer of an enterprise security design. Authentication establishes the principal, ACLs authorize its actions, and TLS or mTLS protects traffic. In a Customer 360 deployment, ACLs govern Kafka Connect and Schema Registry access alongside producer and consumer traffic. section 9.0 section 9.3.6
