Don't use ENV variables for secret data (2017)

Saying "ENV," though, isn't writing badly. Or maybe it is, but it's not a sign of sloppiness. It's not like "JAVA," which was never a thing. It shouldn't trigger your brain defect detector.

It is. This is how I would've written it.

> 1. They're stored right next to variables like PATH,

So what? If the problem is that people might accidentally log secrets then the problem is not env variables.

> 2. They'll get printed any time someone writes a shell script

The set -x flag is a debugging flag to print out traces of a shell script being executed. This flag is disabled by default. Why is this far-fetched example being used to justify not using env variables?

> 3. They'll probably end up in your developers' ~/.profile or ~/.bashrc,

No, they don't. With containers you may launch devel env variables some way or another (env files, setting up the IDE, setting env variables manually) but at most they are a part of a testing config. The env variables used in production are handled by the deployment.

Even if you're able to sniff a env variable used in development, that has nothing to do with the production service.

> 4. Because they'll be in ~/.profile or similar, the secret will be in a file on disk anyway

This complaint makes no sense at all. No container orchestration system stores env variables in ~/.profile although their containers use env variables For secrets extensively. The container orchestration service provides secret-management services, including setting up the env your containers are launched, and all you need to care about is that your container needs to accept certain env variables that you will use on your app.

Even if you deploy services on bare metal, you should still use env variables for config and secrets, but you need to be able to manage secrets and rotate keys with a non-pet method.

> So I can understand why people might end up stuck with environment variables despite their downsides.

I'm sorry but you failed to both present any downside of using secrets and point out any scenario from the real world. I mean, anyone who ever read any intro tutorial on how to deploy a system is well-aware that you should not store passwords and keys and secrets in plain-text files. That has nothing to do with using env variables at all. In fact, all your examples are entirely oblivious to the standard workflow of deploying a service, moreso if it involves a container orchestration system.

So if the examples don't have any relation with basic practices and real-world workflows, why should anyone avoid using a best-practice?

>1. They're stored right next to variables like PATH, JAVA_HOME, LC_ALL and PYTHONPATH which people might plausibly decide to log out every time

No, they aren't. You just create a .env file in your project root and run "source .env" before you run your application.

Unlike Windows there are no global environment variables on Linux. All of them are hierarchical and only exist within the process they were created and its children.

Surely you are missing the point on purpose aren't you? Authorization happens through secrets because it is trivial to spoof anything that is not a secret. If you have a party where only known celebrities are allowed to attend then I can just send a double. That same logic applies to two independent servers and creating a server that is mirroring another is much easier than finding a double. The only way to distinguish between a fake and the original is by looking at things the original doesn't share publicly because the double cannot replicate things it doesn't know. Ok, I hope this explanation was good enough to make you understand that authorization should be based on secrets because they cannot be replicated while kept secret.

So "if your database is accessible by everyone" then it must be because the secret is accessible to everyone. However, this is where you start to contradict yourself. You suggested that delivery of the secret is not a problem because "3/ your production DB shouldn't be accessible directly with the password, otherwise you have a bigger problem". As we have established, anything that isn't a secret can be replicated and therefore should never be relied upon. If you store passwords to your database in the source code it's likely that you are also storing other secrets such AWS keys or the password for the firewall dashboard in an accessible repository. Now an attacker is behind your firewall and can access the database anyway.

I don't understand why you seem to defend storing passwords in source code by arguing about an irrelevant detail. Even if you are completely uninterested in securing your application you would still store the passwords outside of the source code simply for convenience. When you have a production, staging and development environment then each environment will need a different password. The logical conclusion would be to make the password configurable just for this alone. 90% of the features that something like Vault provides are actually more about convenience and password management than actually increasing security. Most of the security benefits come from the fact that it encourages responsible handling of passwords, not from the fact that the software itself is more secure.