Docker in Docker runs nested containers inside a privileged runner pod and can use the Docker daemon to build images. ARC Kubernetes mode does not require privileged mode and spins up separate pods for workload containers. The security trade off is clear: Docker in Docker offers daemon based flexibility, while Kubernetes mode reduces host access risk.
How the execution model changes
Docker in Docker and ARC Kubernetes mode solve different operational problems, and the difference starts with where the workload actually runs. Docker in Docker nests container builds inside a container runtime, which means the runner needs deeper access to the host or daemon path. ARC Kubernetes mode instead schedules separate pods for each workload, so the runner is closer to a normal Kubernetes workload than a privileged container host.
That distinction matters because the build mechanism changes the trust boundary. Docker in Docker centralises more power in the daemon and can make image construction simpler for teams that rely on Docker-native tooling. ARC Kubernetes mode trades some of that convenience for a cleaner pod-level isolation model and less dependence on privileged execution.
For container hardening guidance, NIST’s NIST SP 800-190 Container Security is the closest external control reference for thinking about runtime, orchestrator and image-build risk.
What the security trade-off really is
The main security difference is not simply “more flexible versus more secure”, it is where you accept risk. Docker in Docker is attractive when you need daemon-based image builds, but that same design usually expands the blast radius if the runner or build environment is compromised. ARC Kubernetes mode removes the need for privileged mode in the common case, which reduces host-level exposure and narrows what a compromised workload can directly reach.
In practice, the more privileged the build path, the more carefully you need to treat secrets, image provenance, and lateral movement potential inside the CI environment. When teams say the choice is “just about build convenience”, they often understate the fact that container-build tooling can become part of the attack path if credentials, sockets, or daemon access are exposed.
The container build and secret exposure pattern is well documented in NHIMG’s Massive Docker Hub Secrets Leak and Docker Hub Auth Secrets in Container Images resources, both of which show how build and registry workflows can turn into credential exposure paths.
How to choose between them in practice
Choose Docker in Docker only when the workflow genuinely needs Docker-daemon semantics and the environment is already engineered to tolerate that extra privilege. Choose ARC Kubernetes mode when you want a more constrained runner model, easier isolation between jobs, and less dependence on privileged container execution.
- If the job must build images through Docker-native commands, validate whether that requirement is real or just inherited from older pipelines.
- If the pipeline handles sensitive secrets or deploy credentials, prefer the mode that minimises daemon access and privileged pod exposure.
- If build isolation and multi-tenant safety matter more than legacy Docker compatibility, Kubernetes mode is usually the better default.
For a broader identity and secrets perspective, NHIMG’s Ultimate Guide to Non-Human Identities is useful because CI runners and build systems often depend on credentials and tokens that must be governed as part of the delivery path.
Practitioner Guidance: Treat this as a workload isolation decision, not a naming preference. If the build system ever touches production credentials, image-signing material, or registry authentication, the safer default is the mode that avoids privileged host access unless you have a concrete technical reason to accept it.
Practitioner takeaway: Docker in Docker optimises compatibility, while ARC Kubernetes mode optimises containment, so the right choice depends on whether your build process needs daemon-level power more than it needs a tighter blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties | Runner privilege and daemon access are access-control decisions in this build model. |
| PR.IP-1 — A baseline configuration of information technology/industrial control systems is created and maintained incorporating security principles | The runner mode is a security-relevant configuration choice that should be standardized. | |
| DE.CM-8 — Vulnerabilities are monitored and managed | Privileged build paths increase exposure that should be monitored for misuse and drift. | |
| Recommendation — Apply PR.AC-4 to minimize runner and daemon privileges for CI workloads. Standardize the safer runner configuration as the approved baseline. Monitor privileged build environments for misconfiguration and abuse. | ||
| CIS Controls v8 | 6.3 — Engage Onboarding, Offboarding, and Access Revocation | Build runners and their credentials should be revoked or rotated when pipeline access changes. |
| 6.8 — Define and Maintain Role-Based Access Control | Privileged Docker-in-Docker paths need tightly scoped role assignments and separation of duties. | |
| Recommendation — Revoke or rotate CI runner credentials promptly when build access changes. Restrict Docker-in-Docker administration to narrowly scoped roles. | ||
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
