I own the base image, and as such I add a root CA and I set $HTTP_PROXY to a MITM host I own.
You FROM my base image, most programs honor HTTP_PROXY (e.g. cURL) and send traffic over to me.
That ends up in runtime, so when your app uses a standard library to connect to a third party service (e.g. SendGrid, AWS…) I get to intercept all that traffic plaintext bcuz I own the root CA.
I mean, I guess once you own the base image there are tons of vectors like this, but still. Unless you’re very careful to what base images you use and their contents, this is scary.
You run a potentially arbitrary amount of unreviewed binaries in docker images, sneaking in anything unwanted is trivial. HTTP_PROXY hidden as arg is obviously a creative way, though to be honest reviewing Dockerfiles is clearly the most easy part of things that end-up inside a docker image. Security scanners on the other hand might not really look into image metadata/manifests so might be used to defeat things a little bit.
As far as attack vectors from base images go, this is minor. You’re trusting your base image packager to build your binaries in the first place. Unless you’re very careful about that, you’re open to all kinds of trouble.
I treat them like any software distribution and only get them from channels I trust as much as, say, my linux distribution itself.
As a thought experiment, I do wonder if this makes it easier for someone writing a malicious patch for an upstream package to socially engineer a maintainer into accepting a subtly backdoored patch. I don’t think so. But that’s really the only small bit of extra scare factor I see from this.
This behaves a little similar to the existing instruction ENV, which, for RUN instructions at least, can also be interpolated, but can’t (I don’t think) be set at build time
The ENV instruction sets the environment variable to the value . This value will be in the environment for all subsequent instructions in the build stage (…)
The environment variables set using ENV will persist when a container is run from the resulting image.
A stage inherits any environment variables that were set using ENV by its parent stage or any ancestor.
So, setting ENV at build time effectively sets a default value for a variable.
The interaction between ARG and ENV might be spooky - but I don’t think one is worse than the other?
Set them to document ENV vars that should/can be set at runtime?
Wow! Didn’t know that. Thanks!
Could this be a security problem? Imagine:
That ends up in runtime, so when your app uses a standard library to connect to a third party service (e.g. SendGrid, AWS…) I get to intercept all that traffic plaintext bcuz I own the root CA.
I mean, I guess once you own the base image there are tons of vectors like this, but still. Unless you’re very careful to what base images you use and their contents, this is scary.
You run a potentially arbitrary amount of unreviewed binaries in docker images, sneaking in anything unwanted is trivial.
HTTP_PROXYhidden asargis obviously a creative way, though to be honest reviewingDockerfilesis clearly the most easy part of things that end-up inside a docker image. Security scanners on the other hand might not really look into image metadata/manifests so might be used to defeat things a little bit.As far as attack vectors from base images go, this is minor. You’re trusting your base image packager to build your binaries in the first place. Unless you’re very careful about that, you’re open to all kinds of trouble.
I treat them like any software distribution and only get them from channels I trust as much as, say, my linux distribution itself.
As a thought experiment, I do wonder if this makes it easier for someone writing a malicious patch for an upstream package to socially engineer a maintainer into accepting a subtly backdoored patch. I don’t think so. But that’s really the only small bit of extra scare factor I see from this.
I’ve been using lowercase names for ARG. Seems good to continue, since environment variable names tend to be uppercase.
Not sure what op means by:
https://docs.docker.com/engine/reference/builder/#env
So, setting ENV at build time effectively sets a default value for a variable.
The interaction between ARG and ENV might be spooky - but I don’t think one is worse than the other?
Set them to document ENV vars that should/can be set at runtime?
I’m talking about interpolating the value of env vars into a docker command. For example
The substitution takes place before the command is run.