Secrets in Environment Variables
The cluster debates best practices for managing application secrets like API keys and passwords, focusing on the security risks and alternatives to using environment variables and .env files, such as dedicated secret managers like Vault or EnvKey.
Activity Over Time
Top Contributors
Keywords
Sample Comments
I think using a secret manager like https://onboardbase.com solves this easily. .envs are never in the codebase.
The whole .env file holding all your configs thing is a disaster. People forget to update the template, it has to be passed around, etc.Configure your secrets in Azure Key Vault (AWS Secrets Manager, GCP-something-I-forget) or whatever the non-cloud Vault software is called.Devs only set client_id, client_secret, and env defaulted to dev. On startup, the app fetches configs for the secret store. The needed secrets are in source control. If the needed secret is missing from the secret store
And the environment! (Also, don't put secrets in environment vars)
I assume environment variables became popular as it's an 'easy' way to inject secrets without hardcoding them in a config file.
Can you do safer? Yes, yes you can with a secrets management service (e.g.: Hasicorp Vault). Is that way more complicated to setup in all envs? Oh yes, yes it is.
Any good cross-platform and easy ways to share secrets without using environment variables?
There's nothing wrong with passing secrets in environment variables. They're not supposed to be publicly readable, and if they are, then you should fix that. Any alternative could also end up being accidentally publicly readable due to a mistake.
This is always a very heated discussion topic :)We started developing Infisical for the majority of people using environment variables right now. We actually have some plans for accommodating for other more secure approaches very soon. Stay tuned.Feel free to join our Slack for any updates: https://join.slack.com/t/infisical-u
it's both trueputting any form of secrets into a env var is deeply insecureusing env is the most simple uniformly available way to have configsthrough I would take it a step further, anything which must not be leaked probably should not be in any config, weather env or file or similar, it should be injected through other means if viable
Store a path to the top secret file in an environment variable, and have the program read the credentials out of the file. Put the file somewhere far away from the repo, on the deployed filesystem.