Kafka application consumer code fails with auth_bytes

[ganeshtp]

Hi ,

I was using Kafka-python version 2.0.3. I got an application written to consume a message and that worked without issue. Now when i upgraded to the latest version 2.2.7 version of Kafka-python, the same application fails with error "ValueError: Unexpected receive auth_bytes after sasl/gssapi completion"

I have mentioned (2,2,6) as api version in my consumer application code but still it fails.

How to resolve this issue? Is there any configuration change that needs to be added in code? Any workaround to make the existing application work with the latest version of Kafka-python?

Regards,
Ganesh

[dpkp]

The SASL authentication system was updated between 2.0.3 and 2.2.7, and you may be hitting a bug in one of the new plugins. Can you share your consumer sasl configuration (sasl_mechanism etc)? It would also be helpful if you could share debug logs of the connection failure.

[ganeshtp]

My apologies for not able to respond immediately to your query.
The following is the code :-
topic = "test_topic"
sasl_mechanism = "GSSAPI"
username = "username"
password = "password"
security_protocol = "SASL_SSL"

consumer = KafkaConsumer(topic, bootstrap_servers='KAFKA_BROKER_HOST:9093',
                          security_protocol=security_protocol,
                          ssl_check_hostname=True,
                          sasl_mechanism = sasl_mechanism,
                          sasl_kerberos_domain_name='KAFKA_BROKER_HOST',
                          auto_offset_reset='earliest',
                          enable_auto_commit=False,
                          sasl_plain_username = username,
                          sasl_plain_password = password)

I have attached the debug logs.

debug_logs_kafka_python229.txt

Please let me know if you need more information

[SeppMe]

I have the same problem and did some debugging, finding the direct cause - but not a fix.

In SaslMechanismGSSAPI.receive, the last part after the else is supposed to build the final message we want to send to the server, when the _client_ctx is complete but SaslMechanismGSSAPI is not done, yet. However, that part is never entered, and the message never sent, because auth_bytes gets called by BrokerConnection._sasl_authenticate before receive has a chance to do its work. As a result, SaslMechanismGSSAPI is already set to done, when receive gets called, and we end up in the elif branch, that raises the error, because we think we are done, but we actually are not done, yet.

The old SASL authentication was structured like this (pseudo-code):

while not client_ctx.complete:
    create_next_token()
    send_next_token()
    receive_answer()

create_last_message()
send_last_message()

Those last two steps do not happen after the refactor in version 2.1.0. To fix that, one has to untangle the interactions between SaslMechanismGSSAPI and BrokerConnection. I could probably do that, but only in a way that effectively undoes the new SASL mechanism, thus I must pass the ball to someone who is more familiar with the intent behind the refactor.

[dpkp]

Thanks! I dont have a good gssapi test setup, but from this it looks like client_ctx.complete is set on the final create_next_token() step. The current code assumes that client_ctx.complete is set on the final receive_answer(). The fix for this should be pretty easy (doesn't require changing the connection / sasl plugin interface).