You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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: