How to use with SOPS?

[highb]

Hi there @jessesuen ! Thanks for providing this interesting ArgoCD pattern. I'm trying to make use of it in my own CD experiment that uses SOPS for secrets encryption. I have a secret file that is encrypted with SOPS and called as a resource using Kustomize. When I follow the pattern outlined in this repo and get my "rendered YAML branches", I've found that the SOPS doesn't know what to do with it because the whole file wasn't encrypted originally with SOPS, only one YAML document in the big all.yaml file.

Do you have any workarounds for this? Is there something I'm missing about how SOPS should be used in this context?

[highb]

The workaround I've thought of is to use a different tool such as Vault or sealed-secrets that do the decryption on the cluster itself. Perhaps that the way to go.

[jessesuen]

The workaround I've thought of is to use a different tool such as Vault or sealed-secrets that do the decryption on the cluster itself. Perhaps that the way to go.

Right. This technique won't work for SOPS, or any technique which results in the decrypted/sensitive secrets being stored in the branch in plaintext for all to see.

It will only work if the decryption or fetch of the secret happens in-cluster. Some tools which do this are:

• SealedSecrets
• Vault Agent Sidecar Injector
• ExternalSecrets

Another possibility that will allow you to use SOPS, is to still use an env/prod branch, but instead of containing rendered YAML, it is an actual mirrored branch of main. argo-cd would still perform the templating since the Application path would point to a kustomize base under env/prod.

Pros:

• retain the benefit of shielding prod from changes to the common base (since prod points to a different branch)
• can use SOPSs

Cons:

• upgrading kustomize in argo-cd is still risky
• lose the benefit of a readable diff of manifest changes (since it is obfuscated behind kustomize build)