TL;DR
The current setup works because it provides a fallback KafkaServer section in the broker_jaas.conf file where it should only use the listener-scope properties.
When providing a listener scoped JAAS config (like listener.name.internal.plain.sasl.jaas.config for instance) Kafka will 1st search for a listener.name.internal.sasl.enabled.mechanisms. If the listener-scoped mechanism is not found then Kafka will try to load the information from the java.auth.file (here brokerjaas.conf) looking for first for a internal.KafkaServer section or falling back to KafkaServer.
Combining both a KafkaServer section and a listener-scoped jaas config is kind of fishy... For instance, the credentials defined for the `user` principals are not used at all in cp-demo (overridden by the one in the inlined jaas config property).
Description This issue refers the following discussion https://confluent.slack.com/archives/C60B5SJ1E/p1622746349449000
TL;DR The current setup works because it provides a fallback
KafkaServersection in the broker_jaas.conf file where it should only use the listener-scope properties.When providing a listener scoped JAAS config (like
listener.name.internal.plain.sasl.jaas.configfor instance) Kafka will 1st search for alistener.name.internal.sasl.enabled.mechanisms. If the listener-scoped mechanism is not found then Kafka will try to load the information from the java.auth.file (here brokerjaas.conf) looking for first for ainternal.KafkaServersection or falling back toKafkaServer. Combining both a KafkaServer section and a listener-scoped jaas config is kind of fishy... For instance, the credentials defined for the `user` principals are not used at all in cp-demo (overridden by the one in the inlined jaas config property).