Encrypting credentials config file in production and pseudo key rotation

[Ivan Buljan]

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?

[Brian Candler]

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. 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.

[Peter Galbavy]

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:

[Marcin Romaszewicz]

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

--
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...@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.