I'm not sure what your threat model is, but I note that if you dump both the encrypted data and the key to the filesystem, then the original secret data is trivially recoverable. And with most filesystems, if you delete a file, the data is still recoverable.
I would suggest using an external secret manager like Hashicorp Vault. You give your application some credentials (at the simplest an AppRole, which is essentially a username and password), which it uses to authenticate to the Vault server, obtain a token, and then retrieve the secret data. It then keeps this in RAM only (as presumably it would have done anyway). Of course, you have to decide whether there is a threat that the attacker can break into the application and get hold of the AppRole credentials. However an AppRole can be bound to an IP address so that it can't be re-used elsewhere, and more importantly you will have an audit log of every time the secret was fetched - so if it was fetched when the application *wasn't* restarted, this can set off alarm bells. There are lots of other ways your application can authenticate to Vault <https://www.vaultproject.io/docs/auth>. For example if it's running in one of the big public clouds, then it can use its cloud identity. Not saying this fits all use cases, but you might want to consider this rather than a roll-your-own. 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/d6eabf99-3da0-42eb-bead-c2eddc471db7n%40googlegroups.com.
