3 ms·
Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets. Things like vault which
by mbrumlow 2y ago
Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets.
Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with Nomad and their template system.
I really dislike these sort of articles. Because it has a catchy phrase "Do not use secrets in environment variables", and that is all that will be remembered. And next thing you know you will be at a company submitting a PR and some guy will say "Do not use secrets in environment variables", and then advise you to pass them as arguments on the command line (this happened to me).
Environment variables are today, the most safe way to pass secrets to a program.
.env files ARE NOT Environment variables, they are files. A better title and write up would be "Do not store secrets in file". Once you do that all the weird problems described, with exception of printing them as logs, go away. Then you need a new article "Do not print secrets in your program".
But that is all moot, because you should already be filtering out secrets by configuring your local log system to do so. I my self write wrappers and log systems that handle filtering out secrets from logs within the same context of the application I run. Its super simple, it s fast (if you know what a trie is) and you can worry free print secrets.
Edit: This article in fact has more damaging impact to security as a whole, mostly because of the conflation and 99/1 on problem/solution. This entire domain will now be blocked on all networks I have control over.
- thayne 2y ago> Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with Nomad and their template system. Indeed. But ideally the "somehow" that you pass that in is not an environment variable. Maybe something like a secure in-memory file that only your container/systemd service/whatever has access to that's injected by something like kubernetes/docker secrets, or systemd-creds, etc.
- mbrumlow 2y agoSure there are more secure ways if you own the code base. But listen you have a mix of those in any system. Consul template can render a config in memory. That is safer. But my gripe is the phrase. The phrase leads to worse situations.
- cpill 2y agoI'm sorry, but is there any data on how many leaks there have been because of .env files vs whatever people think it's even more safe?
- bogantech 2y ago> Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets. Not much use to an attacker if the token / approle is restricted to a specific IP / EC2 instance id. Auditable too
- mbrumlow 2y agoMaybe all your secrets should be node locked …