TLS, SASL and ACLs

Kafka · lesson 24 of 34 · 4 min read

Lock a cluster down: encrypt the wire, authenticate the client, then authorise every topic.

Open this lesson in the learning hub

Key points

  • Three layers: encryption (TLS), authentication (SASL or mTLS) and authorisation (ACLs). One is not the others.
  • SASL_SSL with SCRAM-SHA-512 is the usual pick: password auth over TLS, users stored in the cluster.
  • ACLs are per principal, resource and operation. With allow.everyone.if.no.acl.found=false, unlisted means denied.
  • A consumer needs READ on the topic and READ on its group. Forgetting the group ACL is the classic first failure.
  • Give every service its own principal. Shared credentials make rotation impossible and turn any audit into guesswork.
  • Encryption in transit is not encryption at rest. Data on the broker disk is plaintext unless you encrypt the payload or the volume.

Example

# ---- broker ----
listeners=SASL_SSL://:9093
security.inter.broker.protocol=SASL_SSL
sasl.enabled.mechanisms=SCRAM-SHA-512
authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer
allow.everyone.if.no.acl.found=false
super.users=User:admin

# ---- client ----
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
ssl.truststore.location=/etc/kafka/truststore.jks
# sasl.jaas.config comes from a secret, never from a checked-in file

# ---- ACLs: the topic AND the group, or it fails ----
# kafka-acls.sh --bootstrap-server localhost:9093 --add \
#   --allow-principal User:billing-svc \
#   --operation Read --topic orders --group billing-service

Encrypt, authenticate, authorise. Deny by default, and one principal per service.

Kafka Connect and CDC Testing Kafka Code

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the Kafka course, and every lesson in it is listed on the Kafka contents page.