[michaelt]

I think what the author means is environment variables are particularly vulnerable to being logged by accident, because:

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

2. They'll get printed any time someone writes a shell script with set -x then uses the environment variable.

3. They'll probably end up in your developers' ~/.profile or ~/.bashrc, meaning any program logging the environment will log it, not just your program

4. Because they'll be in ~/.profile or similar, the secret will be in a file on disk anyway and a secret that's in one place is always better than a secret that's in two places.

With that said, a lot of CI servers that support "secure variables" offer those as environment variables and nothing else. So I can understand why people might end up stuck with environment variables despite their downsides.

[throwaway894345]

This all seems like a lot of work for a problem that seems largely theoretical. How often do Fargate or Lambda function VMs get broken into in the first place? I could see this maybe being a concern if you're running big, long-running VM instances with lots of collocated services (as well as utilities for process management, ssh support, log exfiltration, package management, etc and all of the extra drudgery/attack-surface you have to manage yourself when you opt out of serverless).

Also, application secrets for development environments probably shouldn't be super sensitive in the first place, right? For example, for a third party API key for a service like Auth0, we would have a dev tenant within Auth0 so even if a developer's environment is compromised, it can't jeopardize production.

[R0b0t1]

It's really the latter half of your fourth point. Many programs log envvars for either debugging or intrusion detection purposes just like they run command invocations. In a multiuser environment this can be problematic, especially in a business with multiple security areas. E.g. you don't want IT (that can read the logs) getting access to production resources in a hard to track way (by reusing a production key instead of their more closely monitored access system).

I tend to stick to files, it's just more convenient and reusable. But if you're on a single user system don't worry about passing things via the command line or via envvars.

[imtringued]

>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.

[rumanator]

> 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?

[tyingq]

Also mentioned in the article, they pass down to forked processes by default.