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.
What ARC Kubernetes Mode Changes
ARC Kubernetes mode changes the runner execution model, not the application being built. By giving each workload its own pod, it reduces runner co-location risk and avoids privileged container operation, which narrows the blast radius if a runner is abused. The trade off is that some Docker daemon based build patterns are unavailable, so teams must use alternate build tooling.
Why the Pod-Per-Workload Model Matters
The main security value of this model is isolation. Separate pods make it harder for one workload to interfere with another through shared runtime state, and they reduce dependence on a privileged runner that can interact closely with the host. That matters most in multi-tenant or high-churn CI environments, where a single compromised job should not be able to influence neighbouring jobs or the underlying node.
This is why container runtime guidance for image and orchestrator security remains relevant here, especially when build systems are part of the delivery path. NIST SP 800-190 Container Security is a useful reference for understanding how image, registry, orchestrator and runtime controls work together.
Build Tooling Trade Offs and Operational Constraints
ARC Kubernetes mode removes the convenience of Docker daemon based image builds, so the practical question becomes how to preserve build capability without reintroducing privileged access. Teams typically need rootless or daemonless build paths, tighter image provenance controls, and a clear decision on which build steps belong inside the runner versus elsewhere in the pipeline.
That trade off is not just operational, because the build method affects what can be trusted about the resulting artifact. If a team swaps convenience for safer isolation, it should still ensure the alternative builder supports repeatable output, access control, and environment hardening appropriate to the workloads it handles.
Where Exposure Usually Emerges
Exposure usually appears when teams try to regain lost Docker functionality by loosening pod security or mounting powerful host resources back into the runner. The safer model can be undermined if the pod is granted unnecessary privileges, broad node access, or writable access to sensitive paths that defeat the original isolation goal.
ARC Kubernetes mode is best understood as a control boundary, not a guarantee. If the surrounding cluster policy is weak, the pod model still leaves room for credential theft, workload tampering, or supply-chain abuse through the build process itself.
ARC Guide is useful here because the same isolation mindset applies to ARC-style deployment choices, even though the mechanics differ from email ARC. The common theme is trusting the right boundary and validating what crosses it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-190, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-190 | Container Security | Guides container image, registry, orchestrator and runtime security for pod-based runners. |
| Recommendation — Apply container security guidance to keep runner pods isolated and limit host-facing runtime exposure. | ||
| NIST SP 800-53 Rev 5 | SC-38 — Operations Security | Supports limiting privileged execution paths and constraining container runtime exposure. |
| Recommendation — Restrict runner privileges and isolate build execution paths to reduce host escape risk. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Addresses hardened configuration for the cluster and runner environment used by Kubernetes mode. |
| Recommendation — Harden cluster and runner configurations so build workloads do not rely on unnecessary privilege. | ||
Practitioner Guidance
What to watch for: Treat ARC Kubernetes mode as a secure-by-default runner pattern only if your build architecture can operate without Docker daemon dependencies and without adding back privileged access as a workaround. The right test is whether the runner can stay isolated while still producing the artifacts your pipeline needs.
Governance implication: Assign ownership for the runner model, build tooling, and cluster permissions together, because security breaks when those decisions are made separately. If a team needs deeper operational context on safe NHI-style automation and build-adjacent control boundaries, Azure Arc Security Guide is a useful adjacent reference for agent identity and control-plane governance.
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?
- Why should Kubernetes containers not run in privileged mode?
- What is the difference between sandbox mode and true network isolation for AI workloads?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org