Helm-operator: SOPS Support

[rbrondgeest]

Describe the feature
Allow helm-operator to decrypt SOPS encrypted files upon loading in a chart.

When a chart contains secrets, it is currently not possible to use these without changing the setup of your project, so that these are part of the step where flux comes in. We have to move SOPS files out of the chart directory and into the releases folder, which forces a certain way of working that might be undesirable.

What would the new user story look like?

1. User starts up the operator using the --enable-sops flag
2. A new HelmRelease is applied using f.e. a git reference.
3. Before a chart is loaded from GIT, Helm Operator looks out for .sops.yaml files in the repository and decrypts any encrypted yaml files while loading in the charts.

Expected behavior

1. When managing secrets inside a GIT repository containing SOPS encrypted values for a helm chart , these are unencrypted upon loading in the chart.
2. chartFileRef could now be used in the HelmRelease resource for easy overrides/contexts of secrets

[hiddeco]

I am personally opposed to this idea as you should not ship encrypted files with your Helm charts, it's a packaging solution and this way your packages are no longer usable without additional non-native Helm requirements.

Note that we already support ways of referring to secret or config map values, and Flux (which main focus is working with Git, and has SOPS support) can put them in place for you so that you can refer to them in your HelmRelease.

[stefanprodan]

I think storing secrets in charts is as bad as storing secrets in container images. @rbrondgeest can you give some examples of what kind of secrets you embed in a chart and what's the reasoning for having them there?

[rbrondgeest]

Im not sure if this could be considered "The secrets being part of the chart"

We ran into this limitation when we started using flux, previously we used to deploy helm charts using the following command:
helm install -f values.yaml -f values.prod.yaml -f secrets.yaml -f secrets.prod.yaml api-example-chart

Where we have the following structure inside our API project:

/api/src/* ... (for the sourcecode)
/deploy/Chart.yaml
/deploy/.sops.yaml
/deploy/templates/* (chart template files)
/deploy/vars/values.yaml
/deploy/vars/values.prod.yaml
/deploy/vars/values.accept.yaml
/deploy/vars/secrets.yaml
/deploy/vars/secrets.prod.yaml
/deploy/vars/secrets.accept.yaml

[jantoebes]

@hiddeco (some background information)

One side effect of using the secretKeyRef in combination with Sops is that the whole config file will be encrypted into a single line.

apiVersion: ENC[AES256_GCM,data:W+M=,iv...
kind: ENC[AES256_GCM,data:hbz10x8e,iv...
metadata:
    name: ENC[AES256_GCM,data:pgUuS0IJ...
    namespace: ENC[AES256_GCM,data...
type: ENC[AES256_GCM,data:K...
stringData:
    values.yaml: ENC[AES256_GCM,data:cJ/Ip9DFoZSjf8s1aj....

This will introduce for instance unnessecary git merge conflicts, while ideally, you would like to have something as

apiVersion: ENC[AES256_GCM,data:W+M=,iv...
kind: ENC[AES256_GCM,data:hbz10x8e,iv...
metadata:
    name: ENC[AES256_GCM,data:pgUuS0IJ...
    namespace: ENC[AES256_GCM,data...
type: ENC[AES256_GCM,data:K...
stringData:
    secret1: ENC[AES256_GCM,data:cJ/Ip9DFoZSjf8s1aj....
    secret2: ENC[AES256_GCM,data:cJ/Ip9DFoZSjf8s1aj....
    secret3: ENC[AES256_GCM,data:cJ/Ip9DFoZSjf8s1aj....

We hoped by using chartFileRef we could work around this limitation of secretKeyRef and SOPS, via chartFileRef, because chartFileRef doesn't require a "yaml in yaml" format. Something secretKeyRef does

[hiddeco]

Wouldn't this issue also be solved by either #37 or #49?

[jantoebes]

Ah nice! I was not aware of these issues. Thanks!

[hiddeco]

Closing this in favour of linked issues above.