Kafka Ports: 9092 (Plain) vs 9093 (Encrypted)
A Kafka broker wires one protocol per port: 9092 plain, 9093 encrypted. There's no upgrade in place. The port you connect to decides the protocol, and aiming wrong just fails.
Quick setup: Kafka is a system for passing events between services, and a broker is one Kafka server. A port is a numbered channel on that server. A broker can listen on several ports at once, and each port is wired to one fixed protocol (for example, plain on 9092, encrypted on 9093).
The part that surprised me: the port you connect to decides the protocol. There’s no “upgrade in place” the way a web address can step from HTTP up to HTTPS on the same connection. Plain and encrypted are just two different doors.
- Internal clients that don’t need encryption connect to
9092and speak plain. - Clients that need encryption connect to
9093and speak encrypted (mutual TLS, with a client certificate). - Aim at the wrong door and the connection fails. Point encrypted settings at the plain
9092door and it breaks at connect time, not as a friendly config error you catch early.
Once you’re on the encrypted door, the Kafka server can also enforce permissions tied to the client certificate’s name: a sender may only write to the topics its certificate is listed for.
In this migration: the whole change was “point the client at 9093 instead of 9092, and tell it to speak encrypted”, done before the platform team turned off the old 9092 door for good.
A Kafka port is not a door you upgrade. The door is the protocol. Pick the right one up front.
References
- https://kafka.apache.org/41/security/listener-configuration/
- https://developer.confluent.io/courses/security/authentication-ssl-and-sasl-ssl/
Related: the encrypted door is mutual TLS, and turning it on is one if in the Kafka client’s SSL config. Back to the overview: two SSLs behind one migration ticket.