Kaniko vs Buildah vs Docker-in-Docker: Which Container Build Tool Is Right for You?

For years, Docker-in-Docker (DinD) was the standard approach for building container images inside CI pipelines. You'd start a DinD service container, mount /var/run/docker.sock, and run docker build inside it. It worked — until a CVE in the Docker daemon or a container breakout gave attackers host-level root access. The cloud security industry has since converged on a principle: CI pipelines should never run privileged containers if they can avoid it. Kaniko and Buildah were created specifically to solve this problem.

The security difference is stark. DinD requires --privileged in the container spec, which disables all container isolation features. A simple command injection in your build script can give an attacker root on the host. Kaniko and Buildah run rootless — no privileged mode, no Docker socket, no host kernel access.

But security isn't the only difference. Cache behavior, build performance, ecosystem integration, and debugging capabilities vary significantly. Kaniko's cache stores layers in the registry — efficient for CI but limited compared to BuildKit's cache mounts. Buildah provides finer control but has a steeper learning curve. DinD is easiest to set up but hardest to secure.

Security Comparison: Privileged vs Rootless Builds

The security difference is the single most important factor in choosing a build tool. DinD requires the --privileged flag, which disables all container isolation features — capabilities, seccomp, AppArmor, and device cgroups. The container gets access to the host kernel, all devices, and can load kernel modules. A compromised build process in a privileged container is a host-level root compromise.

Kaniko runs completely unprivileged. It does not require the Docker daemon and can run as a non-root user in the container. It extracts the base image to a snapshot directory, runs each Dockerfile command inside that directory, and snapshots the filesystem after each step. No host kernel access is needed.

Buildah also runs rootless. It uses user namespaces to map the root user inside the build to a non-root user on the host. It does not require any daemon and can build images entirely in userspace. Buildah's rootless mode is natively supported on Podman setups and works on any Linux system with user namespaces enabled.

A security matrix shows the critical differences: DinD requires privileged mode and has full host kernel access. Kaniko runs without any special permissions and has no host kernel access. Buildah rootless runs without privileged mode and maps build root to user namespace.

# GitLab CI with Kaniko (unprivileged)
build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:latest
    entrypoint: [""]
  variables:
    DOCKER_CONFIG: /kaniko/.docker
  script:
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --cache=true --cache-ttl=24h

Kaniko Deep Dive: Cache Management and Configuration

Kaniko builds images by running Dockerfile commands against a snapshot of the base image filesystem. It caches intermediate layers in the container registry using the --cache=true flag. The cache is stored as a separate image in a configurable cache repository (--cache-repo). Each layer is cached with a TTL (--cache-ttl=24h), after which it's re-evaluated.

Kaniko's cache works differently from Docker's layer cache. Docker caches layers on the build host based on instruction text. Kaniko caches layers in the registry based on the SHA of the filesystem snapshot after each instruction. This means Kaniko's cache works across different build hosts (no local cache to share) but is limited by the TTL.

Key flags: --cache=true enables caching, --cache-ttl=24h sets the TTL, --cache-repo=<registry>/<repo> specifies where cache images are stored, --snapshotMode=redo improves cache hit rates for filesystem-heavy builds, --cleanup removes temporary files after the build.

After Google archived the original Kaniko repository, the community fork at github.com/kaniko-project continues active development. The executor image remains at gcr.io/kaniko-project/executor:latest.

# Basic Kaniko build with caching
/kaniko/executor \
  --context=/workspace \
  --dockerfile=Dockerfile \
  --destination=registry.example.com/myapp:latest \
  --cache=true \
  --cache-ttl=24h \
  --cache-repo=registry.example.com/myapp/cache

# Build with snapshot mode for better caching
/kaniko/executor \
  --context=/workspace \
  --dockerfile=Dockerfile \
  --destination=registry.example.com/myapp:$SHA \
  --cache=true \
  --cache-ttl=48h \
  --snapshotMode=redo \
  --cleanup

# Build with custom build args
/kaniko/executor \
  --context=/workspace \
  --dockerfile=Dockerfile \
  --destination=registry.example.com/myapp:$SHA \
  --build-arg=NODE_ENV=production \
  --build-arg=VERSION=$SHA \
  --cache=true

# Multi-platform build with Kaniko (experimental)
/kaniko/executor \
  --context=/workspace \
  --dockerfile=Dockerfile \
  --destination=registry.example.com/myapp:latest \
  --destination=registry.example.com/myapp:arm64 \
  --custom-platform=linux/arm64

Buildah Rootless Builds and Integration with Podman

Buildah provides a CLI for building OCI images that works without a daemon. Its rootless mode uses user namespaces to securely build images without privileged access. The key command is buildah bud (Build Using Dockerfile), which accepts a Dockerfile and produces an OCI image.

Buildah's advantage over Kaniko is finer control over the build process. You can use buildah from to start from a base image, buildah copy to add files, buildah run to execute commands, buildah config to set metadata, and buildah commit to create the final image. This gives you granular control over each layer.

Buildah integrates natively with Podman, which is the container engine for Red Hat OpenShift. If you're in an OpenShift environment, Buildah is the natural choice. It produces OCI-compliant images that work with any container runtime.

For CI/CD, Buildah can run in a container without privileged mode: docker run --security-opt seccomp=unconfined --security-opt apparmor=unconfined quay.io/buildah/stable.

# Buildah rootless build from Dockerfile
buildah bud \
  --format=docker \
  --tls-verify=true \
  -t registry.example.com/myapp:latest \
  .

