fix(GH-2284): Put docker:dind in proper cgroup parent

[marverix]

Hello,

This PR is fix for ticket openeded since 2023: #2284 .

The idea is to use dockerd cgroup-parent flag to put dind containers in proper control groups.

[Copilot]

Pull request overview

This PR aims to address GH-2284 by configuring the Docker-in-Docker (docker:dind) daemon to place nested Docker containers under the runner Pod’s cgroup via dockerd --cgroup-parent, improving cgroupv2 resource accounting/limits behavior.

Changes:

• Add a --cgroup-parent=... flag to the dind dockerd args.
• Inject the Pod UID into the dind container via the Downward API (metadata.uid) for use in the cgroup parent path.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[marverix]

@copilot apply changes based on this feedback

[fstr]

This patch works, but the containers started via the dind docker process are only able to read the docker sidecar container cgroupv2 slice (or pod level resource if you run on Kubernetes 1.34+ and set pod memory limits) if --default-cgroupns-mode=host is set.

This allows the dind created nested cotainer to see the full cgroup tree of the host and find its parent cgroup (the pod or container cgroup).

Using --default-cgroupns-mode=host leaks some information into the runner about what else runs on the system, which is useful information to an attacker if the runner is compromised, so use with care.

[marverix]

After deeper investigation this will not work properly. There are 2 reasons:

• As Copilot pointed out, this will work only for burstable Pods, so it must be more generic
• 2nd, more problematic, is the docker:dind image itself. This image contains /usr/local/bin/dind bash script, which is doing amendments in /sys/fs/cgroups. To be more precise: it moves processes around. If you run one runner (with dind) it's let's say all right, although I despise the idea of such hacks when the dind has privileged rights. But when number of runners, using the same scrips, all having root privileges, trying to tinker around on hosts's /sys/fs/cgroups... it's a nightmare. In our company we ended forking docker:dind , and creating own image that supports K8s cgroups v2.

I don't see much option rather than github arc going the same direction: to have own dind image with modified dockerd-entrypoint and dind.

After modifications, all OOM issues on nodes ended in our company. Previously it was "WTF" all the time.