-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
oAuthSecret stored in plain text #22950
Comments
Hello @guydog28
|
Adding |
Possibly. If someone wants to point me in the right direction for eclipse's requirements for contributing and the section of the architecture to look at for this, I can possibly dig in a bit. |
I think we can read the secret here [1] like this: secret := &corev1.Secret{}
exists, err := deploy.GetNamespacedObject(ctx, ctx.CheCluster.Spec.Networking.Auth.OAuthSecret, secret) If secret exists, then read some key from it, otherwise use |
I agree that is probably the right spot since it isn't done the same way in openshift. Is this something your team would do or is it still preferred that I do it? I've only written minimal Go, so it might take me a bit to get a working environment going and wrap my head around it and add tests and such. |
I created this: eclipse-che/che-operator@main...guydog28:che-operator:main But I lack the background to create proper unit tests that test the cases where:
Mainly - how to mock the calls to get the secret and the key in the cluster for the tests. Any help on that would be appreciated and then I can submit a PR. |
@guydog28 |
@tolusha eclipse-che/che-operator#1836 Created there. |
@guydog28 |
You are very welcome. Thanks for the help! |
@guydog28 thank you for the contribution \o/
will you be able to contribute additional docs to https://github.com/eclipse-che/che-docs? |
Describe the bug
oAuthClientSecret is being stored in plain text in the CheCluster resource. We deploy Che via helm and GitOps with ArgoCD. This means cluster state is stored in Git. We used ExternalSecrets to keep all sensitive data out of the code base, but this does not seem to be possible with Che.
Suggestion:
Modify networking.auth.oAuthSecret to first check in the namespace for a secret with the provided name, and a key of 'secret', and if it does not exist, assume the value is the plaintext secret. This keeps things working with backward compatibility but allows us to keep sensitive oauth client secrets out of our git repo.
Che version
7.85@latest
Steps to reproduce
No steps required.
Expected behavior
Provide a kubernetes secret name in place of a plaintext oauth client secret.
Runtime
Kubernetes (vanilla)
Screenshots
No response
Installation method
other (please specify in additional context)
Environment
Amazon
Eclipse Che Logs
No response
Additional context
We store the CheCluster resource and supporting resources in git, and use ArgoCD to keep them in sync with the cluster.
The text was updated successfully, but these errors were encountered: