Kustomize-controller can currently decrypt SOPS encrypted files - but whole files only. It does this by, among other things, string matching "sops" and "ENC".
Kubernetes Secrets are base64 encoded, therefore when a SOPS encrypted file is added as base64 encoded data to a Kubernetes Secret, it is not decrypted.
I tried to explain this here fluxcd/flux2#745 (reply in thread)
You may well ask yourself, why someone would want to base64 encode a SOPS encrypted file. We, and I believe others, would and have (using fluxv1 workaround not available in v2) been using Kustomize secretGenerator. It is a useful feature in that it appends a hash of the content of the secret, and propagates that suffixed name to pods that need that secret. This enables that if the underlying secret should change, appropriate deployment/pod rollouts are scheduled.
I will submit a very rough PR, showing a functional solution. This is my first foray into Go development, with such a complicated project I'm surprised it worked - credit to the CONTRIBUTING instructions on getting a local version running so easily. If there is appetite to accept the idea, then I and hopefully others can work to improve the quality of the code and tests etc..
Kustomize-controller can currently decrypt SOPS encrypted files - but whole files only. It does this by, among other things, string matching "sops" and "ENC".
Kubernetes Secrets are base64 encoded, therefore when a SOPS encrypted file is added as base64 encoded data to a Kubernetes Secret, it is not decrypted.
I tried to explain this here fluxcd/flux2#745 (reply in thread)
You may well ask yourself, why someone would want to base64 encode a SOPS encrypted file. We, and I believe others, would and have (using fluxv1 workaround not available in v2) been using Kustomize secretGenerator. It is a useful feature in that it appends a hash of the content of the secret, and propagates that suffixed name to pods that need that secret. This enables that if the underlying secret should change, appropriate deployment/pod rollouts are scheduled.
I will submit a very rough PR, showing a functional solution. This is my first foray into Go development, with such a complicated project I'm surprised it worked - credit to the CONTRIBUTING instructions on getting a local version running so easily. If there is appetite to accept the idea, then I and hopefully others can work to improve the quality of the code and tests etc..