Secret value not transferred to output values.yaml

[Vaintti]

I have a secret defined in a kubernetes yaml file but the value doesn't get transferred to generated values.yaml file

Input

apiVersion: v1
kind: Secret
metadata:
  name: db-password
type: Opaque
data:
  password: c3VwZXJzZWNyZXRwYXNzd29yZAo=

Output

dbPassword:
  password: ""
kubernetesClusterDomain: cluster.local

Expected output

dbPassword:
  password: "supersecretpassword"
kubernetesClusterDomain: cluster.local

[arttor]

Hi @Vaintti, thank you for the question. This was done on purpose. In most cases, generated chart will be stored in git. In this case, it is not a good idea to have secrets in values.yaml. So secretes are omitted from values.yaml and marked as required in a template to force chart user to provide it as flags in helm install.

[Vaintti]

Just thinking if this should be made possible with a flag. --use-unsafe-secrets or something to make it clear it's not the safest of practices

[arttor]

I agree that it is inconvenient but it is true for all security measures. I suggest not implementing this option right now. But we can do so if we have more votes for this feature.

[vmath3us]

I'm interested. My use case would be something like:
Take a single kubernetes.yaml coming from the repository, concatenate it with a local secret.yaml, run helmify, and apply the resulting helmchart. It would be useful in airgaped scenarios

[saper44rus]

+1

[maobuji]

In most cases, using a template is the correct approach. However, in some cases, I require an instance configuration that can be used for quick conversion and unified management. In such cases, I prefer the configuration to remain as close to the original as possible, so that I can use it quickly.

I suggest splitting it into different modes. This can help avoid similar issues from occurring.

[rcaballeron]

+1
I’m supporting this feature as well. In my case, the secrets are already encrypted using SOPS so that it isn’t a problem at all to commit them to the remote repo. Indeed, as part of our gitops setup, it’s expected to have them committed. It will be great to have such feature.

[arttor]

can this feature be covered by external secrets #152?

[rcaballeron]

Hi Artem,
I think that it could work. The main idea is to transfer the existing values in the secrets to the generated helm values.yaml file. If that is achieved by implementing #152, this use case is covered.