Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement]: Support for Passing Username as Secret in KafkaClientAuthenticationPlain #10823

Open
joystern13 opened this issue Nov 11, 2024 · 4 comments

Comments

@joystern13
Copy link

joystern13 commented Nov 11, 2024

Related problem

Description:
I am trying to use Plain authentication for my Kafka clients as documented here. However, I need the ability to pass the username as a Kubernetes secret.

Background:
We are using Strimzi for building Kafka Connectors. We connect to Kafka server hosted on Confluent platform by a different application which uses plain authentication scheme. Our system credentials are stored in Azure Key Vault, where the username and password are rotated periodically. To manage these secrets effectively in Kubernetes, we initially attempted integration with the Secrets Store CSI driver to automatically fetch updated secrets from Key Vault. However, this failed as CSI driver integration is currently unsupported for Strimzi (refer to Issue #5277).

We have now started using akv2k8s to handle this requirement, which requires that both the username and password are configured as Kubernetes secrets.

Request:
Please add support for passing the username in KafkaClientAuthenticationPlain via a Kubernetes secret, in addition to the existing support for passing the password this way. This feature would allow Strimzi users to securely manage dynamically updated usernames and passwords stored in external secrets managers like Azure Key Vault.

Suggested solution

In KafkaClientAuthenticationPlain add the ability to pass both username and password as a single secret.

Alternatives

No response

Additional context

No response

@scholzj
Copy link
Member

scholzj commented Nov 12, 2024

This is currently not planned. But if you would want to contribute it, it might not be a problem, but it should have a proposal to cover the new APIs, backwards compatibility, impact on other places where username is passed (it should lilely be done in the same way everywhere) etc.

@im-konge
Copy link
Member

Triaged on 14.11.2024: This makes sense to have implemented, but it requires a proposal. @joystern13 do you want to have a look at it?

@joystern13
Copy link
Author

Hello @scholzj , @im-konge ,
I will look at it and provide a proposal. Sorry, I can't commit to a timeline.

@scholzj
Copy link
Member

scholzj commented Nov 14, 2024

@joystern13 No worries about the timeline. When you get to it you get to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants