Google’s Kaniko project is designed to make container building easier on Kubernetes without giving access to docker daemon!
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 article.
What is Kaniko?
Kaniko, 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
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.
Build Context Supported by Kaniko as of now-
- GCS Bucket
- S3 Bucket
- Azure Blob Storage
- Local Directory
- Local Tar
- Standard Input
- Git Repository
Steps it follows:
- Image is built from scratch, Kaniko reads the specified Dockerfile from Build Context
- Kaniko extracts the base image according to your docker file into the container filesystem.
- Kaniko snapshots the filesystem completely in user space within the executor image (avoids requiring privileged access) after every run.
- Appends the snapshot layer to the base layer on each run.
It's time for hands-on!
- 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
- We will prepare a Kaniko Build YAML to execute in Kubernetes.
- 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
config.json file with your Docker registry URL and the previous generated base64 string
"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
or create secret directly, 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
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
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.
Fork this repository into your GitHub account for all exercise files.