Piotr Smolinski created KAFKA-15814:
---------------------------------------
Summary: SASL Kerberos authentication cannot be used with load
balanced bootstrap
Key: KAFKA-15814
URL: https://issues.apache.org/jira/browse/KAFKA-15814
Project: Kafka
Issue Type: Bug
Components: core, security
Affects Versions: 3.6.0
Reporter: Piotr Smolinski
Actually it is a very old problem still unresolved. When access to Kafka is
done over load balanced bootstrap (like in Kubernetes, or when the number of
brokers is inpractical to enlist them in the bootstrap, or when we want to give
a single access address), the broker endpoint can be accessed using at least
two addresses: one for connection bootstrap (load balanced) and another one for
broker connection (direct). The problem is that Kafka Kerberos configuration
forces JAAS to use only one SPN (like kafka/b-0.kafka@DOMAIN). In weaker
algorithms (like RC4) the same keytab entry can be used for multiple server
names. The problem arises when we use stronger algorithms (like AES128 or
AES256), the SPN is used to compute the messages and keytab entries for
kafka/b-0.kafka@DOMAIN and kafka/kafka@DOMAIN are not compatible.
JAAS configuration for Kerberos can be specified in two ways depending whether
we are using it for service client or server:
{code:java}
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/etc/kafka/security/kafka.keytab"
principal="kafka/node-0.kafka.home.arpa@LOCALDOMAIN"
; {code}
{code:java}
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
keyTab="/etc/kafka/security/kafka.keytab"
principal="*"
isInitiator=false
; {code}
While the former one can be used on both sides, it forces only one principal to
be selected from the keytab. The latter form cannot be used on the client side,
but it dynamically selects the correct SPN based on the client request.
Kafka Kerberos implementation does not distinguish between client and server
property. In particular the same JAAS configuration entry is used when the
broker uses Kerberos for inter-broker communication.
Even if the listener property in the broker is known to be not used, the code
currently does not allow to specify wildcard principal.
Some time ago I have created a patch that solves the problem preserving the
current semantics, but I did not have time to describe the submission. This
ticket is a tracker for the Pull Request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
