DEV Community

Srinivasaraju Tangella
Srinivasaraju Tangella

Posted on

How I Built a Secure CI/CD Pipeline Using Kaniko, Jenkins, and Kubernetes

#kubernetes #devops #security #cicd

What is Kaniko?

Kaniko is a container image builder that lets you build Docker images without using Docker.
It works perfectly inside Kubernetes, Jenkins, GitHub Actions, and other CI/CD tools where running Docker daemon is not allowed or is unsafe.

🧠 Why Kaniko is Needed

Normally, Docker builds require:

A Docker daemon

Privileged access

Docker socket mounting

These are high security risks, especially inside Kubernetes.

Kaniko solves this by building images safely in unprivileged mode — no root, no socket, no daemon.

🔐 Kaniko Key Advantages

You can build Docker images inside Kubernetes safely

No need to run Docker-in-Docker (DinD)

No need for privileged containers

Works entirely in userspace

Fully compatible with Dockerfile syntax

Designed for secure CI/CD pipelines

🔧 Where Kaniko is Used

Kaniko is widely used in:

Jenkins Pipelines

GitLab CI

GitHub Actions

Tekton / Argo Workflows

Kubernetes-native CI/CD setups

Whenever you want image builds without Docker daemon, Kaniko is the right tool.

⚙️ How Kaniko Works

1.It reads your Dockerfile

2.Executes each command inside a container

3.Builds each layer one by one

4.Creates a final image

5.Pushes the image to registry (Docker Hub, ECR, GCR, Harbor, etc.)

You get the same output image as Docker build — but more securely.

📘 Example: Running Kaniko

A typical Kaniko command looks like this:

/kaniko/executor \
--dockerfile Dockerfile \
--context ./ \
--destination registry.example.com/myapp:v1

🧩 Kaniko in Jenkins Pipeline

sh """
/kaniko/executor \
--dockerfile=Dockerfile \
--context=${WORKSPACE} \
--destination=${IMAGE}:${BUILD_NUMBER}
"""

Kaniko Architecture:

1️⃣ Core Purpose of Kaniko

Build container images without Docker daemon

Run securely in unprivileged containers

Designed for Kubernetes + CI/CD environments

Fully supports Dockerfile syntax

2️⃣ Major Components in Kaniko Architecture

A.Kaniko Executor

The main binary responsible for building images

Reads and interprets Dockerfile

Executes each instruction in isolated environment

Builds layers sequentially

Writes image layers to final tarball

Pushes image to container registry

B.Build Context

Contains all files required for the build

Can come from:

Local filesystem

Git repository

Tarball

GCS/AWS/S3 buckets

Passed to kaniko using --context

C.Filesystem Snapshotter

Watches filesystem after each Dockerfile instruction

Detects changes made in each step

Creates layer diffs

Makes image layers deterministic and cacheable

D.Image Layer Builder

Converts file diffs into image layers

Compresses and optimizes layers

Stores temporary layers inside /kaniko directory

Creates manifest and config JSON

E.Registry Writer

Supports authenticated pushes

Works with:

Docker Hub

ECR

GCR

Azure ACR

Harbor

Uses OCI/Docker registry APIs

Pushes built layers + manifest to target registry

3️⃣ How Kaniko Executes Build Internally

Step 1—Load the Dockerfile

Reads Dockerfile line by line

Parses instructions (FROM, RUN, COPY, ENV…)

Validates syntax

Step 2—Pull the Base Image

Pulls the image defined in FROM

Extracts its filesystem

Uses it as starting point

Step 3—Execute Each Dockerfile Instruction

For each instruction:

Creates temporary filesystem

Executes instruction using real Linux commands

Takes a snapshot of file changes

Generates new layer

Step 4—Build OCI-Compliant Image

Combines all layers

Creates image metadata (manifest, config)

Assembles final image

Step 5—Push Image to Registry

Authenticates via secret

Uploads layers

Uploads manifest

Tags the image

4️⃣ Kaniko Execution Environment (What It Needs)

A.Container Runtime

Runs inside Kubernetes Pod

Requires no privileged mode

B.Scratch Space

