...

It is an error to set both security.inter.broker.protocol and inter.broker.protocol.label at the same time. inter.broker.protocol.label will be null by default, which means that PLAINTEXT will be used by default (as is currently the case).

...

Finally, we make it possible to provide different security (SSL and SASL) settings for each protocol label by using a prefix in the config name. For example, if we wanted to set a different keystore for the CLIENT protocol label, we'd use 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 generic config (i.e. ssl.keystore.location) for compatibility and convenience.

ZooKeeper

Version 4 of the broker registration data stored in ZooKeeper would will have protocol labels instead of security protocols in the elements of the endpoints array and would have 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.

{
  	"version": 4,
  	"jmx_port": 9999,
  	"timestamp": 2233345666,
  	"host": "localhost",
  “port”:	"port": 9092,
  	"rack": "rack1",
  	"listener.security.protocol.map": {
		"PLAINTEXT": "PLAINTEXT",
		"SSL": "SSL",
		"SASL_PLAINTEXT": "SASL_PLAINTEXT",
		"SASL_SSL": "SASL_SSL"
	},
  	"endpoints": [
    		"CLIENT://cluster1.foo.com:9092",
    “REPLICATION:		"REPLICATION: //broker1.replication.local:9093”9093",
    “INTERNAL		"INTERNAL_PLAINTEXT: //broker1.local:9094”9094",
		"INTERNAL_SASL://broker1.local:9095"
  ]    	]
}

Protocol

Version 2 of UpdateMetadataRequest would have  a  will be introduced and the elements of the end_points array would also have a protocol_label field instead of security_protocol_type:.

UpdateMetadata Request (Version: 2) => controller_id controller_epoch [partition_states] [live_brokers] 
  controller_id => INT32
  controller_epoch => INT32
  partition_states => topic partition controller_epoch leader leader_epoch [isr] zk_version [replicas] 
    topic => STRING
    partition => INT32
    controller_epoch => INT32
    leader => INT32
    leader_epoch => INT32
    isr => INT32
    zk_version => INT32
    replicas => INT32
  live_brokers => id [listener_security_protocol_map] [end_points] 
    id => INT32
    end_points => port host protocol_label (instead of security_protocol_type)
      port => INT32
      host => STRING
      protocol_label => String
 (instead    of security_protocol_type => INT16)

Client

Protocol labels only exist in the brokers, clients never see them.

...

The changes are mostly mechanical and don't affect public API.

We would also have to change the various authenticator classes to look for security configs for the relevant protocol label before falling back to the generic ones.

As stated previously, clients never see protocol labels and will make metadata requests exactly as before. The difference is that the list of endpoints they get back is restricted to the protocol label of the endpoint where they made the request. In the example above, let's assume that all brokers are configured similarly and that a client sends a metadata request to cluster1.foo.com:9092 and it reaches broker1's 192.1.1.8:9092 interface via a load balancer. The security protocol would be SASL_PLAINTEXT and the metadata response would contain host=cluster1.foo.com,port=9092 for each broker returned.

The exception is ZooKeeper-based consumers. These consumers retrieve the broker registration information from ZooKeeper directly and would have to be updated to map from protocol label to security protocol.

Compatibility, Deprecation, and Migration Plan

...

For users upgrading, they should only use protocol labels once all the brokers and ZooKeeper-based consumers have been upgraded to a version that supports protocol labels.

An important limitation of this proposal is that ZooKeeper-based consumers won't understand protocol labels and hence people who still rely on them won't be able to use this feature. We are in the process of deprecating the old consumers and they don't support newer features like security, so this seems acceptable.

Rejected Alternatives

Rejected Alternatives

1. Instead of adding the listener.security.protocol.map config, we could extend the protocol part of the listener definition to include both the protocol label and security protocol. For example, CLIENT+SASL_PLAINTEXT://192.1.1.8:9092. This is appealing from a clarity perspective (the listeners are fully defined in a single config value), but it may lead to duplication between listeners and advertised.listeners. A way to avoid that issue (at the cost of loss of symmetry) would be for advertised.listeners to only include the protocol label (we can infer the security protocol by looking at the listeners entry with the same protocol label).
2. Assume that listener.security.protocol.map is the same in every broker. The slight benefit in terms of smaller broker registration JSON is not worth the additional operational complexity when it comes to changing the config values in a running cluster (two rolling upgrades would be needed in some simple cases)Implicit It's worth mentioning that the config value should be the same in every broker in the Kafka cluster for it to work as expected. This is also the case for a number of existing Kafka broker configs and since Kafka doesn't support cluster configs at this point, it seems acceptable.
3. Using hard-coded listener domains for internal and replication traffic. The config format is simpler and there's less scope for hard to understand configs. The main disadvantage is that it's a bit too specific and may need to be extended again as more sophisticated use cases appear. The current proposal is more general and it seems like a natural evolution of the existing system.

...