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

Re: Don’t use environment variables for configuration

#281

Post by HelloNurse » Fri, Apr 02, 2021, 12:23 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'…

1. If your program is chatty, it can be chatty in the same way regardless of where the improperly logged secrets come from; it's still your fault for being coarse and lazy. There's little difference between logging all environment variables(and/or all command line parameters) and logging the whole configuration object.

2. If your child processes shouldn't inherit environment variables, set them properly. The "ghosts of Unix past" have "foreseen the need" for execve(2) and execveat(2), which don't pass anything by "default".

Re: Don’t use environment variables for configuration

#282

Post by victorNicollet » Fri, Apr 02, 2021, 1:18 PM UTC

I have only very rarely used environment variables in my own software over the last 20 years. The argument for their use that I have heard the most frequently has been "you would have to be an idiot to not use them" which has thus far failed to convince me. That, and its little brother "you must never have pushed anything to production" seem to find some echo in this thread.

From what I could gather, the actual reasons that Other People use environment variables seem to be:

- Other People use some tool for a reason unrelated to environment variables, and that tool happens to make environment variables extremely easy or convenient. A more pessimistic alternative: that tool makes everything inconvenient except for environment variables. Whatever that tool may be, I suspect that I am not using it.

- Other People write programs that are invoked (I write programs that run continuously), and environment variables improve the ease with which programs can be invoked, which is a concept I never have to deal with.

My programs load their configuration from files at startup ; configuration files are committed to git and included in the build ; secrets live in a remote key vault, with a local cache in case of unavailability. Maybe in the future, I will discover something that environment variables greatly improve about this. I don't know.

Re: Don’t use environment variables for configuration

#283

Post by michaelmior » Fri, Apr 02, 2021, 2:22 PM UTC

kodah wrote: post #271

michaelmior wrote: post #248

Earlier quoted context omitted.

> Environment variables are scoped to the current process. Obviously this is true in a sense. But for practical purposes, it depends on how the environment variables are set. For example, if I set them in my ~/.bash_profile, they're scoped to all bash processes that my current user runs. If I put them in /etc/profile, they're effectively global.

Depending on the variable, sure, but that's a wide latitude in the interpretation of "global". They're not linked or the same memory in any form or fashion. They're merely identical in value.

True. I was thinking in the context of software deployments where environment variables are commonly used as read-only configuration values once the deployment is made.

Re: Don’t use environment variables for configuration

#284

Post by 0xEFF » Fri, Apr 02, 2021, 2:32 PM UTC

danielhlockard wrote: post #253

KptMarchewa wrote: post #221

Earlier quoted context omitted.

Vault should be source of those env variables. Via some predefined initcontainer or something like that, to which devs don't have access to.

Or you could, you know, auth to vault and pull the creds from vault inside of your app?

How do you auth to vault?

Re: Don’t use environment variables for configuration

#285

Post by fatnoah » Fri, Apr 02, 2021, 2:37 PM UTC

erulabs wrote: post #6

I disagree with this post so strongly - having spent most of my career installing, configuring, and managing other people’s software. > The answer is that you, the end user, can not now. Every program is free to do its own thing and most do. If you have ever spent ages wondering why the exact same commands work when run from one terminal but not the other, this is probably why. If the same program is behaving differe…

>If the same program is behaving differently between two systems - it can -only- be the environment that’s different.

As a developer, I've generally used configuration files for changing the operation of my software and environment variables for information my code needs to know about WHERE the code is running. For example, the same code doing the exact same thing on 10 machines would have the same configuration file (or command line parameters in simpler cases) but the environment variables may change from machine to machine.

Re: Don’t use environment variables for configuration

#286

Post by 0xEFF » Fri, Apr 02, 2021, 2:38 PM UTC

LanternLight83 wrote: post #181

0xEFF wrote: post #167

Earlier quoted context omitted.

What better place is there to store credentials?

Via either program config files, an inline subshell calling cat, or ssh-agent in that specific case, to keep credentials both out of the environment, and off of the command-line where it can be read by inspecting the resulting process for it's invocation.

All of those places can also be read.

SSH agent is a good example. It’s effectively an environment var which is why this works fine:

  sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK git clone ...

Edit:

The reason I think it’s silly to make a blanket statement environment vars are bad is because too many containers have credentials baked into the image when they should be passed in another way.

Re: Don’t use environment variables for configuration

#287

Post by josephcsible » Fri, Apr 02, 2021, 4:06 PM UTC

yrro wrote: post #132

kerny wrote: post #39

Earlier quoted context omitted.

Any third party code can just read your credentials file and POST it to remote server.

Bold of you to assume my third party code runs with the same UID and SELinux label as my credentials-handling code. (I wish, it's April 1 after all!)

If the third party code runs with a different UID, then it can't read the environment either.

Re: Don’t use environment variables for configuration

#288

Post by josephcsible » Fri, Apr 02, 2021, 4:07 PM UTC

yokaze wrote: post #43

kerny wrote: post #39

Earlier quoted context omitted.

Any third party code can just read your credentials file and POST it to remote server.

File permissions allow finer granularity of access control. Environment variables are visible to any user in the system.

> Environment variables are visible to any user in the system.

This is completely false in any modern OS. You can only see environment variables of your own processes.

Re: Don’t use environment variables for configuration

#289

Post by josephcsible » Fri, Apr 02, 2021, 4:22 PM UTC

AzzieElbab wrote: post #102

sure env vars are overused. some values simply do not belong in the environment, for example - credentials. however, i havent seen a more convenient method of injecting configuration dynamically without some error prone file watching mechanics

Why don't credentials belong in the environment? They're definitely not visible to other users there, as opposed to on the command line where they definitely are, or in a file where they can be if you don't set the permissions correctly.

Re: Don’t use environment variables for configuration

#290

Post by rascul » Fri, Apr 02, 2021, 11:46 PM UTC

yrro wrote: post #278

rascul wrote: post #270

Earlier quoted context omitted.

> I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive' and 'noexport', allowing them to opt out of the default behaviour. The default behavior is a non-exported variable. If you want child processes to see it, you must export it.

There is no such thing as an exported or non-exported environment variable. In fact, as the kernel is concerned, there is no such thing as an environment _variable_ at all, just a block of data. See execve(2): "envp is an array of pointers to strings, conventionally of the form key=value, which are passed as the environment of the new program. The envp array must be terminated by a NULL pointer." You can confirm this…

I guess I assumed you were referring to environment variables in the context of the shell. Apparently I was incorrect.