Uploaded image for project: 'Kafka'
  1. Kafka
  2. KAFKA-15814

SASL Kerberos authentication cannot be used with load balanced bootstrap

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 3.6.0
    • None
    • core, security
    • Patch

    Description

      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:

      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"
      ; 
      com.sun.security.auth.module.Krb5LoginModule required
        useKeyTab=true
        storeKey=true
        keyTab="/etc/kafka/security/kafka.keytab"
        principal="*"
        isInitiator=false
      ; 

      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.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              psmolinski Piotr Smolinski
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: