In a KRaft cluster, controllers must use a separate listener named in controller.listener.names, and it cannot be the same as the inter-broker listener. Clients do not use it, so isolate it at the network level and secure it with a protocol such as SASL_SSL, even on brokers that do not run the controller role.
What the controller listener does
KRaft clusters have servers with the broker role, the controller role or both, set in process.roles. The Kafka documentation says controllers receive requests from other controllers and from brokers. The listener in inter.broker.listener.name is used exclusively for requests between brokers, while controllers use a separate listener from controller.listener.names. The two settings cannot have the same value.
An easy to miss point: a server that is only a broker still must define the controller listener and its security properties, because it talks to the controllers. It does not list it in listeners, since it does not expose the controller listener itself.
Example from the documentation
For a standalone broker, the Kafka docs show settings along these lines:
process.roles=broker
listeners=BROKER://localhost:9092
inter.broker.listener.name=BROKER
controller.quorum.bootstrap.servers=localhost:9093
controller.listener.names=CONTROLLER
listener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL
For servers that have both roles, the controller listener must also be included in listeners. Whichever layout you use, the host and port in controller.quorum.bootstrap.servers must route to the exposed controller listeners.
Why isolate it
The documentation says the controller listener should be isolated, since clients do not work with it anyway. Clients connect to the other listeners on a broker, and requests that need the controller are forwarded for them. So there is no client reason for a controller port to be reachable from application networks.
The controller quorum holds cluster metadata and makes decisions about it. A path that lets the wrong party speak to it is a path into the control plane, not just a path to one topic.
| Listener | Who should reach it |
|---|---|
| Client listener | Application networks |
| Inter-broker listener | Other brokers |
| Controller listener | Controllers and brokers |
The third row follows from the documentation's description of who sends requests to controllers.
Steps
- List every node, its process.roles and its listeners. Draw which node talks to which.
- Confirm controller.listener.names differs from inter.broker.listener.name on every server.
- Set a real protocol for the controller listener in listener.security.protocol.map. See Is Kafka inter-broker traffic encrypted by default? for why defaults are not enough.
- Write firewall or security group rules so the controller port accepts connections only from brokers and controllers.
- From an application host, confirm the controller port is unreachable.
- Review changes. Port changes are easy to make during troubleshooting, so keep the rules in code.
Changing listeners without downtime
The documentation notes you can define more than one controller listener. That gives you a way to move from one port or security protocol to another with a roll of the cluster: one roll to expose the new listener, and one to remove the old one. When there are several, the first in the list is used for outbound requests. Use this to retire a plaintext controller listener without a hard cutover.
Safeguard's policies and gates can check configuration changes before they merge, and the free scan shows your dependency inventory.
Quick check
Can the controller and inter-broker listeners share a port and name?
No. The documentation says controller.listener.names cannot be set to the same value as the inter-broker listener.
Do pure brokers need controller security settings?
Yes. They must define the controller listener and its security properties because they send requests to controllers, though they do not expose it.
Sources
Last reviewed: 19 October 2026.
