Skip to content
New issue

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

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

Already on GitHub? # to your account

Proposal for configuring username as secret in KafkaClientAuthenticationPlain #154

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

joystern13
Copy link

@joystern13 joystern13 commented Mar 19, 2025

This is a proposal for configuring username as secret in KafkaClientAuthenticationPlain raised for strimzi/strimzi-kafka-operator#10823

Copy link
Member

@scholzj scholzj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the proposal.

I do not think the username is secret and I do not think Kafka is treating it as such. It can show up in many different configs and logs. So I do not think this would solve all your problems.

But this idea comes up from time to time. If we decide that this is something we should support, we should definitely have consistency accross our APIs. So should we accept this proposal and its implementation, it should propose and implement this for all places where the username is specified. E.g. also for SCRAM-SHA authentications and so on.

## Affected/not affected projects

The `KafkaClientAuthenticationPlain` is used in `KafkaBridgeSpec`, `KafkaConnectSpec`, `KafkaMirrorMaker2ClusterSpec`,
`KafkaMirrorMakerConsumerSpec`, `KafkaMirrorMakerProducerSpec`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these two exist anymore.

Copy link
Member

@scholzj scholzj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should also provide more details on the planned implementation. You cover only the API, which is important, but there is obviously also the actual implementation behind it that should be covered.

@ppatierno
Copy link
Member

Thanks for this proposal which makes sense but as Jakub stated we would need more details about the implementation and not only a higher view of the API.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants