What are the advantages of putting secret values of a website as environment variables?

The author lists their reasoning, although it’s a bit disjoint. Their primary argument is that it’s easy to accidentally check in a config file, and that config files have varying formats and may be scattered around the system (all three of which are at best mediocre arguments for security related config like auth tokens and credentials).

Given my own experience, you’ve essentially got the following three options, with associated advantages and disadvantages:

Store the data in config files.

When taking this approach, you should ideally isolate them from the repository itself, and make sure they’re outside of the area that the app stores it’s content in.

Advantages:

• Very easy to isolate and control access to, especially if you’re using things like SELinux or AppArmor to improve overall system security.
• Generally easy to change for non-technical users (this is an advantage for published software, but not necessarily for software specific to your organization).
• Easy to manage across large groups of servers. There’s all kinds of tools for configuration deployment out there.
• Reasonably easy to verify what the exact configuration being used is.
• For a well written app, you can usually change the configuration without interrupting service by updating the config file and then sending a particular signal to the app (usually SIGHUP).

Disadvantages:

• Proper planning is needed to keep the data secure.
• You might have to learn differing formats (though these days there’s only a handful to worry about, and they generally have similar syntax).
• Exact storage locations may be hard-coded in the app, making deployment potentially problematic.
• Parsing of the config files can be problematic.

Store the data in environment variables.

Usually this is done by sourcing a list of environment variables and values from the startup script, but in some cases it might just state them on the command-line prior to the program name.

Advantages:

• Compared to parsing a config file, pulling a value out of an environment variable is trivial in pretty much any programming language.
• You don’t have to worry as much about accidentally publishing the configuration.
• You gain some degree of security by obscurity because this practice is uncommon, and most people who hack your app aren’t going to think to look at environment variables right away.
• Access can be controlled by the application itself (when it spawns child processes, it can easily scrub the environment to remove sensitive info).

Disadvantages

• On most UNIX systems, it’s reasonably easy to get access to a process’s environment variables. Some systems provide ways to mitigate this (the hidepid mount option for /proc on LInux for example), but they aren’t enabled by default, and don’t protect against attacks from the user who owns the process.
• It is non-trivial to see the exact settings something is using if you handle the above mentioned security issue correctly.
• You have to trust the app to scrub the environment when it spawns child processes, otherwise it will leak information.
• You can’t easily change the configuration without a complete restart of the app.

Use command-line arguments to pass in the data.

Seriously, avoid this at all costs, it’s not secure and it’s a pain in the arse to maintain.

Advantages:

• Even simpler to parse than environment variables in most languages.
• Child processes don’t automatically inherit the data.
• Provides an easy way to quickly test out particular configurations when developing the application.

Disadvantages:

• Just like environment variables, it’s easy to read another process’s command-line on most systems.
• Extremely tedious to update the configuration.
• Puts a hard limit on how long the configuration can be (sometimes as low as 1024 characters).