Uses /kaniko folder as working directory

Stores layers, snapshots, metadata

C.Credentials

Can work with:

Kubernetes Secret (recommended)

Google Credentials

AWS IAM roles

Docker config file

D.Network Access

Pull base images

Push final image to registry

5️⃣ Security Architecture Advantages

No Docker daemon → no root access

No need to mount /var/run/docker.sock

Restricted container permissions

Safe for multi-tenant Kubernetes clusters

CIS-compliant and cloud-native

6️⃣ Kaniko vs Docker Daemon Internal Architecture

Docker Daemon

Requires root

Runs background service

Manages image layers + build engine

Needs privileged container for CI

Kaniko

Runs as normal user

No daemon

Self-contained executor

Safer for CI/CD

Kubernetes-native building

7️⃣ Why Kaniko Works Best in Kubernetes

Stateless

Does not depend on host Docker

Fully isolated build environment

Can run in Pod, Job, Tekton, Argo CD, Jenkins

Easy to scale image builds in cluster

🚀 2.Jenkinsfile Using Kaniko

pipeline {
agent none

stages {
    stage('Build Image with Kaniko') {
        agent {
            kubernetes {
                yaml """
Enter fullscreen mode Exit fullscreen mode

apiVersion: v1
kind: Pod
spec:
containers:

  • name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    command:

    • cat tty: true volumeMounts:
      • name: docker-config mountPath: /kaniko/.docker/ volumes:

    • name: docker-config
      configMap:
      name: docker-config
      """
      }
      }
      environment {
      IMAGE_NAME = "myrepo/myservice"
      TAG = "v${BUILD_NUMBER}"
      }

      steps {
    container('kaniko') {
        sh """
            /kaniko/executor \
            --dockerfile=Dockerfile \
            --context=${WORKSPACE} \
            --destination=${IMAGE_NAME}:${TAG} \
            --cleanup
        """
    }
}

      }
      }
      }

🔧 3.Kaniko Pod Template for Kubernetes

apiVersion: v1
kind: Pod
metadata:
name: kaniko-builder
spec:
containers:

  • name: kaniko image: gcr.io/kaniko-project/executor:latest args:
    • "--dockerfile=Dockerfile"
    • "--context=git://github.com/user/repo.git"
    • "--destination=myrepo/app:latest" volumeMounts:
      • name: docker-config mountPath: /kaniko/.docker volumes:
  • name: docker-config secret: secretName: docker-creds

📦 4.Kaniko vs BuildKit

✔ Kaniko

Best for Kubernetes CI/CD

Works without privileged mode

Pure userspace execution

Very secure

100% Dockerfile compatibility

Slightly slower for complex builds

✔ BuildKit

Faster due to parallel layer building

Requires privileged mode (unless using rootless mode)

More advanced caching

Best for local builds or trusted CI

Used by docker buildx

🔥 5.Kaniko vs Docker Build

Kaniko

Designed for Kubernetes

Works without Docker daemon

Does not require root

Very safe for multi-tenant clusters

Best for cloud-native CI/CD

Docker Build

Requires Docker daemon

Needs privileged container

Cannot run safely inside Kubernetes

Fast and simple—best for local dev

🏆 6.Full Flow: How Kaniko Works

1.Kaniko container starts inside Kubernetes

2.It reads your Dockerfile

3.It downloads the base image layers

4.Executes each Dockerfile instruction (COPY, RUN, ADD)

5.Builds the entire filesystem layer by layer

6.Creates final OCI image

7.Pushes to registry

8.Pod is cleaned up (if --cleanup used)

You get the same final image as traditional Docker build — but securely.

📘 7.Best Dockerfile Tips for Kaniko

Always use specific base images:
FROM python:3.11-slim

Avoid ADD unless needed; use COPY

Prefer multi-stage Dockerfile

Reduce RUN steps to fewer layers

Avoid interactive flags (e.g., apt-get -y)

🏆 Short Summary

Kaniko is a secure, Kubernetes-native tool to build Docker images
without Docker daemon or privileged mode.
Perfect for CI/CD pipelines.

Top comments (0)