actions
[Security] Improve secureness of dind root containers with "User Namespaces" feature.
What would you like added?
Because the DinD (Docker-in-Docker) pod runs as root, it should leverage Kubernetes “User Namespaces” for better isolation and security (see https://kubernetes.io/docs/tasks/configure-pod-container/user-namespaces/).
Enabling this feature only requires adding the field hostUsers: false to the pod template, for example here: https://github.com/actions/actions-runner-controller/blob/master/charts/gha-runner-scale-set/templates/autoscalingrunnerset.yaml#L157
Why is this needed?
User Namespaces are a new Kubernetes security feature that significantly reduces the risk of privilege escalation. Security is a must-have. 😊
Additional context
• The spec.hostUsers field is available starting with Kubernetes 1.30 (to be confirm) • Setting hostUsers: false activates User Namespaces only if clusters support them; otherwise clusters the field is simply ignored, so compatibility is maintained.
Good suggestion to fix the VULN, I tried enabling this while doing a POC but I am getting below error post configuring hostUsers: false and the runner pod was unable to start.
Warning FailedCreatePodSandBox 5s (x7 over 90s) kubelet Failed to create pod sandbox: the handler "" is not known
I will not recommend to enable it yet as default template as not all hosts supports user namespace isolation. Was trying it in EKS v1.33 with osImage: Amazon Linux 2023.8.20250721 and the error was
Warning FailedCreatePodSandBox 3s kubelet Failed to create pod sandbox: can't set `spec.hostUsers: false`, runtime does not support user namespaces
Same for osImage: Bottlerocket OS 1.44.0 (aws-k8s-1.33) with user namespace activated by
[settings.kernel.sysctl]
"user.max_user_namespaces" = "16384"
and error is [rootlesskit:parent] error: failed to setup UID/GID map: newuidmap 33 [0 1001 1 1 100000 65536] failed: newuidmap: write to uid_map failed: Operation not permitted
True, it's easier to keep the default as-is for now, but still it would be nice to be able to enable user namespace usage directly from chart.
As mentioned, this would be crucial especially for DinD usage, but also improve security in general.
Not sure if (at least at first stage) there would be need to implement any automation to recognize if cluster supports user namespaces or not, as default would be not to use those.
Hi there.
I think that k8s user namespace is nice too, but what's the difference of dind rootless ?
https://docs.docker.com/engine/security/rootless/#how-it-works https://docs.github.com/en/enterprise-cloud@latest/actions/tutorials/use-actions-runner-controller/deploy-runner-scale-sets#example-running-dind-rootless
Rootless docker also run in user namespace, so it can isolate between host and container root user.
@air-hand it's not that straight forward, as the docs you pasted still have privileged: true set. So even it partially works at user namespace, container still has privileges also on host level. And this is something that user namespaces (hostUsers: false) would help, that even privileges are given they are not host privileges.
I just closed the PR, as failed to see earlier that template.spec already passes through so that with current version it's already possible to set template.spec.hostUsers: false and get runner to run on user namespace (as long as underlying host supports that)
@Hi-Fi
Thanks for explanation. I understood that combine hostUsers: false and dind-rootless could more securely.
Any recommendations for current pre-built AMI's/OS's that currently support all the required features..or examples of building your own?
If Im understanding them correctly:
- Linux 6.3 kernel
- Filesystems that can be used :
btrfs, ext4, xfs, fat, tmpfs, overlayfs - OCI runtime support of either : crun version 1.9 or greater (it's recommend version 1.13+)...or...runc version 1.2 or greater
- CRI container runtime (to use user namespaces with Kubernetes) either: containerd: version 2.0 (and later)...or...CRI-O: version 1.25 (and later)
