...
As such, we propose that Kafka brokers should be able to define multiple listeners for the same security protocol for binding (i.e. listeners) and sharing (i.e. advertised.listeners) so that internal, external and replication traffic can be separated if required.
Public Interfaces
Broker Configuration
A new broker config listener.security.protocol.map will be introduced so that we can map a protocol label to a security protocol. The config value should be in the CSV Map format that is currently used by max.connections.per.ip.overrides. The config value should follow map semantics: each key should only appear once, but values may appear multiple times. For example, the config could be defined in the following way to match the existing behaviour:
...
Finally, we make it possible to provide different security (SSL and SASL) settings for each protocol label by using adding a prefix in normalised prefix (the security label is lowercased) to the config name. For example, if we wanted to set a different keystore for the CLIENT protocol label, we 'd use would set a config with name protocol.label.client.ssl.keystore.location. If the config for the protocol label is not set, we will fallback to the generic config (i.e. ssl.keystore.location) for compatibility and convenience. For the SASL case, some configs are provided via a JAAS file, which consists of one or more entries. The broker currently looks for an entry named KafkaServer. We will extend this so that the broker first looks for an entry with a lowercased protocol label followed by a dot as a prefix to the existing name. For the CLIENT protocol label example, the broker would first look for client.KafkaServer with a fallback to KafkaServer, if necessary.
ZooKeeper
Version 4 of the broker registration data stored in ZooKeeper will have protocol labels instead of security protocols in the elements of the endpoints array and an additional listener.security.protocol.map field. The latter is not strictly needed if we assume that all brokers have the same config, but it would make config updates trickier (e.g. two rolling bounces would be required to add a new mapping from protocol label to security protocol). Also, we add an additional field instead of changing the endpoints schema to allow for rolling upgrades.
...