kafka KRaft SASL_SSL

### Kafka KRaft Mode Configuration with SASL_SSL Security Protocol In configuring a Kafka cluster using the KRaft (Kafka Raft) mode alongside the `SASL_SSL` security protocol, several key configurations must be set to ensure secure and reliable operation of the Kafka brokers. The following sections detail these settings. #### Broker Configuration for KRaft Mode For enabling KRaft mode without relying on ZooKeeper, specific properties need adjustment within each broker's configuration file (`server.properties`). These changes facilitate direct management by controllers embedded within the Kafka nodes themselves: - **Enable Controller Quorum**: Set `process.roles=broker,controller`. This allows the node to act both as a broker and partake in leader election processes among controllers. - **Controller Quorum Listener Setup**: Define listeners specifically designated for inter-controller communication via `listener.names=CONTROLLER,SASL_SSL`. - **Inter-Broker Communication Settings**: Ensure that all communications between brokers occur over SSL/TLS secured channels through setting up appropriate listener names like `listeners=SASL_SSL://:9093`, where port numbers can vary based on deployment requirements. - **Security Protocols Specification**: Specify protocols used across different types of connections such as client-broker or controller-to-controller interactions under `security.inter.broker.protocol=SASL_SSL`. ```properties # Example server.properties snippet for KRaft setup process.roles=broker,controller node.id=<unique_node_id> controller.quorum.voters=<comma_separated_list_of_controller_nodes> listener.security.protocol.map=PLAINTEXT:PLAINTEXT,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL,SSL:SSL,CONTROLLER:SSL listeners=SASL_SSL://localhost:9093,CONTROLLER://localhost:9094 advertised.listeners=SASL_SSL://<external_ip>:9093 sasl.enabled.mechanisms=SCRAM-SHA-512 inter.broker.listener.name=SASL_SSL security.inter.broker.protocol=SASL_SSL ``` #### Configuring SASL_SSL Authentication Mechanism To enforce strong authentication while maintaining encrypted transport layers, configure the `SASL_SSL` mechanism appropriately: - **Mechanism Selection**: Choose mechanisms supported by your environment; SCRAM is commonly recommended due to its robustness against common attacks compared to PLAIN text methods[^1]. - **JAAS Configuration File**: For clients connecting securely, provide JAAS files specifying credentials necessary for authenticating users attempting access to topics hosted on this cluster. ```java // Sample Java code demonstrating how applications might connect using SASL_SSL Properties props = new Properties(); props.put("bootstrap.servers", "host1.example.com:9093"); props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); // Enable SASL/SSL props.put("security.protocol", "SASL_SSL"); props.put("sasl.mechanism", "SCRAM-SHA-512"); props.put("sasl.jaas.config", "org.apache.kafka.common.security.scram.ScramLoginModule required username=\"admin\" password=\"password\";"); ``` By adhering closely to these guidelines when deploying Kafka clusters configured for KRaft operations combined with stringent security measures enforced through `SASL_SSL`, administrators gain enhanced control over their messaging platforms' integrity and confidentiality aspects. --related questions-- 1. How does one migrate an existing Kafka cluster from ZooKeeper-based architecture to KRaft? 2. What are best practices regarding securing Kafka deployments beyond just implementing SASL_SSL? 3. Can you explain more about choosing between various SASL mechanisms available in Kafka? 4. In what scenarios would it make sense not to use encryption at rest even though network traffic uses SASL_SSL?