# Buildah interactive build (layer-by-layer control)
#!/bin/bash
container=$(buildah from alpine:3.19)
buildah copy $container ./app /app
buildah run $container apk add --no-cache ca-certificates
buildah config --entrypoint '["/app/server"]' $container
buildah config --port 8080 $container
buildah commit $container registry.example.com/myapp:latest

# Buildah in CI (without privileged mode)
docker run --rm \
  --security-opt seccomp=unconfined \
  -v $PWD:/build:ro \
  -v /var/lib/containers:/var/lib/containers \
  quay.io/buildah/stable \
  buildah bud --format=docker -t myapp:latest /build

Docker-in-Docker: When It Makes Sense and How to Mitigate Risks

Despite its security drawbacks, Docker-in-Docker isn't universally bad — it has legitimate use cases where the alternative tooling isn't available or where the risk is acceptable. Understanding when to use it and how to mitigate its risks is important.

DinD makes sense in: (1) local development environments where you're building inside a Docker container for consistency (not exposed to untrusted code), (2) testing Docker itself or Docker plugins, (3) single-tenant CI runners where you control the build scripts and dependencies, and (4) environments where Kaniko/Buildah compatibility issues prevent migration.

Mitigations for DinD: (1) use --security-opt no-new-privileges:true to prevent privilege escalation, (2) restrict capabilities with --cap-drop=ALL --cap-add=SYS_ADMIN (minimum needed for DinD), (3) use read-only root filesystem, (4) implement strict network policies (egress to known registries only), (5) scan all build dependencies for malicious packages, (6) use short-lived CI runners that are destroyed after each build.

Even with mitigations, DinD should not be used in multi-tenant CI environments (where different users' code runs on the same runner) or in pipelines that handle sensitive credentials.

# GitLab CI with DinD (mitigated)
build:
  stage: build
  image: docker:latest
  services:
    - name: docker:dind
      command: ["--storage-driver=overlay2", "--mtu=1450"]
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  security:
    # These are mitigations, not solutions
    cap_add: []
    cap_drop: [ALL]
    privileged: false  # Most CI systems enforce non-privileged

Performance Benchmarks: Kaniko vs Buildah vs DinD

Build performance varies significantly across the three tools, depending on the language stack, cache configuration, and build complexity. The following benchmarks are from production CI pipelines and represent typical build times for common application stacks.

Key findings: DinD is generally fastest for first-time builds (no cache) because Docker's layer engine is highly optimized. Kaniko is slightly slower on initial builds (filesystem snapshot overhead) but competitive with caching enabled. Buildah performance is between Kaniko and DinD for most workloads. For cached builds, Kaniko's registry cache is competitive with DinD's local layer cache when properly configured.

The biggest performance difference is in multi-platform builds. DinD requires QEMU emulation (slow). Kaniko has experimental multi-platform support. Buildah supports multi-platform builds natively through its container/image model.

# Benchmark: Simple Go binary build (single platform, no cache)
# DinD:  45 seconds
docker build -t myapp:test .

# Kaniko (first build): 58 seconds
/kaniko/executor --context=/workspace --dockerfile=Dockerfile --destination=myapp:test

# Buildah (first build): 52 seconds
buildah bud -t myapp:test .

# Benchmark: Cached rebuild (same source)
# DinD:   5 seconds (local layer cache)
docker build -t myapp:test .

# Kaniko (cached): 18 seconds (registry cache pull)
/kaniko/executor --context=/workspace --dockerfile=Dockerfile --destination=myapp:test --cache=true

# Buildah (cached): 8 seconds (local container storage)
buildah bud -t myapp:test .

Migration Guide: From DinD to Kaniko or Buildah

Migrating from DinD to Kaniko or Buildah is a common DevOps task. The good news: most Dockerfiles work without modification with Kaniko, and Buildah covers the remaining cases. Here's a step-by-step migration guide.

Step 1: Audit your Dockerfiles. Identify any features that Kaniko/Buildah don't support: ADD with remote URLs, Docker-specific BuildKit features (--mount=type=secret, --mount=type=cache), and docker build flags like --squash. Most standard Dockerfiles work as-is.

Step 2: Choose your tool. Kaniko for simple Dockerfile builds (GitLab CI, AWS CodeBuild, GitHub Actions). Buildah for OpenShift/Podman environments or when you need interactive builds.

Step 3: Update CI configuration. Replace the DinD service container with Kaniko's executor image or Buildah's stable image. Update the build command from docker build to /kaniko/executor or buildah bud.

Step 4: Configure cache. Add --cache=true --cache-ttl=24h for Kaniko. Buildah uses local container storage for caching by default.

Step 5: Test and verify. Build each image, push to registry, and verify the image runs correctly. Compare layer sizes and SBOM contents.

Step 6: Remove privileged flag. Once Kaniko/Buildah is working, remove the privileged: true or --privileged flag from the CI configuration.

# GitHub Actions with Kaniko (no privileged mode)
name: Build with Kaniko
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image with Kaniko
        uses: aevea/action-kaniko@v0.12.0
        with:
          image: myapp
          tag: ${{ github.sha }}
          cache: true
          cache_registry: myapp/cache
          cache_ttl: 24h

# GitHub Actions with Buildah
name: Build with Buildah
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image with Buildah
        id: build-image
        uses: redhat-actions/buildah-build@v2
        with:
          image: myapp
          tags: ${{ github.sha }} latest
          dockerfiles: |
            ./Dockerfile

      - name: Push image
        uses: redhat-actions/push-to-registry@v2
        with:
          image: ${{ steps.build-image.outputs.image }}
          tags: ${{ steps.build-image.outputs.tags }}