Kaniko — Build Container Images in Kubernetes Without a Docker Daemon

Introduction

Kaniko solves one of the most persistent pain points in cloud-native CI: building container images without giving the build pod access to /var/run/docker.sock or running privileged. It executes each Dockerfile instruction in userspace, snapshots the filesystem, and pushes the resulting OCI image to any registry — perfect for hardened, multi-tenant Kubernetes.

What Kaniko Does

• Parses a Dockerfile and executes RUN/COPY/ADD/ENV directives inside its own rootfs
• Captures filesystem diffs after each instruction to form image layers
• Pushes the final image to Docker Hub, GCR, ECR, GHCR, Harbor, Artifactory
• Caches intermediate layers to a registry or cloud bucket (--cache=true)
• Plugs into GitLab CI, Jenkins, Tekton, Argo Workflows, GitHub Actions

Architecture Overview

The Kaniko executor is a single Go binary shipped as gcr.io/kaniko-project/executor. It runs as PID 1 inside a container, unpacks the base image into its own scratch rootfs, and uses a userspace chroot + filesystem snapshotter to execute each layer. Because it never needs CAP_SYS_ADMIN or a Docker daemon, it is safe to run as a normal pod — the key security reason teams moved off DinD.

Self-Hosting & Configuration

• Run as a Kubernetes Job, Tekton TaskRun, or CI runner container — no DaemonSet
• Credentials: mount .docker/config.json or use workload identity on GKE/EKS
• Layer cache: --cache --cache-repo=registry.example.com/cache (huge speedup)
• Build args: --build-arg KEY=VAL; ignore paths with --ignore-path
• Multi-arch: combine with buildx-style manifests or run one Kaniko per arch

Key Features

• Rootless and daemonless — no privileged: true
• Drop-in compatibility with existing Dockerfiles
• Registry-backed layer cache for fast incremental builds
• OCI-compliant output (works with cosign, notation, Trivy, etc.)
• Maintained by Google under the GoogleContainerTools org

Comparison with Similar Tools

• BuildKit — faster and more features but needs a daemon or rootless setup; more config
• Buildah — great CLI, Podman ecosystem, but requires user namespaces in the pod
• img — similar rootless idea, less active
• Docker-in-Docker — works but needs privileged mode, which most clusters forbid
• Ko / Jib — language-specific (Go, Java); no Dockerfile needed but not general-purpose

FAQ

Q: Does Kaniko need root? A: No. It runs as UID 0 inside its own container but needs no host privileges or capabilities.

Q: How do I speed up CI builds? A: Turn on --cache=true and point --cache-repo at a registry; combine with --snapshotMode=redo.

Q: Can it do multi-stage builds? A: Yes. All FROM ... AS stage blocks work; intermediate stages are discarded like with Docker.

Q: Does it support BuildKit frontends? A: No. Kaniko parses standard Dockerfile syntax only, not # syntax=docker/dockerfile:1 experimental directives.

Sources

• https://github.com/GoogleContainerTools/kaniko
• https://cloud.google.com/build/docs/kaniko-cache