Ability to read required secrets from other sources (file) than Kubernetes

[burmanm]

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

    secret := &corev1.Secret{}
    if err := client.Get(

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.

┆Issue is synchronized with this Jira Story by Unito ┆Issue Number: CASS-25

[Miles-Garnsey]

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;

secret := &corev1.Secret{<content>}

I might have missed the point here somewhere I suspect.