Crypto support for git

[davidkarlsen]

It would be great if https://www.agwa.name/projects/git-crypt/ or https://github.com/mozilla/sops could be supported OOTB.

While I am aware of solutions like sealed https://github.com/bitnami-labs/sealed-secrets (and also use it for my own charts for secrets) there are certain public charts which do not - hence there is a real need to support a secure git repo in some way.

Both options can be supported quite non-intrusively - simply add support for the binary and add config vars (at least for sops)

[stephenmoloney]

@davidkarlsen

It would be great if https://www.agwa.name/projects/git-crypt/ or https://github.com/mozilla/sops could be supported OOTB.

These are useful projects and I've used git-crypt but plan on moving to sops. and I've recently come across another one that seems interesting in the k8s context: https://github.com/Soluto/kamus but I have given it a try yet.

With that said, however, I wonder if flux already has a workaround for your issue with the ValueFileSecrets feature?
https://github.com/weaveworks/flux/blob/master/site/helm-integration.md#specvaluefilesecrets
This can be useful where a chart does not provide the option to specify an existingSecret.

[whereismyjetpack]

I use valueFileSecrets with helm charts that don't support external secrets. Even if they do, I find that deployments roll nicer when helm manages all the bits and bobs.

We use git-crypt for humans and sealed secrets for the cluster. This seems to work well

[davidkarlsen]

valueFileSecrets amends this to a certain extent - but you'll have one manual flow (create the secret) - and one git-ops driven - using sops or git-crypt makes it fully git-driven.

kamus looks a bit like sealed-secrets

[Multiply]

We've been using helm secrets (sops) for a while, and prefer it over SealedSecrets, as we can use AWS KMS to distribute keys to our team.

An easy way to integrate sops, would be to extend valueFileSecrets or add another one specifically for sops, that takes the encrypted file location, attempts to decrypt it using credentials you configured for flux globally, and profit.

[michaelgeorgeattard]

https://github.com/roboll/helmfile supports helm secrets (sops) and is working fine for us.

We are looking into switching to Flux for parts of our deployment flow, and helm secrets support would be awesome.

[mr-karan]

For people who don't use helm and just want to use the ol' school sops --decrypt mysecret.sops.yaml | kubectl apply -f - is there any way we can support this as well?

[PaulFarver]

I have taken a look at sops support for flux, and have made a proof of concept of the feature. It works for our use case, but it needs a bit of work to be official-ready. I am not very experienced in golang, and could use some help completing the feature. What would be an ideal way forward?

[2opremio]

@PaulFarver I would suggest to clean up the code (if need be) and create a PR (a draft if you don't think it can be merged yet) asking for feedback and with an extensive description indicating how the implementation works.

Thanks a lot for working on it 🌷

[2opremio]

For people who don't use helm and just want to use the ol' school sops --decrypt mysecret.sops.yaml | kubectl apply -f - is there any way we can support this as well?

@mr-karan I have never used sops, but maybe you can use a .flux.yaml file to invoke sops. Additionally you will need to install sops into the flux container (either through an init container or creating your own Flux image).

[2opremio]

We now support SOPS (thanks @PaulFarver ) and git-secret (thanks @arsiesys ), I think this can be closed. Please create a separate ticket if you still think we should support other systems like git-crypt.

[chris13524]

See #2904 for git-crypt support