The Docker-in-Docker Trap: Escaping Privileged Container Hell With Edera

We've seen this pattern across multiple customer conversations. Today, we want to walk you through exactly how Edera solves it.

It usually starts with a CI/CD requirement. A platform team needs to build container images as part of an automated pipeline. Their orchestration layer runs on Kubernetes. And somewhere along the way, someone realizes: to run Docker inside a container, you either mount the host socket or you run a privileged container. Neither option is great. But the business need is real, the deadline is looming, and so the privileged container gets deployed. I’ve been there, you just grit your teeth and deploy it, then file an issue that says “make this better” and hope you find the time to fix it later.

We've heard this story from multiple teams who've reached out to us. The specific context varies – multi-tenant CI/CD platforms, AI infrastructure providers running GPU workloads, SaaS companies building developer tooling – but the core problem is always the same: they've hit the wall that Docker-in-Docker (DinD) builds, and they need a real solution.

This post walks through why DinD is fundamentally broken from a security standpoint, what the real-world blast radius looks like when something goes wrong, and how Edera's hardened runtime eliminates the conundrum entirely rather than just making it marginally less bad.

Why Both DinD Approaches Break Container Isolation

The requirement is legitimate: modern software delivery workflows need to build, test, and push container images. When your workloads run inside containers on Kubernetes, you need some mechanism to run the Docker (or containerd) daemon that makes that possible.

There are two dominant approaches:

Approach 1: Mount the host Docker socket (Docker-out-of-Docker)

You expose /var/run/docker.sock from the host node into the container. The container then talks directly to the host's Docker daemon. This is operationally simple but the security implications are severe: any process running inside that container now has root-equivalent access to the host. It can spawn containers with arbitrary capabilities, bind-mount host paths, and — in most real-world configurations — fully escape to the underlying node. Compromising the build job means compromising the node.

Approach 2: Privileged containers

You run the container with --privileged, which grants the container nearly full access to the host kernel. This is required to run a nested Docker daemon directly. The Kubernetes equivalent is securityContext.privileged: true. The security implications are not subtle: a privileged container is, from a kernel perspective, barely a container at all. The capability restrictions that make namespaces a meaningful security boundary are removed, so a privileged container can trivially escape its namespaces and reach the host.

A privileged container is not a hardened container with elevated permissions. It is a container where the isolation model has been suspended.

What a Compromised DinD Build Job Can Actually Reach

Here's what "something goes wrong" actually looks like in a DinD environment:

• A dependency in a build pipeline is compromised, think XZ Utils, tj-actions, SolarWinds. The malicious package executes inside what appears to be an isolated build container. Because that container has socket access or is privileged, it can now reach the host daemon, spawn additional containers, or access secrets mounted on other workloads running on the same node.
• A vulnerability in the container runtime or the build tool itself is exploited, think Leaky Vessels. Again, the attacker's effective blast radius is not "this build job" — it's "this node" or potentially "this cluster."
• An insider threat or misconfigured service account causes a workload with DinD access to be abused to scan and access co-located workloads. The multi-tenant boundary that was supposed to protect Customer A's data from Customer B's build job is meaningless.

‍

The teams we've spoken with have often already experienced near-misses – a security audit finding, a pen test result, or a customer compliance review that flagged privileged containers as a critical risk. The question they come to us with isn't "is this a problem" – they know it's a problem. The question is: "what can we actually do about it?"

Why Rootless Docker, Buildah, and Pod Security Standards Miss the Point

The standard hardening guidance for DinD includes things like: use rootless containers, use Buildah or Kaniko instead of Docker, apply Pod Security Standards, enable seccomp profiles, use image scanning. These are all reasonable hygiene practices. None of them solve the underlying problem.

Rootless Docker and Buildah require user namespaces which actually expands the shared kernel attack surface. Kaniko is better, but still relies on the shared kernel behaving itself. Pod Security Standards can prevent the most egregious misconfigurations, but they don't provide workload isolation — they provide policy guardrails. And seccomp profiles reduce the syscall surface but don't eliminate the kernel-sharing problem that is the root cause of DinD's risk.

You cannot patch your way out of a design problem. If the isolation model requires trusting every workload on the node not to abuse kernel access, the isolation model is already broken.

How Edera Solves DinD Without the Tradeoffs

Edera's hardened runtime is built on a Type 1 hypervisor, rewritten in Rust, that provides hardware-enforced workload isolation at the VM boundary – not the container boundary. Each workload gets its own isolated kernel. Containers running inside that boundary share a kernel with each other, but not with the host and not with other workloads running on the same node.

