Overview ACL
Access to a Kafka database is controlled in two independent steps, and confusing them is the usual reason an application connects successfully and then fails on every operation.
| Step | What it does | Without it |
|---|---|---|
| Kafka user | Authenticates the client to the database over SASL | The client cannot connect at all |
| ACL | Authorizes that user on specific topics and consumer groups | The client connects and can access nothing |
Producers, consumers, and Kafka Connect each authenticate as a Kafka user. This feature applies to the Kafka engine only.
A Kafka user with no ACL has access to nothing. Grant an ACL after creating the user.
SASL mechanisms
A user is created with one of three mechanisms: PLAIN, SCRAM-SHA256, or SCRAM-SHA512. The choice is not only about strength.
Creating or updating a user with SASL/PLAIN restarts the Kafka database, which disrupts producers and consumers. A SCRAM mechanism does not. Prefer SCRAM, or schedule PLAIN changes for off-peak hours.
What an ACL can grant
ACLs apply at database level and take effect immediately, with no restart. Each one names a resource type, a prefix, and the operations permitted on it. A single user can hold several.
For Topic:
| Operation | Grants |
|---|---|
| All | Every operation on the topic. |
| Alter | Editing DANGER parameters of the topic in Kafka UI. |
| AlterConfigs | Editing non-DANGER parameters of the topic in Kafka UI. |
| Read | Reading topic content. |
| Write | Writing data to the topic. |
For Consumer group:
| Operation | Grants |
|---|---|
| Delete | Deleting the group. |
| Describe | Viewing group details. |
| Read | Reading group content. |
The prefix decides reach. Entering All covers every topic or every consumer group; any other value covers the resources whose name starts with it.
Working safely
- Create one user per application or service, so you can revoke access without affecting others.
- Grant by prefix rather than per resource. Prefix ACLs keep working as topics multiply.
- Keep producer and consumer permissions on separate users where your architecture allows it.
- Grant All only where you have a specific reason.
- Rotate passwords periodically, and review the ACL list to remove what applications no longer use.
- Avoid creating users during peak hours, because a PLAIN mechanism triggers a restart.
Next steps
- Configure ACL to create a user and grant it permissions
- Configure NAT for Kafka to reach the database from outside the VPC
- View Action Logs to see who changed what