hachikuji commented on a change in pull request #11503:
URL: https://github.com/apache/kafka/pull/11503#discussion_r760634593



##########
File path: core/src/main/scala/kafka/server/KafkaConfig.scala
##########
@@ -1960,9 +1962,16 @@ class KafkaConfig private(doLog: Boolean, val props: 
java.util.Map[_, _], dynami
   }
 
   def listenerSecurityProtocolMap: Map[ListenerName, SecurityProtocol] = {
-    getMap(KafkaConfig.ListenerSecurityProtocolMapProp, 
getString(KafkaConfig.ListenerSecurityProtocolMapProp))
+    val mapValue = getMap(KafkaConfig.ListenerSecurityProtocolMapProp, 
getString(KafkaConfig.ListenerSecurityProtocolMapProp))
       .map { case (listenerName, protocolName) =>
-      ListenerName.normalised(listenerName) -> 
getSecurityProtocol(protocolName, KafkaConfig.ListenerSecurityProtocolMapProp)
+        ListenerName.normalised(listenerName) -> 
getSecurityProtocol(protocolName, KafkaConfig.ListenerSecurityProtocolMapProp)
+      }
+    if (usesSelfManagedQuorum && 
!originals.containsKey(ListenerSecurityProtocolMapProp)) {
+      // Nothing was specified explicitly, so we are using the default value;
+      // therefore, since we are using KRaft, add the CONTROLLER:PLAINTEXT 
mapping
+      mapValue ++ Map(new ListenerName("CONTROLLER") -> 
SecurityProtocol.PLAINTEXT)

Review comment:
       The default mapping here doesn't do us any good unless it corresponds to 
one of the values in controller.listener.names, no?
   
   > What if someone names their controller listener SSL ?
   
   Interestingly, the logic we use today allows for this explicitly. Here is 
how we currently determine the security protocol in 
`BrokerToControllerChannelManager`. 
   
   ```scala
       val controllerSecurityProtocol = 
config.listenerSecurityProtocolMap.getOrElse(controllerListenerName, 
SecurityProtocol.forName(controllerListenerName.value()))
   ```




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to