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.

Sign up for GitHub

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

Jump to bottom

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

Open
Tracked by #601
burmanm opened this issue Apr 20, 2023 · 1 comment · May be fixed by #521
Open
Tracked by #601

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

burmanm opened this issue Apr 20, 2023 · 1 comment · May be fixed by #521
Labels
enhancement New feature or request product-backlog Issues in the state 'product-backlog'

Comments

@burmanm
Copy link
Contributor

burmanm commented Apr 20, 2023 •
edited by sync-by-unito bot
Loading

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
@burmanm burmanm added the enhancement New feature or request label Apr 20, 2023
@adejanovski adejanovski moved this to Product Backlog in K8ssandra Apr 20, 2023
@burmanm burmanm linked a pull request Apr 21, 2023 that will close this issue
Draft
5 tasks
This was referenced May 5, 2023
Open
Closed
@adejanovski adejanovski moved this from Product Backlog to Ready in K8ssandra May 11, 2023
@adejanovski adejanovski added the ready Issues in the state 'ready' label May 11, 2023
@Miles-Garnsey
Copy link
Member

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.

@adejanovski adejanovski moved this from Ready to Product Backlog in K8ssandra Aug 22, 2024
@adejanovski adejanovski added product-backlog Issues in the state 'product-backlog' and removed ready Issues in the state 'ready' labels Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request product-backlog Issues in the state 'product-backlog'
Projects
No open projects
K8ssandra
Status: Product Backlog
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

SecretProvider burmanm/cass-operator
3 participants
@burmanm @adejanovski @Miles-Garnsey