When should security teams prioritise Kubernetes mode over Docker in Docker for ARC runners?

Security teams should prioritise Kubernetes mode when they want to reduce host exposure and avoid running the runner pod in privileged mode. In this model, each container gets its own pod, and ARC requests pods on demand. The trade off is that Docker daemon based builds are not available, so teams must use alternatives such as Kaniko or Buildah.

Why Kubernetes mode is the safer default for ARC runners

Kubernetes mode is the better choice when the security goal is to minimise how much the runner can touch on the host. It gives each job its own pod and avoids the common pattern of running the runner pod in privileged mode, which materially reduces host-level blast radius if a build or job is compromised. For teams already managing container risk, that operational boundary is the main reason to prefer it.

The distinction matters because ARC runners are not just a scheduling detail, they define the trust boundary for CI execution. In Kubernetes mode, the platform provisions pods on demand, so the runtime environment is created and destroyed around the job rather than persisting with broad host access. That fits better with security models that assume build workloads should be isolated by default and only granted the minimum runtime capability they need.

This is especially relevant in container-heavy environments where build steps may interact with images, registries, or secrets during the pipeline. Kubernetes mode aligns more naturally with container security guidance around limiting orchestrator and runtime exposure, which is why NIST SP 800-190 Container Security is the strongest external reference for the underlying risk boundary. It is also consistent with the broader control objective described in NHIMG’s Ultimate Guide to NHIs, Key Challenges and Risks, where excessive access and weak visibility are recurring failure modes.

What you give up when you leave Docker in Docker behind

The security benefit of Kubernetes mode comes with a real build-capability trade off: Docker daemon based builds are not available. Teams that still depend on Docker-in-Docker patterns for image creation, nested builds, or Docker-specific tooling will need an alternative build engine such as Kaniko or Buildah. That is not just a tooling swap, it changes how the pipeline assembles images and what assumptions the build step can make about the runtime.

Practically, that means the migration decision should be driven by the build features you actually need, not by habit. If the pipeline only needs to build and publish container images, Kubernetes mode is often the cleaner security choice. If a workflow still depends on the Docker daemon for legacy reasons, the security gain may be offset by operational friction unless the team is prepared to rework the build process.

For teams reviewing container platform controls, it helps to anchor the decision in prescriptive safeguards rather than convenience. CIS Controls v8 is useful here because it emphasises account management, access control, and secure configuration, all of which are affected when you choose a less privileged runner model. For a broader governance view, CSA Cloud Controls Matrix helps frame the same decision as a cloud workload control problem rather than a pure build-engine preference.

Operational signals that Kubernetes mode is the right security move

Choose Kubernetes mode when the build environment is multi-tenant, when runner compromise would be expensive, or when security policy forbids privileged pods on shared infrastructure. The signal to watch is whether the current pipeline design forces you to trade isolation for convenience. If the answer is yes, the safer default is to remove the Docker daemon dependency and treat the runner as an ephemeral workload with tightly bounded access.

It is also the better fit when you need clearer separation between build jobs, better pod-level teardown, and less persistent host exposure. That reduces the chance that a compromised job can reach beyond its own execution context. The trade off is not only technical capability, but also migration work: image build tooling, caching behaviour, and pipeline assumptions all need to be revalidated before the switch is treated as complete.

Failure mechanism: Docker in Docker often concentrates build authority into a privileged runtime that can expand host exposure if a job is abused or misconfigured.

Impact: A compromise can move from a single pipeline job to broader node-level exposure, while Kubernetes mode constrains the likely blast radius to the pod boundary and makes privilege reduction much easier to enforce.

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, CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Access Control	Runner privilege and host exposure are access-control issues.
Recommendation — Limit runner privileges and enforce the least access needed for builds.
CIS Controls v8	6 — Access Control Management	The choice affects privileged access and account boundary design for CI workloads.
	8 — Audit Log Management	Ephemeral runners and isolated pods improve traceability of build activity.
Recommendation — Remove unnecessary privileged access from runner workloads and service accounts. Log runner actions so you can attribute and investigate build-time activity.
NIST Zero Trust (SP 800-207)	SC-1 — Policy Decision Point Separation	Kubernetes mode better supports separating job execution from broad host trust.
Recommendation — Isolate build execution from the underlying node and enforce explicit policy.
NIST SP 800-63	IAL — Identity Assurance Level	Build workloads still rely on authenticated access to cluster and registry resources.
Recommendation — Require strong authentication before granting build or deployment access.

Practitioner Guidance

What to prioritise: Prioritise Kubernetes mode when your first security objective is to eliminate privileged runner execution and reduce dependence on the host Docker daemon. That is the right default for shared clusters, regulated environments, and any CI path that handles sensitive build inputs or deployment credentials.

What to verify: Confirm that the replacement build path really covers your required image-build features before migration. If you still need Docker-specific behaviour, test Kaniko or Buildah in the same pipeline conditions so the security improvement does not create hidden release risk.

Practitioner takeaway: The deciding factor is not whether Docker in Docker is familiar, it is whether the runner needs host-level privilege to do its job. If it does, Kubernetes mode is usually the safer security posture.