Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t use environment variables for configuration

nibblestew.blogspot.com

Post reply on HN
Print view View original

171–180 of 296 posts

Re: Don’t use environment variables for configuration

#171

Post by jayd16 »

CGamesPlay wrote: post #128
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…

> Perhaps the ideal tool would allow every option to be set/changed from config file, environment and argument. This is exactly what the most widely used golang configuration library does: https://github.com/spf13/viper

Its also what most of the entrprisey frameworks do. Spring will do this and I'm pretty sure ASP.NET has some form of it.

Re: Don’t use environment variables for configuration

#172

Post by PeterisP »

hajile wrote: post #162
yrro wrote: post #145

Earlier quoted context omitted.

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…

It's also easier to encrypt a config file and provide the decrypt key externally.

So then the real secret is the key, which is provided "externally" ... how? Through command line parameters, some other config file, or environment variables? :P

Re: Don’t use environment variables for configuration

#173

Post by whatshisface »

0xEFF wrote: post #167
intrepidhero wrote: post #150

Earlier quoted context omitted.

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

What better place is there to store credentials?

Store a path to the top secret file in an environment variable, and have the program read the credentials out of the file. Put the file somewhere far away from the repo, on the deployed filesystem.

Re: Don’t use environment variables for configuration

#174

Post by phtrivier »

If you don't mind, I'll keep doing the relatively sane thing: using env variable at the startup of my applications (and, as much as possible, never anywhere else), among other configuration sources (like text files), to create a struct / object / dict / whatever that represents the configuration, and that the rest of my code uses.

If you see someone using `os.env["xxx"]` as an escape hatch for a mutable global variable, then, yes, it's probably not a good idea. But it's not configuration anymore, it's runtime state.

(Although I suppose no one is going to hit HN front page by writing an article titled "Don't use global mutable state", except to make game programmers giggle ?)

Re: Don’t use environment variables for configuration

#175

Post by junon »

darkwater wrote: post #71
junon wrote: post #51

Earlier quoted context omitted.

100% this. The developer behind Prometheus was a huge dick to people about env vars a while back, in similar fashion. Just the other day, they held another closed-doors vote after a year or so and finally decided they were OK. Doesn't surprise me the creator of Meson of all people made the same dogmatic assertion. What a circus this industry has become.

Any link about that? Are you talking about this? https://github.com/prometheus/prometheus/issues/6047#issueco...

This was the original discussion that spanned quite a long time. https://github.com/prometheus/prometheus/issues/2357

Re: Don’t use environment variables for configuration

#176

Post by OJFord »

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'…

I used to agree with (2), but now I think Meh, it's an implementation detail whether the program uses my environment variable 'directly' or with a child process, it's not meaningful to make that distinction.

When it is meaningful (and this is supported today) is to set them just for specific programs/invocations, rather than exporting for a long-running interactive shell (and everything within it) willy-nilly.

More innovation around making that easier would be interesting, env vars that should be set specified by program, isolated from others, for example. So `foobar` would actually get executed like `FOO_SECRET=hunter2 foobar` without specifying it every time or having it exported in the shell, and in a generic way not specific to each program's config.

It's not really related but for some reason 'summon' is on my mind as a tool to mention. I haven't used it in anger yet, but it is interesting. It's not quite this though, or at least, it solves only the 'storage' part of the implementation of what I described, not the 'orchestration' or mapping of programs to vars/summon invocations.

Re: Don’t use environment variables for configuration

#177

Post by PeterisP »

yrro wrote: post #166
bopbeepboop wrote: post #156

Earlier quoted context omitted.

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

Good point about command line arguments being often automatically logged! So they bad for both reasons :) Now, if you're running in k8s then you can improve your setup by mounting your secret into your container, and have your code read the credentials from the file within the mount. This just looks like another kind of config file to me :)

Embedding secrets (which should be changeable and with limited access) into container images (which should be reproducible and perhaps stored in accessible locations) sounds like not a goood idea; IMHO you definitely need the capability to have the same container use different credentials so that, for example, you can run the same container in a development or testing environment as in production, but with different credentials.

Re: Don’t use environment variables for configuration

#178

Post by jayd16 »

hjek wrote: post #142
junon wrote: post #50

Oh this guy again. This guy created Meson and has a pattern of being 1) Quite toxic and 2) Entirely dogmatic when it comes to software design. He shows no interest in discussing design problems with Meson and asserts his viewpoints as truth and fact, resorting to snide comebacks instead of having thoughtful conversation. Doesn't surprise me he wrote an article like this. Completely misguided and isn't rooted in reali…

Okay, so when you write that this blog author, who made a post arguing how environmental variables are global mutable state, is quite toxic and resorting to snide comebacks instead of having thoughtful conversation, then that is just you engaging in thoughtful conversation about the issue (which is envvars), and not you making a toxic ad-hominem attack at all, right?

I would say at least the comments about dogma and tone are relevant in the current context.

Re: Don’t use environment variables for configuration

#179

Post by falcolas »

0xEFF wrote: post #167
intrepidhero wrote: post #150

Earlier quoted context omitted.

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

What better place is there to store credentials?

A config store like Vault. Of course, that needs credentials too, which are typically a file on the file system.

IMO, people are overly sensitive about environment vars. They are really no worse than files on the file system - both can be accessed if you're a privileged user on that machine.

Re: Don’t use environment variables for configuration

#180

Post by [deleted] »

edem wrote: post #59
magicalhippo wrote: post #54

Earlier quoted context omitted.

I have no skin in this game, so to speak, so just curios. What kind of ways did you get burned by other things than env vars in a way in which env vars would not?

Mostly configuration stored in the database (who configures the database) or 3rd party configuration services without an SLA and config files that are either present or not. Env vars are really simple since they are completely decoupled from the app and you can have default values for all of them. You just need a single class that loads all config on startup and you can go from there (or fail if you don't have the ma…

[deleted]
Post reply on HN