Sensitive data in ConfigMaps and Helm values.yaml about helm HOT 8 CLOSED

np np, I'm putting together a PR that explains what I'm thinking.

from helm.

As a short term solution for this issue could we add a bypass to the ConfigMap and allow it to be written by hand in a k8s secret?

from helm.

@roberttmoon-wizehive I'm not sure what you mean here.

FlowForge needs to read all the values from a single flowforge.yml file. That is currently provided to the deployment from the ConfigMap.

If you can come up with a PR to the helm chart that moves to a Secret then I'll happily review it, but it will need to support upgrades.

from helm.

If you can come up with a PR to the helm chart that moves to a Secret then I'll happily review it, but it will need to support upgrades.

How is that secret set, I don't see it in the helm charts

from helm.

@roberttmoon-wizehive There is no secret, hence the issue...

from helm.

this is the secret it uses, but I don't know where it is created:

https://github.com/flowforge/helm/blob/main/helm/flowforge/templates/job-upgrade-db.yaml#L37-L41

there doesn't seem to be anything in the chart the creates the secret.

from helm.

oh its from the postgresql chart

from helm.

Ok, so i have looked over the db update script some more and it seems that the update only runs when you are using fileStorage and localPostgres.

My expectation would be that if you were by-pasing the config builder in the helm chart to write your own from scratch as a Kubernetes secret then you would be beyond running postgres in your cluster.

The goal here is to provide a method (albeit not as user friendly as I would like) to secure the helm chart and make it safe to check in to a source control repository and be installed to your cluster with something like ArgoCD or Flux.

Additionally, I could add a validation to the chart.schema.json that prevents using the secrets with the localPostgres

from helm.