-
Notifications
You must be signed in to change notification settings - Fork 90
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
Set the OIDC client secret in an existingSecret in the helm chart #19
Comments
In what perspective would this prove security? Helm uses secrets to store its state and it creates secrets to hold that information. From a Kubernetes point of view it doesn't vhange the domain of the secrets. You can of course argue that someone might use a controller to generate secrets by either having an OIDC operator or just by using a controller to manage secrets (e.g. sealed secrets, vault, …) however, this doesn't make secrets more secure, just changes the way they are created. What makes them more secure in this case, would be your opinionated way of deploying a helm chart, since (as already mentioned) you might store these values outside the chart. In short, yes, I think it makes sense to allow external/existing secrets to be used, but I don't think it's for security, rather than convenience reasons. |
Currently the OIDC client secret is set in a configmap, so the additional security comes from access control (like allowing reading configmaps but not secrets) I agree that it should be moved from the ConfigMap to a Secret as its a sensitive value |
This will definitely be a good idea to provide a way to use an existing Secret for this. It could be done similar to #38 and I will review any PR implementing this! |
You should probably move the value from the ConfigMap to the Secret regardless of supporting external secrets |
Steps to reproduce the problem
Install from helm chart.
Expected behaviour
The oidc client secret should be set in an existing secret for extra security (on par with the rest of the secure tokens)
Actual behaviour
You need to set it in the values
Detailed description
I've created a pull request to fix this: mastodon/mastodon#20803
Specifications
v3.5.5
v4.0.2
The text was updated successfully, but these errors were encountered: