Denied Operation is getting triggered in node-rdkafka with incorrect principal

[saravanavel891]

Environment Information
OS : Linux
Node Version: 14.21.3
node-rdkafka version: 2.10.1

Description
System having two kerberos token established for different purpose.

• KAFKA_PRINCIPAL_ID - Connect to Kafka for messaging related purpose
• CACHE_PRINCIPAL_ID - Connect to Hazlecast Cache

In kafka configuration we have provided the kafka principal and details as per below kafka configuration. When we publish a message to topic it is getting published successfully using the KAFKA_PRINCIPAL_ID, but some time it is trying to connect to the topic using CACHE_PRINCIPAL_ID instead of KAFKA_PRINCIPAL_ID and it is getting denied with below Error.

The "node-rdkafka" is a NodeJS client for Apache Kafka that wraps the native librdkafka library. So I would like to know if there is a configuration that we are missing for this issue.

I appreciate any help one this.

Error

INFO Principal = User:CACHE_PRINCIPAL_ID is Denied Operation = Describe from host = **** on resource = Topic:LITERAL:TOPIC_NAME for request = Metadata with resourceRefCount = 1 (kafka.authorizer.logger)

kafka Configuration
{
"sasl.mechanism": "GSSAPI",
"sasl.kerberos.principal": "KAFKA_PRINCIPAL_ID",
"sasl.kerberos.service.name": "kafka",
"sasl.kerberos.keytab": "MY_KAFKA_KEYTAB",
"sasl.kerberos.kinit.cmd": "kinit -V -R -t "%{sasl.kerberos.keytab}" -k %{sasl.kerberos.principal} || kinit -V -t "%{sasl.kerberos.keytab}" -k %{sasl.kerberos.principal}",
"sasl.kerberos.min.time.before.relogin": 90000,
"security.protocol": "sasl_plaintext",
}

[rolandyoung]

Is there any way you can persuade the Hazelcast authentication to use a separate Kerberos cache? I'm fairly sure that Kerberos will get confused if the cache contains tokens for more than principal, so I'm guessing that the Kafka authentication works only until your process authenticates with Hazelcast, at which point the token-granting-token for KAFKA_PRINCIPAL_ID gets replaced by one for CACHE_PRINCIPAL_ID. You could confirm this by using klist to check the content of the Kerberos cache at various points (as long as you can somehow get your program hold off authentication with Hazelcast for a bit.)
Ideally, librdkafka would allow you to specify the Kerberos cache, but I can't see any such config option, so you will have to see if anything similar exists for Hazelcast.
Alternatively, could you use the same principal for both mechanisms? What you are asking Kerberos to do is a little like expecting Windows to be able to allow a user logged on as Alice to connect to shared drives as Alice but to authenticate to a database as Bob - it's impossible in Windows and only possible in Kerberos if you can persuade it to use a separate token cache for each identity.