Configuring sops/helm-secrets in flux

1/24/2020

I currently have Flux and the helm operator installed in my cluster via the helm charts. The flux deployment is monitoring a git repo where I have a .flux.yaml which I pass a folder context via the flux deployment git-path flag. This is used to run kustomize to patch which values files I want to use for the deployment. Some of these environments have files that are encrypted via sops.

I have configured Flux with sops enabled. sops/helm secrets is using an aws kms key, so locally, I assume a role which I have granted access to encrypt/decrypt with the specified kms arn. The issue I am running into is getting these secrets decrypted prior to the helm deploy. I currently end up with the encrypted values in the final kubernetes resource. Cant seem to find any additional documentation about configuring aws access/secret keys to be used by sops on the flux side, nor anything on the helm operator to potentially do it via helm secrets. Any tips would be greatly appreciated!

-- WMiller112
cd
kubernetes-helm
mozilla-sops

1 Answer

1/31/2020

It turns out there was no issue with decrypting the secret. the flux pod runs sops using the node role (which I had granted access to decypt with the necessary kms key), and was successfully decrypting secrets. I tested this by execing into the pod and trying sops -d on the file containing my secrets.

The issue ended up being that I wasnt actually passing the decrypted file to my helmrelease. I ended up accomplishing this by using the following .flux.yaml:

version: 1
patchUpdated:
  generators:
    - command: sops -d --output secrets.yaml secrets.enc.yaml && kustomize build .
    - command: rm secrets.yaml
  patchFile: ../base/flux-patch.yaml

I originally had my secrets file formatted like a helm values file, but instead updated it to be able to patch the base helmrelease file values section with the decrypted values. This results in all the decrypted values being consumed by the helmrelease. The second command removes the decrypted secrets.yaml file so that it doesnt end up getting committed back to the repo.

Keep in mind that this results in the helmrelease in the cluster containing all of your secrets, so you need to manage access to helmrelease objects accordingly.

-- WMiller112
Source: StackOverflow