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

251–260 of 296 posts

Re: Don’t use environment variables for configuration

#251

Post by jillesvangurp »

q3k wrote: post #97
jillesvangurp wrote: post #60

Earlier quoted context omitted.

Yes. If you package software up for deployment on some server (i.e. you use something like Docker), environment variables are the easiest/only configuration mechanism at your disposal. Packages that don't support this, need some workarounds (e.g. dockerize to template some config file using environment variables) to be packaged up; which is annoying and extra work. Decent server software comes prepackaged in docker f…

> Dedicated configuration files only make sense if you assume a writable file system is there. I disagree. It's pretty typical in containerized environments (in my experience) to pass in (eg. mount) a config generated by whatever configuration management system into a container for it to load its configuration from. This has the following advantages over env var configs: - support for more complex expressions than st…

Writable file systems are needed for things that are stateful but inappropriate otherwise.

Re: Don’t use environment variables for configuration

#252

Post by emj »

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.

You can disable access the possibility to read the memory of other processes and you can do it for environment variables. Storing access tokens in memory is more obscure than environment variables, that is true though.

Re: Don’t use environment variables for configuration

#253

Post by danielhlockard »

KptMarchewa wrote: post #221
falcolas wrote: post #179

Earlier quoted context omitted.

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.

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?

Re: Don’t use environment variables for configuration

#254

Post by OJFord »

jschwartzi wrote: post #249
OJFord wrote: post #176

Earlier quoted context omitted.

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

This is pretty much how systemd works. You can specify secrets that are retrieved from somewhere else and provided to the process in the environment it is started with. So you could do exactly this with the right unit configurations.

Ha, funnily enough I mentioned systemd and then deleted it. I do run as much like that as possible, I just couldn't succinctly explain why I thought it was different or better than putting:

    VAR=whatever process
in .xinitrc or wherever.

Re: Don’t use environment variables for configuration

#255

Post by bmh100 »

ajarmst wrote: post #144

This attitude is how we ended up with Active Directory. One assumes that the author doesn't spend much time in a command-line environment. The option to set defaults for one's normal working environment is obviously of value, and environment variables are hardly exclusive of configuration files (~/.bashrc, makefiles, ...). The theory that complex syntax and statelessness are inherently good and cost-free is naïve to…

What do you mean about Active Directory?

Re: Don’t use environment variables for configuration

#256

Post by [deleted] »

prussian wrote: post #77
neolog wrote: post #24

> An environment variable can only contain a single null-terminated stream of bytes. This is very limiting. The same is true of command-lines and files. Computers can only use bytes.

A files' contents are not effectively smuggled just because halfway through a file a NUL is in it, unlike environment or arguments.

[deleted]

Re: Don’t use environment variables for configuration

#257

Post by amelius »

gnulinux wrote: post #205
kodah wrote: post #187

Earlier quoted context omitted.

On the facade environment variables may seem like they're orthogonal to global variables but they're not. Environment variables are scoped to the current process. This could be your shell, but it could also be a web server. This doesn't make them leak proof, but unlike global variables, environment variables have a scope. Environment variables are also used more widely as an API. Many CLIs have a command that when se…

I don't get this. From the same perspective you can argue global variables have scope too since they are "scoped to the current process". It's not like other processes can access your global variable, that's a very low bar for a scope.

> It's not like other processes can access your global variable, that's a very low bar for a scope.

They can read them, in /proc/[PID]/environ

Re: Don’t use environment variables for configuration

#258

Post by haolez »

orthecreedence wrote: post #224
haolez wrote: post #93

Earlier quoted context omitted.

Make doesn't work like that.

Wait, make has a global state? I was under the impression most make targets are stored somewhere in the project itself (like a build/ directory). I think this is a fine approach, BTW. I think global state should be avoided unless necessary.

Make does what you tell it to do. While some projects have the setup that you've described, many others do not. Make will only check the timestamps of the generated assets and decide to build (or not) based on that.

Re: Don’t use environment variables for configuration

#259

Post by tylerchr »

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?

You could, but then you’ll have replaced a universal and standardized abstraction with a hard commitment to one very specific approach. That doesn’t come cheap.

Re: Don’t use environment variables for configuration

#260

Post by OJFord »

Lvl999Noob wrote: post #245
OJFord wrote: post #176

Earlier quoted context omitted.

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

Iiuc you are advocating for setting env vars at the call site, like `FOO_SECRET=hunter2 foobar`? In that case, why not just use command-line args and call it like `foobar --secret=hunter2`?

I wasn't advocating for it in preference to args, but there are circumstances where that's not possible, for example calling some CI/CD tool (say terraform, ansible, fabric, whatever) that doesn't consume the var itself but uses something that does.

It's also a more convenient/already generic interface for doing something consistent across multiple programs.

Post reply on HN