Google’s kaniko - An open-source build tool for Docker Images in Kubernetes, without a root access

Google recently introduced kaniko, an open-source tool for building container images from a Dockerfile even without privileged root access.

Prior to kaniko, building images from a standard Dockerfile typically was totally dependent on an interactive access to a Docker daemon, which requires a root access on the machine to run. Such a process makes it difficult to build container images in environments that can’t easily or securely expose their Docker daemons, such as Kubernetes clusters. To combat these challenges, Kaniko was created.

With kaniko, one can build an image from a Dockerfile and push it to a registry. Since it doesn’t require any special privileges or permissions, kaniko can even run in a standard Kubernetes cluster, Google Kubernetes Engine, or in any environment that can’t have access to privileges or a Docker daemon.

How does kaniko Build Tool work?

kaniko runs as a container image that takes in three arguments:
- a Dockerfile,
- a build context and
- the name of the registry to which it should push the final image.

The image is built from scratch, and contains only a static Go binary plus the configuration files needed for pushing and pulling images. googles-kaniko-open-source-build-tool-for-docker-images-in-kubernetes-img-0 kaniko image generation

The kaniko executor takes care of extracting the base image file system into the root. It executes each command in order, and takes a snapshot of the file system after each command.

The snapshot is created in the user area where the file system is running and compared to the previous state that is in memory. All changes in the file system are appended to the base image, making relevant changes in the metadata of the image.

After successful execution of each command in the Dockerfile, the executor pushes the newly built image to the desired registry.

Finally, Kaniko unpacks the filesystem, executes commands and takes snapshots of the filesystem completely in user-space within the executor image. This is how it avoids requiring privileged access on your machine. Here, the docker daemon or CLI is not involved.