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.
