-
Notifications
You must be signed in to change notification settings - Fork 376
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
kafka: SCRAM secret association #1451
Comments
@chlunde - did you make any headway on this? I fear its absence is going to make Crossplane a non-starter for us... |
Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as |
/fresh This is certainly still an issue - we currently have our Crossplane usage wrapped up with some bash scripting to do the association which is fairly unpleasant. |
Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as |
What resource do you need?
ScramSecretAssociation.kafka
What is your use case?
Provision users with access to kafka
Would you be willing to contribute it using code generator?
Yes
I started looking at adding support for attaching secretsmanager secrets to kafka clusters in provider-aws / kafka. The MSK API for SCRAM secrets has List/BatchAssociate/BatchDisassociate, but no Get (or filter for List).
So it would be fairly expensive to create a model where each user is a distinct object (i.e. for 100 users, one would call List 100 times every 5 minutes).
So I wonder if we should have one object containing the list of all secrets that should be associated with the resource.
Using referencers, one can easily select any amount of secrets that should be attached to the cluster.
Design 1 - one ScramSecretAssociation per cluster
Design 2 - one ScramSecretAssociation per user, multiple ScramSecretAssociation per cluster
In this case, we would call the List API endpoint (returning 1000 users) 1000 times per minute, if we have a reconcile interval of one minute and 1000 users in the cluster (the current limit)
The text was updated successfully, but these errors were encountered: