Teams often assume rootless Docker in Docker removes the core risk, but it still requires privileged Kubernetes mode. Running the runner and daemon as non root lowers exposure, yet the pod remains privileged and the runner cannot install tools dynamically during jobs. That shifts more responsibility to the base image and increases operational overhead.
Why the “rootless” label is only part of the security story
In arc, the real mistake is treating rootless Docker in Docker as if it removes the need for a privileged execution path. It reduces some exposure by running the daemon and runner processes as non root, but the pod still depends on Kubernetes privileged mode, so the boundary shifts rather than disappears. For container-runtime risk, the useful question is what authority remains in the pod and what workload can reach it through the build path.
That is why teams should think in terms of control reduction, not control elimination. Rootless mode can narrow the impact of a compromise inside the container, but it does not make the runner equivalent to an unprivileged workload. The security model still depends on the cluster’s privilege decision, the base image, and how much trust you place in whatever tools and binaries are already present in that image.
When practitioners compare this with broader container guidance, the same pattern shows up: the runtime surface matters as much as the image surface. NIST’s NIST SP 800-190 Container Security is a useful reference because it treats image, registry, orchestrator, and runtime choices as linked controls, not isolated settings. The practical takeaway is to review the whole execution chain, not just the root user inside one container.
Why tool installation and base-image discipline become the trade-off
The second common error is assuming a runner can stay flexible in the same way as a privileged DinD setup. In rootless ARC, the runner cannot freely install tools during jobs, so the base image becomes the real dependency surface. That changes the operational model: instead of appending tools on demand, teams need a curated image with known versions, predictable maintenance, and clear ownership for updates.
This trade-off is often underestimated because it moves effort from pipeline steps into image engineering. If you do not control the base image carefully, you inherit drift, stale tooling, and hard-to-troubleshoot failures when jobs expect packages that are not present. In other words, the security gain comes with a supply of operational debt unless the image is treated like a first-class build artifact.
A strong way to validate the setup is to ask whether job requirements are satisfied by the image before execution begins. If the answer is no, teams end up reintroducing ad hoc privilege, network fetches, or wrapper scripts that weaken the original hardening goal. For that reason, this pattern usually works best when the job catalog is stable and the image maintenance process is mature.
What teams should verify before standardising on rootless ARC
Before standardising, teams should verify three things: the pod’s privilege boundary, the image’s toolchain coverage, and the blast radius if the runner is compromised. That is the decision point that rootless Docker in Docker forces. It is less about whether the daemon runs as root, and more about whether the surrounding execution environment is still too trusted for the workloads it runs.
This is also where identity and access discipline matters in practice. Even when the subject is container runtime design, the risk increases when the build path can reach overly broad credentials, registries, or other secrets. NHIMG’s Ultimate Guide to Non-Human Identities is relevant here because the broader control problem is still about reducing the value and reach of credentials used by automation.
For practitioners who want a current control view, OWASP Non-Human Identity Top 10 helps frame the credential and privilege side of the problem, while SPIFFE workload identity specification is useful when the long-term goal is to replace broad ambient trust with stronger workload identity patterns.
Risk and Threat Considerations
Rootless Docker in Docker narrows the impact of process-level compromise, but it does not remove the trusted computing base of a privileged Kubernetes pod. If the runner image, mounted inputs, or job steps are abused, the attacker still has a path to runtime abuse, secret exposure, or lateral movement through whatever the pod can access.
Failure mechanism: The control fails when teams equate non root processes with non privileged execution and overlook the fact that the pod still runs with elevated cluster-side authority.
Impact: A compromise can expose build credentials, corrupt artifacts, or turn the runner into a pivot point for broader cluster or supply-chain abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6.3 — Account Management | Controls runner and build access paths that can widen blast radius. |
| Recommendation — Restrict and review runner account access to limit build-time privilege exposure. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | The runner still depends on privileged cluster authorization and scoped access. |
| PR.IP-1 — Configuration Baselines | Rootless DinD shifts security dependence onto the base image and runtime baseline. | |
| DE.CM-8 — Vulnerability Information | Image and runtime weaknesses must be visible to manage the residual risk. | |
| Recommendation — Enforce least-privilege permissions for the runner and its mounted resources. Maintain a hardened, versioned base image as the enforced execution baseline. Monitor container image and runtime exposure for weaknesses that affect the runner. | ||
| MITRE ATT&CK | T1611 — Escape to Host | Privileged container paths can enable breakout-style abuse if compromised. |
| Recommendation — Hunt for container breakout conditions when privileged build pods are exposed. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Build jobs may rely on secrets whose exposure drives the remaining risk. |
| NHI-03 — Privilege and Access Management | The design still depends on privileged pod access despite rootless processes. | |
| Recommendation — Reduce and tightly scope secrets available to build-time automation. Minimise the privileges granted to runner workloads and their tokens. | ||
Practitioner Guidance
What to prioritise: Treat the base image as part of the security boundary. If jobs need extra tooling, bake it into a maintained image rather than granting ad hoc install capability during execution.
What to verify: Confirm that the runner’s effective permissions, mounted volumes, registry access, and secret exposure are all compatible with the assumption that the pod is still privileged, even if the process user is not.
Common mistake: Teams often report “rootless” as a security outcome when the more accurate statement is that they reduced one privilege layer while retaining others. That distinction matters most when jobs can touch production credentials or artifacts.
Practitioner takeaway: Use rootless DinD to reduce exposure, not to justify weaker cluster governance, because the remaining privilege boundary and image discipline determine whether the design is actually safer.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
