New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transparent encryption/decryption on k8s secrets to encourage GitOps #127

Open
mumoshu opened this Issue Jan 5, 2018 · 1 comment

Comments

2 participants
@mumoshu
Contributor

mumoshu commented Jan 5, 2018

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

This comment has been minimized.

Contributor

rhs commented Jan 5, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment