ARC Kubernetes mode is the runner model where each container workload runs as a separate Kubernetes pod. It avoids privileged mode and therefore reduces the chance of host escape from the runner pod. The trade off is that Docker daemon based image builds are not available, so teams need alternate build tooling.
How ARC Kubernetes mode works
ARC Kubernetes mode changes the runner execution model by isolating each job in its own Kubernetes pod. That design gives each workload a narrower blast radius than a shared, privileged runner and aligns well with container-native orchestration.
The key idea is separation of execution context. Instead of letting multiple jobs share a runner environment, Kubernetes schedules isolated pods that can be created, torn down, and governed independently. For container-heavy teams, this makes the runner estate easier to reason about from a workload isolation perspective.
The trade-off is equally important: because the mode avoids Docker daemon based image builds, teams must use alternate build tooling. In practice, the architectural gain in isolation comes with a tooling shift in how images are built, cached, and handed off.
Why the security model is different
The main security benefit is the reduction in privileged execution. A runner pod that does not rely on privileged mode is less exposed to host escape paths that can arise when container workloads interact too directly with the node or with the Docker daemon.
This is a container runtime and orchestration control issue first, and an access-control issue second. The distinction matters because the security gain comes from changing where code runs and what it can touch, not from a policy label alone.
For readers evaluating the underlying container risk, NIST SP 800-190 Container Security is the most direct external reference for image, registry, orchestrator, and runtime risk. The pod-level isolation pattern also fits naturally with NIST Cybersecurity Framework 2.0 because it strengthens protect and recover outcomes through reduced blast radius.
Operational trade-offs and build implications
ARC Kubernetes mode is not simply a safer default, it is a different build and execution contract. Teams that depend on Docker daemon behaviors need to replace those assumptions with a build path that works without privileged access or direct daemon interaction.
That can affect caching, build performance, local parity, and pipeline standardisation. It also means the runner design must be evaluated together with the rest of the CI/CD toolchain, not in isolation, because the security improvement is only useful if the build process still supports repeatable delivery.
For organisations comparing container isolation patterns, NIST SP 800-207 Zero Trust Architecture is a useful external lens for reducing implicit trust in runner environments. Where build and delivery controls are already part of the program, OWASP SAMM offers a broader software assurance reference point for securing the delivery lifecycle.
When ARC Kubernetes mode is a good fit
This mode is best suited to teams that value workload isolation, run many ephemeral jobs, and want to avoid giving build infrastructure unnecessary privilege. It is especially attractive when the runner platform is part of a larger Kubernetes estate and the organisation already has mature cluster operations.
It is less attractive when the environment depends on Docker daemon based workflows that are expensive to replace or when build portability is the overriding requirement. In those cases, the mode may still be viable, but only if the alternate build stack is already planned and tested.
NHIMG’s Ultimate Guide to Non-Human Identities is useful here because runner and pipeline design often intersects with secrets exposure, credential handling, and privilege control, even when the primary concern is container isolation. For that same reason, the strongest internal references are the Massive Docker Hub Secrets Leak and Docker Hub Auth Secrets in Container Images, both of which show why reducing runner privilege and avoiding secret exposure in image workflows matters.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 | CIS Control 4 — Secure Configuration of Enterprise Assets and Software | ARC Kubernetes mode reduces runner privilege and host exposure through secure runtime configuration. |
| CIS Control 5 — Account Management | Runner workflows depend on controlled credentials and access paths when build tooling changes. | |
| CIS Control 8 — Audit Log Management | Containerised runners need visibility into job execution and runtime events for detection and review. | |
| Recommendation — Harden runner pod and node configurations to remove unnecessary privilege and reduce host-escape exposure. Restrict build and deployment access to the minimum accounts needed for the runner workflow. Centralise runner and cluster logs so job activity and anomalous pod behaviour can be reviewed quickly. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The mode lowers privilege by separating each job into its own pod and avoiding privileged execution. |
| PR.PT — Platform Security | Pod-per-workload execution is a platform hardening choice that shrinks host escape risk. | |
| DE.CM — Continuous Monitoring | Ephemeral runner pods still require runtime monitoring for misuse, escape attempts, and anomalous behaviour. | |
| Recommendation — Enforce least-privilege access for runner execution paths and cluster resources. Use container platform controls that isolate jobs and block unnecessary privileged container features. Monitor runner pods and cluster events for suspicious runtime activity and privilege misuse. | ||
Related resources from NHI Mgmt Group
- When should security teams prioritise Kubernetes mode over Docker in Docker for ARC runners?
- What is the difference between Docker in Docker and ARC Kubernetes mode?
- What is the difference between sandbox mode and true network isolation for AI workloads?
- How should teams govern Kubernetes service accounts as NHI identities?
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
