Security implications of Docker In Docker setup

[rajbos]

I'm trying to get a grip on the security implications of the Docker In Docker setup being used. In the readme a privileged sidecar is mentioned. From testing I see that the runner itself is running under the UID 1000 named 'runner'. Running a job in a container shows the user in the container (depending on the image off course) often runs as root (UID 0). That also means I can execute curl commands at /var/run/docker.sock and find stuff (like running containers, images available, etc.) from inside the container.

If I understand correctly, this is only limited to the information inside the DinD container, right? I cannot escape that layer as well and get access to the host of the pod (that runs both the runner and the DinD containers). Or am I misunderstanding the side car concept here?

Not that well versed on how this works in kubernetes at all, just trying to understand this a bit better.

[toast-gear]

If I understand correctly, this is only limited to the information inside the DinD container, right? I cannot escape that layer as well and get access to the host of the pod (that runs both the runner and the DinD containers). Or am I misunderstanding the side car concept here?

You pretty much have it, we don't expose the node's docker socket to the runner (or to anything) so the docker daemon you interact with is the daemon in the dind sidecar https://hub.docker.com/r/summerwind/actions-runner or in the runner itself if you use the all in one image https://hub.docker.com/r/summerwind/actions-runner-dind.

As a cluster administrator there isn't anything stopping you from configuring the runner to mount the node's docker socket of course but you would have to explicitly set that up and it looks like there may be some issues with doing that atm #72

[rajbos]

Looking further into this, I noticed that we always spin up the privileged dind container: https://github.com/actions-runner-controller/actions-runner-controller/blob/3366dc9a634563b1ae1fe303bde1f3c234af3bca/main.go#L41

That image is running as root, and we expose the docker daemon with the passing in of the DOCKER_HOST setting to the dind container, correct? That is then being used by the runner to launch a container in the dind container.

And since we can only talk to the docker daemon in the container to spin up new containers, the started container has access to the same daemon? That means someone could still get access to the daemon and get root privileges on the dind container which means that they could still break out of that container as well?

[rajbos]

To follow up on this, we're currently running with this custom dind-rootless image so that the DinD container has less rights. Seems like this is working as expected.

Some test results:

Action	Result
Docker build on the runner	Works
Run job in container: node	Works
Run job in container: python	Works
uses: docker/setup-buildx-action@v1	Fails: has not enough rights to install, which is as expected
Call docker images on the runner	Fails, which is what we want

[nascit]

@rajbos I see his defaultDockerImage propery is not exposed as a parameter. Does it mean you had to fork ARC?