"flux build kustomization" should handle encrypted secrets better

[aloifolia]

I have a cluster which applies flux to auto-syncs the configurations in a repo with the installed k8s objects. SOPS is used to encrypt secrets. All of this works as intended.

Now, sometimes I want to do a flux build kustomization on my local machine, followed by a kubectl apply -f to test my configuration in a playground environment before I actually change the state of the main branch in my repo. When the target includes SOPS-encrypted secrets, they are transformed like this:

apiVersion: v1
data:
  .dockerconfigjson: eyJtYXNrIjoiKipTT1BTKioifQ==
kind: Secret
metadata:
  name: my-secret
  namespace: my-namespace
type: kubernetes.io/dockerconfigjson

The decoded value of the .dockerconfigjson is {"mask":"**SOPS**"} regardless of the encrypted value. Thus, flux does not apply SOPS to decrypt the value but rather just replaces the encrypted values by dummy values.

I find this behaviour suboptimal because the secret is rendered useless but the command does not tell me that there might be an issue. If you don't know about this behaviour, you don't see the issue before everything is installed and stuff crashes in the cluster.

There are a few ideas that come to mind for alternative modes that could be activated by a specific flag:

1. Abort if a secret requires decryption and if the decryption cannot be handled by flux. This way, I see issues with my setup before I apply them manually in a cluster.

2. Skip secrets that cannot be decrypted by the flux command. This way, the output does not contain garbage and I can easily augment it (something like "sops -d [path] >> result.yaml").

3. Under the hood, trigger a separate command to perform the decryption. This could either be hard-coded for specific use-cases or there could be some mechanism to apply a user-provided script. This way, the user would not need to combine the pieces of different commands manually.

I'm not sure if these feature requests should be asked here or at the kustomize issue tracker.

[souleb]

flux build ks purpose is to provide the same build output than kustomize-controller and early feedback on build issues. The only step where a request is made to the k8s API Server, is to retrieve a live kustomization. The masked data is not decoded. Doing secret decryption is out of scope, and we purposely mask any sops data. One intended use case is to run the build process in CI for validation and we do not want to expose the sops values.