The Command Line Interface Guidelines [1] says:<p>> Do not read secrets from environment variables<p>> Secrets should only be accepted via credential files, pipes, `AF_UNIX` sockets, secret management services, or another IPC mechanism<p>Which one of these do you use? On github it seems common for projects to use environment variables for secrets.<p>Do you use secret management services for work only, or do you use them in your personal projects too?<p>[1] https://clig.dev/#environment-variables
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.
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.<p>[1] <a href="https://www.doppler.com/blog/lessons-from-mercedes-benz-source-code-exposure">https://www.doppler.com/blog/lessons-from-mercedes-benz-sour...</a>)
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.