Ask HN: What tools should I use to manage secrets from env files?

There are varying degrees to this but I'll focus on the early stage, low effort approaches I've found work.

For an easy, slightly hacky version I've used git-crypt (https://github.com/AGWA/git-crypt) with tiny teams. You'll need to share the decryption key (e.g. via 1password shared vaults).

As your need for security grows (but you're still not working with a giant team) you're better off using non-committed .env files locally (with need-to-be-shared dev keys stored in shared vaults in 1password) and prod GCP/AWS secrets managers remotely.

Once you work with a bigger team you'll need to start minting API keys limited in scope to each individual, for them to work with locally. The prod keys will only live in the remote environment, managed by some kind of secret manager offered by the platform and will need to be rotated frequently.

So far, I find Ansible Vault to be good enough for this (when using Ansible at least): https://docs.ansible.com/ansible/latest/vault_guide/index.ht...

You still have to "manage" the vaults' passwords, though.

I agree that using a hosted secrets manager is better than storing a random assortment of secrets in an .env file that's written right next to your source code. Just make a with-secrets shell script that checks your 2FA and fetches them into the environment as it starts your application.

This way, the opportunity to expose the secrets is more limited to the actual run-time of the application. You don't need to risk exposing your secrets every time you git push.

The place I work has a list of security guidelines that is, like, ten pages long and full of links to more detailed explanations.

The exact advice depends on how you’re running your services. My starting advice, for cloud, is this:

1. Run in multiple, separate accounts. Don’t put everything in one account. This could be as simple as having a beta account for testing and a separate production account.

2. Use cloud-based permissions systems when possible. For example, if you are running something on AWS Lambda, you create an IAM role for the Lambda to run as and manage permissions by granting them to the IAM role.

3. If that’s not possible, put your credentials in some kind of secrets management system. Create a process to rotate the secret on a schedule. I’d say 90 days is fine if you have to rotate it manually. If you can rotate it automatically, rotate it every 24 hours.

4. Set up logging systems like CloudTrail so you can see events afterwards.

Finally, as a note—people at your company should always authenticate as themselves. If you are TheBigDuck234, then you access your cloud resources using a TheBigDuck234 account, always.

This is just the start of things.

You could use SSM or the Secrets Manager. Although IAM is it's own nightmare realm.