• A workload running inside an Edera-isolated environment can run a Docker daemon – including with elevated capabilities – without exposing the host kernel. The "privileged" context it's running in is its own isolated VM environment, not the host.
• Socket mounting can be scoped to within the isolated workload boundary. The build job talks to its own daemon, not the host's. The blast radius of a compromised build is the workload, not the node.
• The hardware enforcement means this isn't a policy you can misconfigure away. There's no kubectl flag, no ServiceAccount permission, no seccomp misconfiguration that collapses the isolation. The boundary is enforced at the hypervisor level.

‍

For multi-tenant CI/CD platforms, this means Customer A's build pipeline can run privileged operations without creating risk for Customer B's workloads on the same node. For AI infrastructure teams running GPU workloads, it means build jobs that require elevated privileges to interface with GPU drivers don't become lateral movement vectors across the cluster.

Teams that have come to us with DinD problems consistently describe the same experience after deploying Edera: they stop treating "needs privileged access" as a security exception that requires a risk acceptance process, and start treating it as an implementation detail that's handled at the runtime layer. 

Deploying Edera for Privileged Build Workloads: What Changes

The deployment pattern we see most often looks like this:

• Platform team identifies the set of build workloads that currently require privileged containers or socket mounting.
• Edera is deployed as the runtime for those specific workloads – no need to migrate the entire cluster at once.
• Existing Kubernetes manifests remain largely unchanged. The privileged securityContext that was previously a security risk becomes a scoped, hardware-enforced configuration.
• Security team reviews the change and can close out the finding – not because the risk was accepted, but because the isolation model changed.

‍

The operational footprint is small. The security posture change is significant. And unlike most "security solutions," this one actually makes the platform team's life easier rather than harder – they can give build jobs the capabilities they need without a security review every time.

Assume Breach, Contain the Blast Radius: The Right Model for CI/CD Security

DinD is a specific problem, but it illustrates a broader principle that we think the industry is still underweighting: the right model for modern workload security isn't "prevent every possible exploit" – it's "assume that something will be exploited, and minimize what an attacker can reach from there.”

Hardware-enforced workload isolation doesn't prevent compromise. It contains it. And in the DinD case – where the compromise vector is often a build dependency or a developer tool, not something you'd have caught with a scanner – containment is the realistic mitigation.

We're not selling 'nothing bad will ever happen.' We're building the architecture for 'when something happens, the blast radius is a workload, not a cluster.'

If This Sounds Familiar

If your team is running privileged containers to support CI/CD, build infrastructure, or any other workload that requires elevated kernel access, and you've been treating that as an accepted risk or a problem to solve later – we'd like to talk.

We've had this conversation with enough teams to know what the blocker usually is: not budget, not willingness to change, but a belief that the only path forward involves either living with the risk or rebuilding the build infrastructure from scratch. Edera is neither of those. It's a runtime change that gives you the isolation model you needed in the first place.

Reach out here or find us on social. We're happy to walk through your specific setup and show you exactly what the deployment looks like.

FAQ

What is Docker-in-Docker and why is it a security risk?

Docker-in-Docker (DinD) refers to running a Docker daemon inside a container to support container image builds in CI/CD pipelines. The two dominant approaches — mounting the host Docker socket or running with --privileged — both grant the container root-equivalent or full kernel access to the host. A compromised build job can reach the host node and co-located workloads, making the blast radius of any supply chain incident far larger than the build itself.

Why don't rootless containers or Pod Security Standards solve the DinD problem?

Rootless Docker and Buildah still require elevated kernel capabilities. Kaniko still shares the host kernel. Pod Security Standards enforce policy guardrails but do not provide workload isolation. All of these operate on top of a shared kernel, which is the root cause of DinD risk. You cannot patch your way out of a shared-kernel architecture.

What does Edera change about running privileged containers in Kubernetes?

Edera runs each workload in a hardware-isolated zone with its own dedicated kernel. A build job that requires --privileged or socket access operates within its own isolated VM environment, not the host. A compromised build cannot reach the host daemon, other workloads, or secrets mounted on co-located pods. The blast radius of a compromise is the workload, not the node.

How does Edera deploy for existing DinD build infrastructure?

Edera integrates as a Kubernetes CRI-compliant runtime via runtimeClassName: edera. Existing pod manifests and securityContext configurations remain largely unchanged. Teams target specific build workloads for migration without redeploying the entire cluster.