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

> If you are TheBigDuck234, then you access your cloud resources using a TheBigDuck234 account, always.

Or have a 'sudo' TheBigDuck234-to-AdminAcct mechanism if possible, or TheBigDuck234_admin account.

On my Linux machines I do sudo-to-root, but on macOS, my daily driver account does not have sudo access so I have to first su to "admin" and then can sudo from there (for GUI requests I enter "admin" (or whatever)).

Using https://www.gopass.pw, which stores secrets in git, and thus also works for teams. Also possible to access the secrets programmatically.

Usually `.env` files are sourced into your development shell and also ignored by `.gitignore`.

The problem with `.env` files is that you're leaving credentials unencrypted on disk and it's easy to leak these files during screen sharing and with multiple projects there will eventually there will be so many secrets spread/sprawled everywhere that you lose track of what credentials are being used and what are expired. You want to be able to inject the required keys only when needed and leave no trace behind when not needed.

I wrote about this in our documentation for Polykey: https://polykey.com/docs/how-to-guides/developers/developmen...

We are still working out the kinks but I expect that one should be able to easily do `. <(polykey secrets env project-vault)` in whatever development shell you have, perhaps even reference a schema for expected keys.

Another new (open source!) tool to check out in this space is https://dmno.dev

It's a bit different than most of the other tools listed here, in that it is designed to generally solve the papercuts of dealing with config (both sensitive and not), and is not coupled to storing your sensitive config in a specific platform (paid or otherwise).

You define a simple schema for all of your config, and you get validations, built-in documentation, full type safety, and the ability to compose config together in any way you choose. You can also easily share config across a monorepo (if you are using one).

Additionally, our drop-in integrations (node, vite, nextjs, astro, remix, more on the way) go a bit deeper and do things like help you detect and stop leaked secrets, redact secrets in logs, and deal with the footguns of boot vs build time config in hybrid rendering environments.

As for storing/syncing sensitive data, we currently have 2 plugins but more are in the works and will be guided by user demand. The first lets you store your secrets encrypted within your repo (like dotenvx, git-crypt, etc), and the second lets you sync with 1password. Personally we think the 1password plugin makes sense for a lot of teams, since they are probably already using it. You can wire up individual items to your schema, or pull from dotenv style text blobs. You can (and should!) segment items into multiple vaults, and use multiple service accounts to access them. You can even mix and match plugins to pull secrets from multiple services.

(see https://dmno.dev/docs/plugins/encrypted-vault/ + https://dmno.dev/docs/plugins/1password/)

In the future, we'll have deeper support for things like key rotation and single-use keys, k8s, way more backends, etc. It's all open source, so come and tell us what you need (or even help us build it) and we'll make it happen!

If it's not obvious already, I am the creator :)

PS - Feel free to hit me up for more info or a demo - theo at dmno dot dev

This is by far the simplest solution. It’s easier to understand and setup than the other solutions mentioned. It simply encrypts the value portion of the variable so its safe to commit the entire env file. The only draw back is developers could still potentially commit private keys the repo or commit the decrypted env file. If you’re working with env variables that don’t require updates often it’s a decent solution.