A checkout service needs to record purchases, but it should not gain access to every Kafka topic. Authentication identifies the client when it connects to a broker; authorization determines which actions that authenticated principal may perform. Give each service only the permissions it needs. section 13.2 section 13.2.3
Kafka access control lists (ACLs) express permissions as rules for a principal, an operation, and a resource. A rule allows or denies an action on a named resource or one matching a prefix; it can also be restricted to a host. When checking an action, Kafka first allows super-admins, then rejects a matching Deny rule, and then checks for an Allow rule. Kafka includes an ACL authorizer; some providers also offer role-based access control. section 13.2.3
Table 13.2 Kafka ACLs structure
| Component |
Options |
Examples |
|---|---|---|
| Principal |
|
|
| Resource type |
|
|
| Pattern type |
|
|
| Resource name |
|
|
| Operation |
|
|
| Permission type |
|
|
| Host |
|
|
Use the ACL fields to check exactly who may perform which operation on which resource, and whether the rule applies to one name, a prefix, or a particular host. section 13.2.3
Permissions for an online checkout
Grant the checkout service Write on checkout.changelog. Grant the payment-processing service Read on that topic and Read on its payment-processor consumer group. A checkout-analytics service using Kafka Streams needs Read on checkout.changelog and permissions on topics beginning checkout.analytics.* because it manages internal topics. These are distinct service needs, not a reason to grant blanket access. section 13.2.3
Automate ACL management rather than maintaining permissions by hand. Monitor unauthorized-access signals alongside authentication and encryption: access rules control permitted operations, while encryption addresses different risks. In a data mesh, data owners can decide which departments or partners receive access to their data products. section 13.2.3 section 15.5.6 section 18.1.4
