11.4 Security updates without downtime

"Kafka deployments need regular maintenance to rotate secrets, apply security fixes, and update to the latest security protocols. Many of these are performed using rolling updates... Some tasks like updating SSL key stores and trust stores can be performed using DYNAMIC CONFIG UPDATES WITHOUT RESTARTING BROKERS."

PLAINTEXT → SASL_SSL (add a listener, migrate, remove)

1. Add a new listener on a New port to each broker using the configs tool. “Use A single config update command to update listeners And advertised.listeners to include the Old listener as well as the New listener, and provide all the configuration options for the new SASL_SSL listener With the listener prefix.”
2. Modify all client applications to use the new SASL_SSL listener.
3. If inter-broker communication is being updated, perform a Rolling update of brokers with the new inter.broker.listener.name.
4. Use the configs tool to Remove the old listener from listeners and advertised.listeners, and remove unused options of the old listener.

The key idea: two listeners coexist during the migration, so clients migrate at their own pace. No flag day.

PLAIN → SCRAM-SHA-256 (same listener port, five steps)

1. Add all existing users to the SCRAM store using the configs tool.
2. Set sasl.enabled.mechanisms=PLAIN,SCRAM-SHA-256, configure listener.name.<name>.scram-sha-256.sasl.jaas.config, and perform a Rolling update.
3. Modify all client applications: sasl.mechanism=SCRAM-SHA-256 and update sasl.jaas.config to use SCRAM.
4. If the listener is used for inter-broker communication, Rolling update to set sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256.
5. Rolling update to Remove the PLAIN mechanism: set sasl.enabled.mechanisms=SCRAM-SHA-256 and remove listener.name.<name>.plain.sasl.jaas.config and any other PLAIN options.

Note the shape: enable both → migrate clients → migrate inter-broker → remove the old. Same pattern as the listener migration, one level down.

---