Introduction: The All‑Too‑Common DinD Shortcut

Many teams adopt Docker‑in‑Docker (DinD) as a quick way to build container images inside a CI job. The idea looks attractive: spin up a privileged container, run docker build, push the result, and you’re done. In practice, that shortcut hides a cluster of problems that surface under load, in regulated environments, or when the pipeline is scaled across many runners.

This article does not present a “how‑to‑build” guide for DinD; instead it explains why you should avoid it, uncovers the hidden internals that cause trouble, and walks you through a robust replacement built on Kaniko and GitHub Actions.

What Happens Under the Hood When You Run DinD

When a CI job starts a DinD container it typically requests --privileged mode. This grants the inner Docker daemon full control over the host kernel namespaces, cgroups, and storage drivers. The consequences are threefold:

  • Privilege escalation: Any vulnerability in the Docker daemon can be leveraged to escape the container and affect the host runner.
  • Layered storage bloat: The outer Docker layer stores the entire inner Docker image store, leading to exponential disk growth during concurrent builds.
  • Race conditions: Multiple DinD containers share the same underlying daemon if the host re‑uses the same socket, causing builds to interfere with each other.

Because the inner daemon runs as root inside a privileged container, secret files (e.g., .npmrc or cloud credentials) can inadvertently be written to the host’s /var/lib/docker directory. Auditors frequently miss these artifacts, resulting in compliance gaps. 

# Typical DinD step in a GitHub Actions workflow
- name: Build with Docker‑in‑Docker
  uses: docker://docker:latest
  with:
    args: |
      docker run --privileged \
        -v /var/run/docker.sock:/var/run/docker.sock \
        docker:dind \
        sh -c "docker build -t myapp:${{ github.sha }} . && docker push myrepo/myapp:${{ github.sha }}"

The snippet above illustrates the core problem: the job mounts the host’s Docker socket, effectively handing the inner container direct access to the host daemon.

Why the “Docker‑in‑Docker” Pattern Is a Liability

Security exposure: A compromised build step can install a rootkit on the host runner, persisting across subsequent jobs. In a shared runner fleet, the impact spreads instantly.

Performance degradation: Each DinD instance spawns its own storage driver (overlay2, devicemapper, etc.). On a typical CI machine with 8 GB RAM, three simultaneous DinD jobs can exhaust memory, causing OOM kills.

Debugging nightmare: Errors surface deep inside the nested Docker daemon logs (/var/log/docker.log) that are not captured by the CI UI. Engineers spend hours chasing phantom failures.

Compliance blind spot: Artifacts stored in the inner Docker layer are not scanned by standard SBOM tools because they reside outside the primary image registry scan scope.

Alternative Approach: Build Images with Kaniko in a Stateless Runner

Kaniko is a tool that builds container images from a Dockerfile without requiring a Docker daemon. It runs entirely in userspace, reads the Dockerfile, and writes the resulting layers directly to a registry. This eliminates the need for privileged containers and dramatically reduces the attack surface.

Below is a complete GitHub Actions workflow that replaces DinD with Kaniko. The workflow runs on a standard Ubuntu runner, uses a dedicated service account for registry access, and caches the .docker/config.json file to speed up repeated pushes. 

name: CI – Build with Kaniko

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu‑latest
    permissions:
      contents: read
      packages: write

    steps:
      # Checkout source
      - name: Checkout repository
        uses: actions/checkout@v3

      # Authenticate to the container registry
      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      # Pull Kaniko image
      - name: Pull Kaniko executor
        run: |
          docker pull gcr.io/kaniko-project/executor:latest

      # Build and push with Kaniko
      - name: Build image with Kaniko
        env:
          IMAGE_NAME: ghcr.io/${{ github.repository }}/myapp:${{ github.sha }}
        run: |
          docker run --rm \
            -v ${{ github.workspace }}:/workspace \
            -v /tmp/kaniko:/kaniko/.docker \
            gcr.io/kaniko-project/executor:latest \
            --context /workspace \
            --dockerfile /workspace/Dockerfile \
            --destination $IMAGE_NAME \
            --cache=true \
            --cache-repo ghcr.io/${{ github.repository }}/cache

Notice the absence of --privileged and the lack of any Docker socket mounting. The Kaniko container only needs read‑only access to the source code and write access to the registry.

Adding a Layered Cache for Faster Iterations

Kaniko supports a remote cache that stores previously built layers in a dedicated repository. By configuring --cache-repo you avoid rebuilding unchanged layers, cutting CI time by up to 50 % for large monorepos. 

# Extend the previous step with a cache key
- name: Build with Kaniko (cached)
  env:
    IMAGE_NAME: ghcr.io/${{ github.repository }}/myapp:${{ github.sha }}
    CACHE_REPO: ghcr.io/${{ github.repository }}/cache
  run: |
    docker run --rm \
      -v ${{ github.workspace }}:/workspace \
      -v /tmp/kaniko:/kaniko/.docker \
      gcr.io/kaniko-project/executor:latest \
      --context /workspace \
      --dockerfile /workspace/Dockerfile \
      --destination $IMAGE_NAME \
      --cache=true \
      --cache-repo $CACHE_REPO \
      --cache-ttl 168h

The --cache-ttl flag ensures that stale layers are purged after a week, keeping the cache size manageable while still delivering speed benefits.

Security and Best Practices

Use scoped service accounts: Create a minimal‑privilege token that can only push to the target repository. Do not reuse personal tokens with broad write access.

Validate image signatures: After Kaniko pushes the image, run cosign verify as a separate step to guarantee integrity before deployment.

Never expose secrets in the Dockerfile: Keep build‑time secrets (e.g., private NPM registries) out of the Dockerfile and inject them via build args that Kaniko can mask in logs.

"Replacing Docker‑in‑Docker with a daemon‑less builder is the single most effective step you can take to harden modern CI pipelines."

Conclusion

Docker‑in‑Docker may look convenient, but its hidden costs—privilege escalation, storage bloat, and compliance blind spots—outweigh any perceived simplicity. By adopting a daemon‑less builder like Kaniko, teams gain a stateless, secure, and faster path from source to registry.

The transition requires only a modest change to the CI definition, yet it yields immediate security hardening, lower resource consumption, and clearer audit trails. Treat the switch as an essential refactor rather than an optional optimization; the hidden risks of DinD are too significant to ignore.