HN Explorer

Ask HN: Do you read Secrets from Environment Variables

4 points by tester457 ↗ HN
The Command Line Interface Guidelines [1] says:

> Do not read secrets from environment variables

> Secrets should only be accepted via credential files, pipes, `AF_UNIX` sockets, secret management services, or another IPC mechanism

Which one of these do you use? On github it seems common for projects to use environment variables for secrets.

Do you use secret management services for work only, or do you use them in your personal projects too?

[1] https://clig.dev/#environment-variables

7 comments

[ 2.0 ms ] story [ 25.6 ms ] thread
AlwaysNewb23
Are you familiar with the recent Mercedes-Benz Source Code Exposure [1]? It's a good example of why you should consider a secrets manager for any serious project. Environment variables come with a lot of risks and are difficult to manage as teams grow. 1) ENV files are easy to accidentally push to a repo. 2) It's easy for environment variables to get out of sync among developers. 3) In the case of exposure, it's often difficult to rotate secrets quickly. A secrets manager removes this risk - but you do need to trust whatever service you decide to use, as well as make sure it's compatible with your infrastructure/cloud environment.

[1] https://www.doppler.com/blog/lessons-from-mercedes-benz-sour...)

AlwaysNewb23
For personal projects, it's probably fine to just use environmental variables and .env files the traditional way. The security risk really increases when you start to scale and work with other team members.
tester457
Thank you for your answers, they were very helpful.

When the Mercedes-Benz Source Code Exposure happened I remembered I wasn't doing secrets management in the proper way, but good to know there's less risk since I'm a solo developer. But Doppler looks worth a shot.

lbhdc
No, nor do I use cli flags or config files. I put everything in a secret manager. In the end I think it has a better DX if the app can use the devs local credentials to transparently interact with that secret manager. It creates an audit log and discourages people from wanting to commit secrets in an `.env.sample` or something like that.
AlwaysNewb23
Audit logs for secret managers are an underrated feature. It really helps to encourage best practices as well as track changes.
valrix
Nah, I keep them in an encrypted environment file that I have to unlock at server startup. I used GPG to encrypt with a key and use a long, complex password for unlock. To make it safer I should probably use a security key instead, or add 2FA before the password prompt to unlock. The guidelines are definitely correct about not using environment variables though, since they can stick around in logs and often stay in memory for the life of the program.
aprdm
Those using Secret Managers, could you share some articles on your set up ? Very interested ! Vault seems quite complex for some simple use cases