How do SASL authentication and TLS encryption protect Kafka cluster communications, and what configuration options are typically used?

How do SASL authentication and TLS encryption protect Kafka cluster communications, and what configuration options are typically used?

• A. TLS encrypts data in transit; SASL authenticates clients and brokers only for internal services; configure basic listeners.
• B. SASL authenticates clients and brokers; TLS is optional and not used.
• C. TLS encrypts data in transit and SASL provides authorization for topic creation only.
• D. SASL authenticates clients and brokers (e.g., PLAIN, SCRAM, GSSAPI); TLS encrypts in transit; configure listeners, inter.broker.protocol, security.inter.broker.protocol, ssl.keystore/truststore, and sasl.enabled.mechanisms.

Answer: (D)

In Kafka, protecting communications relies on pairing encryption with authentication. TLS keeps all data in transit confidential and tamper-evident between clients and brokers and between brokers themselves. SASL handles authentication, letting clients and brokers prove who they are before any messages are exchanged. Together, they ensure both privacy and verified identities across the cluster; you can require that all inter-party communication uses encrypted channels and valid credentials. Typical configuration options include: - listeners (and advertised.listeners) to expose endpoints that use the desired security protocol, such as SASL_SSL for client connections or SSL for TLS-only. - security.inter.broker.protocol to define how brokers talk to each other (for example SSL or SASL_SSL). - ssl.keystore.* and ssl.truststore.* properties so brokers have certificates to present and to trust other brokers or clients. - sasl.enabled.mechanisms to specify which SASL methods are allowed (for example PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, GSSAPI), with sasl.jaas.config for the authentication module configuration. This setup provides both encrypted transport and robust authentication, which is why it’s the correct approach. Choices that imply TLS is optional or that SASL covers only topic-creation authorization overlook the full scope of encryption and authentication used in Kafka, or misstate what SASL actually does.

In Kafka, protecting communications relies on pairing encryption with authentication. TLS keeps all data in transit confidential and tamper-evident between clients and brokers and between brokers themselves. SASL handles authentication, letting clients and brokers prove who they are before any messages are exchanged. Together, they ensure both privacy and verified identities across the cluster; you can require that all inter-party communication uses encrypted channels and valid credentials.

Typical configuration options include:

• listeners (and advertised.listeners) to expose endpoints that use the desired security protocol, such as SASL_SSL for client connections or SSL for TLS-only.

• security.inter.broker.protocol to define how brokers talk to each other (for example SSL or SASL_SSL).

• ssl.keystore.* and ssl.truststore.* properties so brokers have certificates to present and to trust other brokers or clients.

• sasl.enabled.mechanisms to specify which SASL methods are allowed (for example PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, GSSAPI), with sasl.jaas.config for the authentication module configuration.

This setup provides both encrypted transport and robust authentication, which is why it’s the correct approach. Choices that imply TLS is optional or that SASL covers only topic-creation authorization overlook the full scope of encryption and authentication used in Kafka, or misstate what SASL actually does.