Running docker in docker as a privileged container enables you to mount kubernetes node host filesystem and gain root access.

[willejs]

Describe the bug

Currently when you deploy the controller, it runs a docker in docker container as privileged inside the actions controller pod. This enables anyone who has access to execute commands in github actions (in pull requests for example) to mount the nodes root filesystem and read/write to the underlying hosts filesystem. You could then force push (if not disabled) to the branch and wipe out any history of this command running.

This is insecure, and if people are not aware of this, they may run this in a multi tenanted cluster and open themselfs up to potential attacks.

To Reproduce Steps to reproduce the behavior:

1. fdisk -l - Find your host disk partition to mount
2. mkdir /mnt/root
3. mount /dev/nvme0p1 /mnt/root
4. Access the root filesystem of the node.

Expected behavior There should be a warning about this such as the one in concourse ci. Perhaps a bit more explicit! Alternatively perhaps docker in docker could potentially be run without privileged true and instead some locked down selinux controls?

[toast-gear]

Alternatively perhaps docker in docker could potentially be run without privileged true and instead some locked down selinux controls?

From my knowledge docker in docker doesn't work without privileged unless something like sysbox is used https://github.com/actions-runner-controller/actions-runner-controller/discussions/977

There should be a warning about this such as the one in concourse ci. Perhaps a bit more explicit!

we could perhaps add a section outlining what you get (runner + dind) and the fact --privileged is needed as first chapter in the usage section, this could include this warning? End users really should be reviewing what they're deploying beforehand rather than just blindly deploying stuff though, or if this is a huge concern for their cluster (which it should be) they should have a pod security policy preventing privileged pods from even running.

[mumoshu]

Kata v2 is another option https://github.com/kata-containers/kata-containers/blob/main/docs/how-to/how-to-run-docker-with-kata.md. In kata, privileged means the pod's containers run in the lightweight VM are privileged so I'd say it's much safer than the standard pod container being privileged.

Alternatively perhaps docker in docker could potentially be run without privileged true and instead some locked down selinux controls?

I wish it's possible 😄 It would be great if anyone could try integrating https://github.com/msyea/github-actions-runner-rootless into ARC.

[mumoshu]

1644 by @some-natalie gives us rootless-docker-powered runners!

As @toast-gear has pointed out earlier in this thread though, it isn't going to remove privileged: true for runner containers.

However, it does allow us to provide another layer of security that makes it difficult for random actions job steps to affect the host as (1) the user that runs dockerd and the self-hosted runner agent isn't root anymore and (2)the root user within rootless-dockerd-managed containers isn't the same root user as the user of the upper-level runner container and the host.

@willejs Depending on your requirement, you might be able to use the rootless-dind-runer (#1644) or the new kubernetes container mode (#1546).

With those two new features along with a potential enhancement on our docs to more explicitly note about the security caveat, I believe this issue can be closed.

WDYT?