Securing Container Workflows: Building Docker Images Without Root Privileges Using Kaniko on Linux VPS

Introduction to Modern Container Security Challenges

In the landscape of modern cloud-native development, Continuous Integration and Continuous Deployment (CI/CD) pipelines are the backbone of software delivery. Traditionally, building a Docker image required access to a Docker daemon (dockerd). However, executing Docker commands inside a containerized pipeline—a pattern commonly known as Docker-in-Docker (DinD)—introduces severe security vulnerabilities.

To allow DinD to function, the host container must run in privileged mode. This configuration bypasses almost all security isolation mechanisms provided by Linux namespaces and cgroups, granting the container near-total access to the underlying virtual private server (VPS). If a malicious actor compromises a pipeline running in privileged mode, they can easily escape the container, compromise the host operating system, and gain full control over your infrastructure. This is where Kaniko emerges as a game-changing solution for DevOps and security engineering teams.

What is Kaniko?

Kaniko is an open-source tool developed by Google designed specifically for building container images from a Dockerfile without requiring a Docker daemon or root privileges. Because it does not depend on a background daemon process, Kaniko executes each command inside a standard, unprivileged container user space. This makes it an ideal fit for environments where security is paramount, such as multi-tenant Kubernetes clusters, shared build servers, and hardened Linux VPS instances.

How Kaniko Operates Without Root Access

Unlike the traditional Docker CLI, which sends instructions to a privileged host daemon to execute layers, Kaniko handles the entire build process internally. The execution flow follows a structured path:

Fetching the Context: Kaniko downloads and extracts the build context (your source code, configuration files, and Dockerfile) from a specified storage source, such as a Git repository, AWS S3 bucket, or local directory.
Unpacking the Base Image: It parses the FROM line in your Dockerfile, pulls the specified base image from a container registry, and extracts its file system into the root directory of the Kaniko container.
Executing Instructions: Kaniko runs each command specified in the Dockerfile sequentially in user space. After each command, it takes a snapshot of the userspace filesystem.
Diff Calculation and Layer Appending: It compares the snapshot against the prior state, isolates the changes into a new image layer, and appends that layer to the config.
Pushing to Registry: Once all steps are complete, Kaniko authenticates with the target container registry (e.g., Docker Hub, GitHub Packages, GitLab Container Registry) and pushes the newly minted image.

Key Takeaway: Because all file operations and binary executions happen purely within Kaniko's own user space allocation, the host system's Docker socket (/var/run/docker.sock) never needs to be exposed.

Why You Should Choose Kaniko Over Docker-in-Docker

When engineering secure software pipelines on a Linux VPS, choosing the right tool requires balancing efficiency with risk mitigation. Below is a structural comparison highlighting why Kaniko is superior for secure automation environments.

Elimination of Privileged Mode: Kaniko runs entirely in unprivileged containers, completely blocking container breakout attacks.
No Daemon Dependency: Traditional builds fail if the Docker daemon crashes or runs out of disk space on the host. Kaniko is self-contained and stateless, executing as a one-shot job.
Standard Compatibility: It reads standard Dockerfiles natively, requiring zero changes to your existing application build configurations.
Environment Agnostic: Whether you are running a standalone Ubuntu VPS, a lightweight Alpine environment, or a managed Kubernetes cluster, Kaniko behaves identically.

Step-by-Step Guide: Deploying Kaniko on a Linux VPS

To demonstrate the utility of Kaniko, we will walk through setting up a secure build process on a standard Linux VPS. In this scenario, we will build a Node.js application image and push it securely to a remote container registry without utilizing a local Docker daemon.

Prerequisites

Before proceeding, ensure your Linux VPS has the following utilities installed and configured:

A Linux VPS running a modern distribution (e.g., Ubuntu 22.04 LTS or Debian 12).
An unprivileged container runtime installed, such as Podman or a rootless configuration of Docker.
Valid credentials for a container registry (e.g., Docker Hub or GitHub Container Registry).

Step 1: Preparing the Application Context

First, create a dedicated project directory on your VPS and define a simple web application alongside its Dockerfile.

mkdir -p ~/kaniko-project/src
cd ~/kaniko-project

Create a basic Dockerfile within this directory:

FROM node:18-alpine
WORKDIR /app
COPY src/ .
RUN npm install --production
EXPOSE 3000
CMD ["node", "index.js"]

Step 2: Configuring Registry Authentication

Kaniko needs permissions to push the completed image to your registry. It accomplishes this by reading standard Docker config.json authentication files. Create a local credentials file securely:

mkdir -p ~/kaniko-project/.docker
cat < ~/kaniko-project/.docker/config.json
{
  "auths": {
    "[https://index.docker.io/v1/](https://index.docker.io/v1/)": {
      "auth": "$(echo -n 'YOUR_USERNAME:YOUR_PASSWORD' | base64)"
    }
  }
}
EOF

Note: Replace YOUR_USERNAME and YOUR_PASSWORD with your actual registry credentials. Ensure the permissions on this file are restricted to your current non-root user.

Step 3: Running the Kaniko Executor

We will execute the build using the official Kaniko executor image. We mount our project directory as the build context and our configuration folder to pass authentication tokens safely.

podman run --rm \
  -v ~/kaniko-project:/workspace \
  -v ~/kaniko-project/.docker:/kaniko/.docker:ro \
  gcr.io/kaniko-project/executor:latest \
  --dockerfile=/workspace/Dockerfile \
  --context=dir:///workspace \
  --destination=docker.io/YOUR_USERNAME/secure-app:latest

During execution, you will see output logs showing Kaniko unpacking the base image layers, running the npm install step, capturing filesystem changes in user space, and directly pushing the final artifact to Docker Hub—all without touching a privileged daemon socket.

Best Practices for Production Kaniko Deployments

To get the most security and performance benefit out of Kaniko on your Linux VPS, implement these production-grade strategies:

1. Enable Layer Caching

Because Kaniko completely tears down its filesystem after every run, it does not inherently benefit from local host caching like Docker does. To speed up builds, enable Kaniko's remote caching mechanism by adding the --cache=true and --cache-repo= flags. This tells Kaniko to push intermediate layers to your registry, allowing subsequent builds to pull unchanged layers instantly.

2. Restrict Directory Volatility

Kaniko scans the filesystem to determine layer differences. To prevent it from scanning unnecessary local host structures or safe system directories, explicitly leverage the --whitelist-var-run=false flag and configure a clean, minimal .dockerignore file within your context path.

3. Minimize Image Sizes

Keep your final production images small by implementing multi-stage Dockerfiles. Kaniko fully supports multi-stage builds, enabling you to compile assets in a heavy development layer and copy only production-ready binaries into a minimal, secure distroless or Alpine runtime layer.

Conclusion

Securing CI/CD automation pipelines requires removing legacy operational risks like privileged execution modes. Kaniko solves this critical issue elegantly by rethinking how container images are constructed—shifting the process from a privileged daemon control level to an isolated, safe user-space layer manipulation. By adopting Kaniko on your Linux VPS infrastructure, you ensure robust compliance, significantly reduce the attack surface against container escapes, and maintain fast, scalable deployment workflows.