What roles do TLS and SASL play in securing Kafka?

TLS and SASL are complementary security mechanisms that operate at different layers. TLS (Transport Layer Security) provides encryption and integrity for data in transit between clients and brokers, and between brokers. It ensures that data cannot be read or tampered with on the network. TLS can also provide authentication via mutual TLS (mTLS), where both the client and the broker present certificates and verify each other's identity. SASL (Simple Authentication and Security Layer) is a framework for authentication mechanisms. It does not provide encryption by itself; it provides a way for a client to prove its identity to the broker. In Kafka, SASL is typically used over a TLS connection, which is why you see listener names like SASL_SSL. The combination gives you both encryption and authentication. SASL_PLAINTEXT exists but should only be used in isolated test environments because credentials and data are sent in the clear.

The mechanism matters because the two solve different problems. TLS is about the channel: it protects data from eavesdropping and tampering, and with mTLS it can authenticate the client based on its certificate. SASL is about the identity: it defines how the client proves who it is. Kafka supports several SASL mechanisms: SCRAM-SHA-256 and SCRAM-SHA-512 use username/password with a challenge-response protocol; GSSAPI uses Kerberos; OAUTHBEARER uses OAuth 2.0 tokens; PLAIN sends username/password in clear text and must only be used over TLS. The choice of mechanism depends on your identity infrastructure. If you already have Kerberos, GSSAPI is a natural fit. If you use OAuth, OAUTHBEARER integrates with your identity provider. SCRAM is a good general-purpose choice because it does not require external infrastructure and the credentials are stored in Kafka itself. mTLS is another option, where the client certificate's subject becomes the principal. Each has trade-offs: Kerberos is complex to operate; OAuth requires a token service; SCRAM requires managing credentials in Kafka; mTLS requires a PKI.

A common mistake is to use SASL_PLAINTEXT with PLAIN in production, which exposes credentials on the network. Another mistake is to use TLS without verifying certificates, which defeats the purpose of mTLS. A third mistake is to assume that TLS alone provides authorization; it does not. TLS and SASL provide authentication and encryption, but authorization is a separate concern handled by ACLs. The trade-off is between security and operational complexity. TLS adds CPU overhead for encryption and requires certificate management, including rotation and revocation. SASL adds a handshake and, depending on the mechanism, may require external infrastructure. The most common production configuration is SASL_SSL with SCRAM or GSSAPI, which gives encryption and strong authentication. Version note: TLS versions and cipher suites are configurable via ssl.enabled.protocols and ssl.cipher.suites; older TLS versions should be disabled. Kafka 3.x supports TLS 1.3. Always check the version and your organization's security requirements when choosing protocols and mechanisms.