TECH BASICS

Getting started with Kaniko

Building Container Images in Kubernetes (Securely)

Photo by on

Google’s project is designed to make container building easier on Kubernetes without giving access to docker daemon!

Kaniko

As Per Kaniko,

kaniko doesn’t depend on a Docker daemon and executes each command within a Dockerfile completely in userspace. This enables building container images in environments that can’t easily or securely run a Docker daemon, such as a standard Kubernetes cluster.

How Docker Images are Build on your System?

Docker Images are build using a standard Dockerfile that relies upon interactive access to a Docker daemon. You might have noticed while building images that Docker daemon requires root access on your machine to run. If you want to do this inside a container then a similar security risk will be there. You need to run your container in privileged mode and it will access the node’s filesystem and docker daemon.

What is wrong with this Image Build Process?

It's the root Access! We need to have a system where the container image build process should not expose the system with high privilege user. If we have to access the Docker daemon for image build then it should be secure.

For Container Security, I recommend to have a look on this .

What is Kaniko?

K, an open-source tool for building container images from a Dockerfile without privileged root access so it can be run in any environment. With kaniko, you can do both tasks, build an image from a Dockerfile and push it to a registry. Since it doesn’t require any special privileges or permissions, you can run Kaniko in a standard Kubernetes cluster or in any environment that can’t have access to privileges or a Docker daemon.

How does Kaniko work?

Kaniko uses an executor image gcr.io/kaniko-project/executor that runs inside a container. It takes in three arguments: a Dockefile, build context and the name of registryto which it will push the final image.

# kaniko arguements Dockerfile [–dockerfile] – File required to build the image
Build context [–context] – represents a directory containing a Dockerfile which kaniko will use to build your image
Destination [–destination] – Container registry.
If we don't want to push the image we can override the behavior by using the –no-push flag instead.

Supported by Kaniko as of now-

  • GCS Bucket
  • S3 Bucket
  • Azure Blob Storage
  • Local Directory
  • Local Tar
  • Standard Input
  • Git Repository

Steps it follows:

  1. Image is built from scratch, Kaniko reads the specified Dockerfile from Build Context
  2. Kaniko extracts the base image according to your docker file into the container filesystem.
  3. Kaniko snapshots the filesystem completely in user space within the executor image (avoids requiring privileged access) after every run.
  4. Appends the snapshot layer to the base layer on each run.

It's time for hands-on!

  1. We will create a Docker Secret first to use with Kaniko Build. This secret will be used by Kaniko to push images in your Docker Hub Repository
  2. We will prepare a Kaniko Build YAML to execute in Kubernetes.
  3. We will verify the available Image in Dockerhub!

Docker Secret Create

There are two ways by which you can create docker-registry secret. Using

docker registry user and password encoded in base64

echo USER:PASSWORD | base64

Create a config.json file with your Docker registry URL and the previous generated base64 string

{
"auths": {
"https://index.docker.io/v1/": {
"auth": "your credential's base64 string"
}
}
}

Use this file to create a secret -

kubectl create secret generic docker --from-file=.dockerconfigjson=<path/to/.docker/config.json> --type=kubernetes.io/dockerconfigjson

, the choice is yours -

kubectl create secret docker-registry docker --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

Now we have a secret to access Docker Hub, let’s create a Kaniko build YAML file to run in the Kubernetes cluster. You can create a Job or standard Podobject for Kubernetes build, the choice is yours. I always try to keep things simple so using Pod here. My suggestion will always be using Kubernetes Job. My account in GitHub contains the Dockerfile and required code base to build the image.

You may have noticed that it has a Docker secret mount as well which we have created earlier. Please make sure to create before executing this file.

Let’s execute the file using Kubectl -

$ kubectl apply -f kaniko.yaml

Now watch the logs

$ kubectl logs kaniko -f
Kaniko Logs

You can see in the logs that Kaniko executer has started pulling docker images layer and once the image is ready, it pushes the image to docker hub:-

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
kaniko 0/1 Completed 0 7m18s

Let’s verify the image in Docker Hub as well!

That’s it for the post. I hope you would have got some clarity on Kaniko and how it works. I will come up with more advance topics on using Kaniko in coming weeks. Till then, Take care and Stay Safe.

Keep Learning!

Fork into your GitHub account for all exercise files.

In quest of understanding How Systems Work !

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store