In this lesson, you will learn how to implement granular security in your Kafka ecosystem by using Access Control Lists (ACLs) to restrict what clients can do with your data streams.
Even after you have secured your cluster with TLS encryption and SASL authentication, your clients—such as Kafka Connect workers or custom producer/consumer applications—might still have too much power. By default, an authenticated user might be able to read from any topic or write to any consumer group. ACLs allow you to follow the "principle of least privilege" by defining specific operational permissions for specific principals.
An ACL entry consists of four primary components: the Principal (who is performing the action), the Operation (what they are trying to do, like READ or WRITE), the Resource (what they are acting upon, such as a TOPIC or GROUP), and the Host (where the request originates).
For example, if you have a sensitive topic named user-transactions, you don’t want your analytics consumer to accidentally write data to it. You can enforce this restriction using the kafka-acls.sh command-line tool:
kafka-acls.sh --bootstrap-server localhost:9092 \
--add \
--allow-principal User:AnalyticsApp \
--operation READ \
--topic user-transactions \
--group analytics-consumers
In this command, you explicitly grant the AnalyticsApp permission to READ from the user-transactions topic and manage the analytics-consumers group. If that same application attempted to perform a WRITE operation on that topic, the Kafka broker would intercept the request and return an "Authorization Failed" error, effectively protecting your data integrity.
By layering ACLs on top of your existing SASL authentication, you ensure that even if a service account is compromised, the blast radius is minimized because the attacker is limited to only the specific topics and actions assigned to that identity. This granular control is essential for multi-tenant environments where production data must remain isolated from downstream consumers.
Key Takeaway: ACLs enable you to enforce the principle of least privilege by mapping authenticated identities to specific, restricted Kafka operations, ensuring that clients can only access the exact data and groups necessary for their function.