Kaniko — Build Container Images in Kubernetes Without a Docker Daemon

What it is

Kaniko is a tool from Google for building OCI container images from a Dockerfile inside a container or Kubernetes cluster. Unlike Docker build, Kaniko does not require a privileged Docker daemon. It executes each Dockerfile command in userspace, produces a standard container image, and pushes it to a registry.

It is designed for CI/CD pipelines running in Kubernetes or other containerized environments where granting access to a Docker socket is a security risk.

How it saves time or tokens

Running Docker-in-Docker (DinD) for CI builds requires privileged containers, which violate most Kubernetes security policies. Kaniko eliminates this requirement entirely. It runs as a regular container, reads the Dockerfile, and builds the image layer by layer. Layer caching to a remote registry means subsequent builds reuse unchanged layers, cutting build times significantly in pipelines that rebuild frequently.

How to use

1. Run a one-off build with Docker (for local testing).

docker run -v $PWD:/workspace \
  -v ~/.docker/config.json:/kaniko/.docker/config.json:ro \
  gcr.io/kaniko-project/executor:latest \
  --dockerfile=Dockerfile \
  --destination=ghcr.io/you/app:v1 \
  --context=dir:///workspace

1. Use Kaniko in a Kubernetes Job.

apiVersion: batch/v1
kind: Job
metadata:
  name: kaniko-build
spec:
  template:
    spec:
      containers:
      - name: kaniko
        image: gcr.io/kaniko-project/executor:latest
        args:
        - '--dockerfile=Dockerfile'
        - '--context=git://github.com/you/app.git'
        - '--destination=ghcr.io/you/app:v1'
      restartPolicy: Never

1. For GitLab CI, replace the Docker executor with the Kaniko image.

Example

Enabling remote layer caching:

docker run -v $PWD:/workspace \
  gcr.io/kaniko-project/executor:latest \
  --dockerfile=Dockerfile \
  --destination=ghcr.io/you/app:v1 \
  --context=dir:///workspace \
  --cache=true \
  --cache-repo=ghcr.io/you/app/cache

The --cache-repo flag stores layer caches in a registry, so CI runners without local storage still benefit from caching.

Related on TokRepo

• DevOps tools -- CI/CD and container infrastructure tools.
• Security tools -- Secure build pipelines without privileged containers.

Common pitfalls

• Kaniko does not support all Dockerfile instructions identically. Test complex multi-stage builds locally before deploying to CI.
• Registry authentication must be configured via /kaniko/.docker/config.json. Missing or expired credentials cause silent push failures.
• Build context must be accessible from inside the Kaniko container. For git contexts, ensure the repository is public or provide credentials.