Check out SOPS, we use it to commit encrypted secrets into Git and only people with access to keys can see them.
https://github.com/mozilla/sops On Sat, Oct 1, 2022 at 2:59 AM Peter Galbavy <pe...@wonderland.org> wrote: > We have a different requirement, which is opaquing of credentials in user > visible config files. The company I work for has a basic way of doing this > in the "real" product and I followed the same model for compatibility. > There is, as yet, no auto rotation. > > Basically, we generate an OpenSSL "compatible" key file and use that to > encode and decode the credentials. The key file is still local but > can/should be on a different file system and only readable by the app > owner. The config files can then be edited / communicated with less chance > of leaks. The objective is to protect against casual mistakes, not against > determined actors. > > I layered it, along with other local requirements, over viper so that > "GetString" etc. just works. > > https://github.com/ITRS-Group/cordial/tree/main/pkg/config > > Peter > > > On Friday, 30 September 2022 at 17:34:29 UTC+1 Ivan Buljan wrote: > >> Hello World >> >> This relates to that never ending question of securing the credentials in >> production/staging envs, that is, avoiding storing them as plain text >> >> I am wondering if anyone could share their thoughts about the following >> approach we are thinking of taking. >> >> Here we go: >> >> During build phase, an encryption key is generated and credentials are >> encrypted with it. >> >> Once deployed, the instance decrypts credentials with the provided key >> and does what it needs with them. Just before destroying the original files >> (creds & key), the instance then generates a new encryption key and >> re-encrypts a copy of credentials, which it keeps in memory. Newly >> encrypted credentials along with the key are only dumped onto a filesystem >> if the application panics and requires to be restarted, at which point the >> same cycle key rotation decryption/encryption happens again. >> >> Is any security benefit with such approach? >> >> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/d011891f-ab3f-41eb-8ad1-c90cbcf78a58n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/d011891f-ab3f-41eb-8ad1-c90cbcf78a58n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LtbJbScc1EeDa0QbOm48wVa_sXxitAR%3Dy-Wki9BekV%3DiA%40mail.gmail.com.
