Replies: 2 comments 3 replies
-
There is no workaround right now. There is an issue tracking this limitation somewhere among the issues. |
Beta Was this translation helpful? Give feedback.
0 replies
-
@scholzj , thanks for the quick reply. I had a look at all 100+ open issues in the |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello everyone,
Hopefully someone can provide a creative solution for the (rather simple, I'd say) problem that I'm facing.
Context
I'm currently building a cluster that uses OAuth authentication based on Kubernetes generated JWT tokens. The idea is to allow Kafka clients to use their pod's JWT token to authenticate to Kafka.
Using default settings for the OAuth listener the Kafka Principal username gets translated to the value of the
sub
claim, which typically looks like thissystem:serviceaccount:kafka-test:default
.For authorization I'm using the
KafkaUser
CRD.Problem statement
Given that the Kafka Principal username extracted from the JWT token is an invalid Kubernetes resources name (e.g.
system:serviceaccount:kafka-test:default
) this basically means that I can't useKafkaUser
CRD to manage authorization. One quick and dirty workaround is extracting specific claims from the JWT token, but there may be situations where usernames could collide (e.g. service accountkafka-consumer
exists in multiple namespaces).Is there a way to work around this problem? Possible thought/solutions that come to mind:
KafkaUser
CRD to match the Kafka Principal username extracted from the JWT token.userNameClaim
parameter of the OAuth listener.Any help would be highly appreciated.
Later Edit & TDLR
This is known issue, discussion happening in #10353
Beta Was this translation helpful? Give feedback.
All reactions