Introduction

Kafka security is not one feature. It is a stack of decisions about transport encryption, client authentication, broker-to-broker trust, and authorization. A cluster is not meaningfully secure if only one of those layers is configured while the others are left open.

For most modern deployments, the baseline is straightforward: use TLS for encryption in transit, use SASL or mutual TLS for authentication, and use ACLs or a higher-level authorization layer to control who can read, write, or administer resources.

Start With Transport Encryption

The first step is encrypting traffic between clients and brokers, and often between brokers themselves. In Kafka configuration this is typically done with SSL or SASL over SSL listeners.

A broker-side example:

1listeners=SASL_SSL://broker1.example.com:9093
2advertised.listeners=SASL_SSL://broker1.example.com:9093
3
4ssl.keystore.location=/etc/kafka/broker1.keystore.jks
5ssl.keystore.password=changeit
6ssl.key.password=changeit
7ssl.truststore.location=/etc/kafka/broker1.truststore.jks
8ssl.truststore.password=changeit

A matching client configuration might look like:

security.protocol=SASL_SSL
ssl.truststore.location=/etc/kafka/client.truststore.jks
ssl.truststore.password=changeit

TLS protects credentials and message data in transit. Without it, mechanisms such as SASL/PLAIN expose secrets to the network.

Choose an Authentication Mechanism

Kafka supports several authentication approaches. The most common choices are:

• SASL/SCRAM for username and password with hashed credentials
• SASL/PLAIN for simple setups, but only with TLS
• SASL/GSSAPI for Kerberos environments
• mTLS when client certificates are part of the trust model

For example, a client using SCRAM over TLS:

1security.protocol=SASL_SSL
2sasl.mechanism=SCRAM-SHA-512
3sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
4  username="app-user" \
5  password="strong-secret";
6ssl.truststore.location=/etc/kafka/client.truststore.jks
7ssl.truststore.password=changeit

PLAIN is easier to configure, but it should not be used without TLS because the credentials are otherwise exposed.

Add Authorization With ACLs

Authentication tells Kafka who the client is. Authorization decides what that client is allowed to do.

Kafka ACLs are a common built-in authorization mechanism. A modern ACL command targets brokers with --bootstrap-server:

1bin/kafka-acls.sh \
2  --bootstrap-server broker1.example.com:9093 \
3  --command-config admin.properties \
4  --add \
5  --allow-principal User:app-user \
6  --operation Read \
7  --topic orders

A separate rule might allow consumer group access:

1bin/kafka-acls.sh \
2  --bootstrap-server broker1.example.com:9093 \
3  --command-config admin.properties \
4  --add \
5  --allow-principal User:app-user \
6  --operation Read \
7  --group orders-consumer

Least privilege matters here. A client that only needs to read one topic should not be granted broad cluster permissions.

Secure Both Client and Inter-Broker Paths

Many teams focus on client-to-broker security and forget that broker-to-broker traffic also needs a trust model. Replication traffic, controller communication, and internal cluster operations are still part of the attack surface.

That means you should decide:

• what listener each client class should use
• which protocol brokers use among themselves
• whether internal and external listeners are separated

Keeping internal and external listeners separate is a common pattern because it lets you apply different network and authentication policies at each boundary.

Operational Security Matters Too

Security is not only configuration syntax. It is also how you operate the cluster:

• rotate credentials and certificates
• audit ACL changes
• avoid sharing admin principals with application workloads
• keep client and broker configs out of logs and source control

Mismanaged secrets can undo a technically correct Kafka configuration very quickly.

Common Pitfalls

The biggest mistake is enabling SASL/PLAIN without TLS. That protects neither the credentials nor the message traffic.

Another common issue is configuring secure listeners on brokers but leaving clients on plaintext listeners out of convenience. Security only helps if the actual production path uses it.

People also overgrant ACLs, especially during debugging, and never tighten them later. Temporary broad access has a way of becoming permanent.

Finally, do not copy older ZooKeeper-era admin commands blindly into modern clusters. Prefer the current broker-facing admin flows and verify the command syntax against the Kafka version you run.

Summary

• Kafka security combines encryption, authentication, and authorization.
• Use TLS or SASL over TLS as the transport baseline.
• Choose an authentication mechanism that fits your environment, commonly SCRAM, PLAIN with TLS, Kerberos, or mTLS.
• Enforce least privilege with ACLs or an equivalent authorization layer.
• Secure internal broker communication and operational secrets, not just external clients.