Ability to read required secrets from other sources (file) than Kubernetes #520
Open
Labels
Comments
Draft
5 tasks
This was referenced May 5, 2023
|
Is this ticket still required now that we have the modular secrets backend? I'm not sure what purpose it would fulfil since a secret can always be read from a string by just creating it using; I might have missed the point here somewhere I suspect. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is missing?
At the moment, we read all the secrets that are required (be it superuser, mTLS certs etc) from the Kubernetes directly - without any alternatives.
We should do these reads through an interface to simplify both testing as well as user implementations. So instead of
We should modify all these to use
SecretProvider.getSecret(string)or similar interface. We can then later add - if required - multiple implementations of this interface, but for testing we could use strings and for the operator we would add filesystem based reader.The configuration, which one is used should be added as a field to the
OperatorConfig. The intention is to not allow at this point any plugins, but simply decouple the Secret reading from the controller-runtime Client.Why is this needed?
Some users are not able to use Kubernetes secrets due to organizational requirements. cass-operator should be usable to them also.
The text was updated successfully, but these errors were encountered: