fluxcd
Helm storage cannot be changed
We would like to store helm releases in a ConfigMap. This will allow IT staff without rights to read Secrets to be able to perform commands like helm list. The default is helm putting the release data in a Secret, which devs are not permitted to read.
NB, it is not possible to allow a user to "just see one Secret using a wildcard": https://github.com/kubernetes/kubernetes/issues/93845 Since helm releases have incrementing suffixes, this would have been necessary.
Using the chart, I see that there is a value available in a migration value, but we are already on helm 3. Setting it on an existing cluster does not have the desired effect.
# value.yaml
convert:
releaseStorage: "configmaps"
I thought we should be able to pass through the HELM_DRIVER env, but I think extraEnvs is not for passing values to helm itself.
Is there a way to set, in the chart values.yml, the helm storage driver to be a ConfigMap? Thank you!
I believe this is for all versions of the chart. We are using helm 3 only.
Related discussion from the Flux v2 discussion board:
https://github.com/fluxcd/flux2/discussions/839
I did some research and read some code, the important thing to understand why it is not so simple to implement this change is that HELM_DRIVER is an environment variable understood by the Helm (v3) client binary only, not the Helm package used by Helm Operator (and this will likely be the same as with Flux v2 controller)
https://github.com/fluxcd/helm-operator/blob/4dc90d7766bc7a10961c6dc3b2ea6e4d2282c6e8/pkg/helm/v3/upgrade.go#L15
The arguments at the end of this line, opts.Namespace, ""), the empty string is the setting for storage driver. Helm Operator calls into this newActionConfig method in several places all similarly with an empty string setting the storage driver, (this function calls downstream newStorageDriver, which accepts a string setting the storage driver, one and the same empty string.)
So to be clear, Helm Operator is never explicitly setting the storage driver at all, which means you'll always get the default storage driver (secrets). Helm v2 stored releases in configmaps, and changed the default. I think the message I got from the discussion attached in previous comment is that storing releases in a configmap is a legacy behavior which can be "grandfathered" if you are using it from Helm v2 and can't be bothered to change...
But that it is not a supported mode of operating as an ongoing concern in current or future versions; expressly with respect to Flux's helm operator, because a HelmRelease can be constructed with a reference to secrets, and the result of installing a helmrelease that references a secret will be a copy of that secret data in the helmrelease config object, it is not acceptable for Flux to permit, possibly even accidentally, exfiltrating secrets into configmaps that would be possible if we promoted or supported this use case.
OK great, thank you for the writeup, makes sense. I think this essentially means non-"full prod access" devs cannot use commands like helm rollback, or even helm list. We will have a think about what to do. :+1:
Sorry if your issue remains unresolved. The Helm Operator is in maintenance mode, we recommend everybody upgrades to Flux v2 and Helm Controller.
A new release of Helm Operator is out this week, 1.4.4.
We will continue to support Helm Operator in maintenance mode for an indefinite period of time, and eventually archive this repository.
Please be aware that Flux v2 has a vibrant and active developer community who are actively working through minor releases and delivering new features on the way to General Availability for Flux v2.
In the mean time, this repo will still be monitored, but support is basically limited to migration issues only. I will have to close many issues today without reading them all in detail because of time constraints. If your issue is very important, you are welcome to reopen it, but due to staleness of all issues at this point a new report is more likely to be in order. Please open another issue if you have unresolved problems that prevent your migration in the appropriate Flux v2 repo.
Helm Operator releases will continue as possible for a limited time, as a courtesy for those who still cannot migrate yet, but these are strongly not recommended for ongoing production use as our strict adherence to semver backward compatibility guarantees limit many dependencies and we can only upgrade them so far without breaking compatibility. So there are likely known CVEs that cannot be resolved.
We recommend upgrading to Flux v2 which is actively maintained ASAP.
I am going to go ahead and close every issue at once today, Thanks for participating in Helm Operator and Flux! 💚 💙
