Don’t use environment variables for configuration • Hacker News Board

Re: Don’t use environment variables for configuration

#151

Post by Macha » Thu, Apr 01, 2021, 3:00 PM UTC

throw14082020 wrote: post #104

The author says: // to call it you'd do first_argument = 1; second_argument = 2; int three = add_numbers(); This is, I trust you all agree, terrible. This approach is plain wrong. I agree, but I don't think everyone agrees. Just have a look at the apple APIs, their configuration options are all objects you have spend time configuring, then pass as an argument. I don't know why everything with Apple development beats…

I think you're objecting to different things than the author.

The author is complaining that there's no link or information that first_argument or second_argument are used by add_numbers.

In comparison, in the Apple API example you've given, addRequest is explicitly provided to perform.

What you appear to be objecting to is setting up potentially complicated config objects to pass rather than passing simpler arguments.

Re: Don’t use environment variables for configuration

#152

Post by darksaints » Thu, Apr 01, 2021, 3:07 PM UTC

intrepidhero wrote: post #150

yrro wrote: post #131

Earlier quoted context omitted.

Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive'…

Isn't storing credentials in environmental variables bad practice to begin with?

Compared to what?

Re: Don’t use environment variables for configuration

#153

Post by yrro » Thu, Apr 01, 2021, 3:08 PM UTC

intrepidhero wrote: post #150

yrro wrote: post #131

Earlier quoted context omitted.

Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive'…

Isn't storing credentials in environmental variables bad practice to begin with?

Yes, for those reasons

Re: Don’t use environment variables for configuration

#154

Post by xaduha » Thu, Apr 01, 2021, 3:08 PM UTC

Keep it in one place and have an easy way to disable setting configuration through ENV variables altogether. Don't let it get out of hand by sprinkling it everywhere, that's all.

Re: Don’t use environment variables for configuration

#155

Post by bayindirh » Thu, Apr 01, 2021, 3:12 PM UTC

hjek wrote: post #130

bayindirh wrote: post #76

I have a pet peeve about this attitude. These methods are being used for decades and well understood with all their advantages and disadvantages. One day, someone comes and tells that it's bad and considered harmful , and happily tells the only right way to do it . A flame war ensues then. I'm all for moving things forward and evolution, but can't we take a milder stance and move forward in a more peaceful way? Attac…

> Attacking something so well established because of personal reasons feels so wrong from my PoV. That is a mischaracterization of the post. The author is making a clear technical point about how environmental variables are global mutable state. Labeling that as an "attack because of personal reasons" is just plain misleading. > That thing wouldn't be a de-facto standard if it was too bad, right? How much of the post…

> That is a mischaracterization of the post.

I don't think so. First of all, as I detailed in [0] and [1], my central point of disagreement is the tone and attitude of the post, not the usage of environment variables itself.

There are a lot of scenarios where environment variables makes a lot of sense, and scenarios where using them is absolute madness as we discussed with q3k in [1].

> How much of the post did you read?

All of it. BTW, please remember asking this question is directly against guidelines [2] (sec: In comments, guideline 8).

> Your point is almost exactly the same as the 3rd listed in the post: 3. "This is the way we have always done it so it must be correct!"

As I said in my other comments, I do not directly support the exact opposite of the author's stance. My disagreement is in the tone and rigidity of viewpoint. To quote myself:

I'm not calling this is good with the persistence of the original author. I tell that it's one of the realities that we have, and instead of burning it with torches, why not build better conventions around it with better attitude and language?

Please see [0] and [1] for further clarification.

[0]: https://news.ycombinator.com/item?id=26660409

[1]: https://news.ycombinator.com/item?id=26660553

[2]: https://news.ycombinator.com/newsguidelines.html

Re: Don’t use environment variables for configuration

#156

Post by bopbeepboop » Thu, Apr 01, 2021, 3:12 PM UTC

yrro wrote: post #145

bopbeepboop wrote: post #139

Earlier quoted context omitted.

How do command line arguments or config files solve either problem?

Command line arguments aren't inherited by child processes. Unfortunately they are visible to other users on the system, so they're no good for credentials. Config files (or an abstraction of them such as reading config data from a socket), after parsing, result in some credentials sitting in the memory of the process that needs them. They aren't in the environment block, so a quick and dirty "dump all my environment…

> Unfortunately they are visible to other users on the system, so they're no good for credentials.

If you’re concerned about your own software logging credentials, command line arguments are negative in two regards:

They’re highly visible when the process is running; they’re often automatically logged.

> They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them.

Okay — but the usual way that happens is “dump my config object in a log”, which parsed configs don’t help with.

You also now have a config file: how is it stored? ...is it in the repo? ...what are the permissions? ...how do we deploy it?

Environment variables don’t persist in repos and are designed to be integrated with hosting tools, like secrets managers.

I’m not seeing how a config file beats Kubernetes injecting from the secret store, which is why we use environment variables: so our tools (secret stores) can configure the environment our software uses.

Re: Don’t use environment variables for configuration

#157

Post by marcrosoft » Thu, Apr 01, 2021, 3:13 PM UTC

mrkeen wrote: post #15

Easy fix (if it's the shared, mutable state which bugs you): * Create one class responsible for ingesting env vars at startup. * Call it from main, and abort early with nice messages if it fails to read something. * Now you have a nice (preferably immutable) class which guarantees the config is in a 'good state', and is self-documenting because it lists all the keys it uses to lookup env vars with.

The mutable state can be helpful. It is sometimes helpful to be able to change an app’s config without having to restart it. Ingesting the envs on startup into a class removes this ability.

Re: Don’t use environment variables for configuration

#158

Post by npsimons » Thu, Apr 01, 2021, 3:13 PM UTC

yrro wrote: post #131

zajio1am wrote: post #106

Strongly disagree. Environment variables are, IMHO, best tool for some simple configuration in unix. They match perfectly with behavior of the ecosystem and other tools in it (like unix shell). Yes, if your OS is some unversal JS machine, then JSON would be better, if it is Lisp machine, then you would use S-expressions, but on Unix machine, environment/args are way to go. There are two realistic alternatives - confi…

Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive'…

My first thought on the headline are specialized concerns of the above: environment variables are an attack surface. If you use them for configuration, it's all too easy for an attacker to modify them without the victim knowing. Just look at issues with LD_PRELOAD: https://attack.mitre.org/techniques/T1574/006/

That said, I agree with GP that environment variables are super useful and super simple. But I've also been burned more than a couple of times by setting something in the past and then having it caused unexpected bugs that are hard to trace down as they aren't in my working memory. They're a double-edged sword, to be sure.

Re: Don’t use environment variables for configuration

#159

Post by _greim_ » Thu, Apr 01, 2021, 3:16 PM UTC

I don't mind environment variables for config, but it really bugs me when libraries read them. I'd much prefer to front-load them into my app's entrypoint where I can see and control them.

Re: Don’t use environment variables for configuration

#160

Post by jrwr » Thu, Apr 01, 2021, 3:16 PM UTC

intrepidhero wrote: post #150

yrro wrote: post #131

Earlier quoted context omitted.

Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive'…

Isn't storing credentials in environmental variables bad practice to begin with?

depends on who you are talking to, since you run the risk of committing the creds to a git repo