[jira] [Created] (KAFKA-15814) SASL Kerberos authentication cannot be used with load balanced bootstrap

["Piotr Smolinski (Jira)" <ji...@apache.org>]

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)