3 ms·

This is not Docker related. If an application spawns a sub-process, that sub-process will inherit all environment variables. Which might be fine or might not b

This is not Docker related. If an application spawns a sub-process, that sub-process will inherit all environment variables. Which might be fine or might not be, e.g. if the spawned application is user controlled. Also tools such as Airbrake or Sentry often send all your ENV variables to the error collection server, effectively exposing your secret values. Most such tools offer to filter variables, but that's in my experience almost always not done pro-actively. The only thing that's Docker related in that post is that it does offer a turn-key solution for Docker-based projects. The solution's principle can be applied to other projects though, i.e. secrets should be read from a config file (or something like Vault).

linkdd 6y ago
I wonder why you would run a user supplied application without sandboxing it (reset env, user with almost no permissions, ...)
bluejekyll 6y ago
> If an application spawns a sub-process, that sub-process will inherit all environment variables. ...“by default”, specifying the environment is something you do when creating a new process.
chme 6y ago
> If an application spawns a sub-process, that sub-process will inherit all environment variables. Which might be fine or might not be, e.g. if the spawned application is user controlled. Right. But isn't that well known? Of course you have to explicitly define which environment variables are passed through to the process you are going to spawn, just as you would have to drop permissions to (configuration) files and possible limit capabilities if you start spawning untrusted processes. IDK... For me it make sense that you should not give secrets over the command line, because they will appear in the program listings, but environment variable is pretty much ok in many cases.
rumanator 6y ago
> Also tools such as Airbrake or Sentry often send all your ENV variables to the error collection server, effectively exposing your secret values. That only happens if whoever deployed those services screwed up badly and failed to configure any kind of filtering. I mean, airbrake specifically refers to their filtering system as best practices to avoid leak sensitive data. https://airbrake.io/product/security https://airbrake.io/product/security You're not commenting on a problem with env variables. You're commenting how poorly deployed and configured logging services can leak secrets.

linkdd 6y ago

I wonder why you would run a user supplied application without sandboxing it (reset env, user with almost no permissions, ...)

bluejekyll 6y ago

> If an application spawns a sub-process, that sub-process will inherit all environment variables. ...“by default”, specifying the environment is something you do when creating a new process.

chme 6y ago

> If an application spawns a sub-process, that sub-process will inherit all environment variables. Which might be fine or might not be, e.g. if the spawned application is user controlled. Right. But isn't that well known? Of course you have to explicitly define which environment variables are passed through to the process you are going to spawn, just as you would have to drop permissions to (configuration) files and possible limit capabilities if you start spawning untrusted processes. IDK... For me it make sense that you should not give secrets over the command line, because they will appear in the program listings, but environment variable is pretty much ok in many cases.

rumanator 6y ago

> Also tools such as Airbrake or Sentry often send all your ENV variables to the error collection server, effectively exposing your secret values. That only happens if whoever deployed those services screwed up badly and failed to configure any kind of filtering. I mean, airbrake specifically refers to their filtering system as best practices to avoid leak sensitive data. https://airbrake.io/product/security https://airbrake.io/product/security You're not commenting on a problem with env variables. You're commenting how poorly deployed and configured logging services can leak secrets.