kustomize-controller
kustomize-controller copied to clipboard
Global configuration of SOPS Age key
Hi,
we are using SOPS to encrypt our secrets for various people who are allowed to see them and a single key per target environment. With this usage, it's a bit tedious to add this snippet to every single flux kustomization:
spec:
decryption:
provider: sops
secretRef:
name: sops-key
The kustomize-controller already knows when something is encrypted with SOPS (https://github.com/fluxcd/kustomize-controller/blob/e3838182c8c3850cee81522e8dba3f3eab502fee/controllers/kustomization_controller.go#L726-L730), practically eliminating the need for .spec.decryption.provider
. If the kustomize-controller could add keys from a configured file (perhaps even using the environment variable SOPS_AGE_KEY_FILE
), configuring this on every kustomization wouldn't be needed anymore.
All this could be added on top of the current API, so no breaking change and specifying another decryption provider or an additional key source would still be possible.
Thanks for making Flux :)
In the cluster dir where all the Flux Kustomization are, you can write a patch that adds decryption
to all Flux Kustomization that have a common label. This is how it can be done, using a patch in clusters/my-cluster/kustomization.yaml
:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- flux-system # this must be included otherwise Flux will delete itself
- flux-kustomization-app1.yaml
- flux-kustomization-app2.yaml
patches:
- patch: |
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
name: all
spec:
decryption:
provider: sops
secretRef:
name: sops-key
target:
kind: Kustomization
labelSelector: app.kubernetes.io/sops=enabled
Oh, interesting, thank you, we will test this :)
Somehow I never replied to this, sorry!
This works fine for us, many thanks :)
I think there is still a valuable use case for being able to load keys such as sop agekey directly on the controller pod in a multi-tenant environment with namespace isolation. This would allow a cluster administrator to configure sop private key in a infrastructure namespace where the controller is deployed to allow cluster-wide decryption with a single key whilst not needing to expose it to tenant namespaces directly using secrets replication mechanisms. Thus, tenants can simply encrypt using a single global public key whilst not compromising the security of the private key and avoiding the need to configure sops decryption on each kustomize instance with patches and without needing to manage service account impersonation. Not sure if this is already possible with a well crafted volume mount on the controller already @stefanprodan ?