Replies: 3 comments
-
Your problem is that Kerberos is a single sign-on mechanism. The advantage of this is that you only have to authenticate once and then you have a ticket-granting token which enables you to connect to multiple services in the authentication domain (realm). But the disadvantage is that you can only authenticate once - you can't use multiple Kerberos identities in a single process, because Kerberos will always use that single ticket-granting token. If you could somehow use two copies of the Kerberos library, with separate ticket caches, you could have two identities, but there is no reasonable way for a client library (such as librdkafka) to support that. |
Beta Was this translation helpful? Give feedback.
-
I'm looking for something similar in environment where I need to impersonate dozens of principals that are configurable by end user of my application. The cost of operating independent copies of application is quite tough when I need produce 1 message per hour for 1 topic. If I have 200 messages with 200 principals, it becomes real pain, and being part of engineers that can't impact on architecture of infrastructure present in my place I have no way to change the way it behaves, but librdkafka could employ graceful handling of KRB5CCNAME env variable like few other similar libraries to allow my use case to function. I raised this Stackoverflow question sometime back and was pretty much told that its the only "real" thread-safe way. |
Beta Was this translation helpful? Give feedback.
-
Hi everyone, I've encountered the same issue and have created this pull request to address it. In my environment, Kafka messages can be sent and received normally across more than three non-mutual trust Kerberos environments. If anyone has a better solution or additional insights, please let me know. Thank you! |
Beta Was this translation helpful? Give feedback.
-
Our project is using Vector to send message to 2 Kafka brokers. These 2 brokers is using Kerberos for authentication. It works good if we only configure a single broker, but it always fails if we configure 2 brokers.
Further investigation shows that the "Kerberos system" is tring to do "Cross realm authentication", however, these 2 realm (mapping to these 2 broker) is not configured to support corss realm authentication. It's not always possible to configure cross realm authentication for different networks / organizations.
The "kerberos system" is actually the GSSAPI used by librdkafka. So I would like to know if there is a configuration so that I can setup 2 separated Kerberos system.
Beta Was this translation helpful? Give feedback.
All reactions