Transparent encryption/decryption on k8s secrets to encourage GitOps

[mumoshu]

In the helm world, we can use helm-secrets to safely git-commit credentials used by your apps by encrypting it w/ sops.

The decryption is transparent i.e. helm install|upgrade|rollback|template -f path/to/secrets.yaml notices secrets.yaml to be decrypted and consumed by helm automatically. It is useful for enforcing GitOps without authoring your own secret management for it.

A feature for supporting transparent secret encryption/decryption would encourage forge users to organize everything in git repos.

Alternatively, a plugin mechanism to allow an user to extend forge so that one can instruct forge to call out a helm binary for utilizing helm-template/helm-secrets to generate k8s manifests instead of jinja2+yaml.

I'd personally prefer the latter because it would keep forge's scope smaller while providing possibility to also support #15.

WDYT?

[rhs]

Thanks for taking the time to file this issue!

I really like the idea of being able to have extremely minimal footprint outside of git, and it sounds like sops could provide a missing part of the picture there. I need to read up on it a bit more.

I'd also like a plugin system that would allow for extensibility. I've actually got a small start on that already, but haven't made much progress due to lack of an initial use case. I think helm could make a great one though.

I'm just finishing up some vacation right now, but will be back next week so I can take a deeper look at this. One question though... this whole area at first blush seems like it could have a reasonable amount of scope... do you have an example/project slug/initial usage scenario/etc, something that could provide a narrower starting point?

Most existing forge functionality comes out of taking what was once a manual process and automating/streamlining it, so just a simple shell transcript would be a great starting point.