Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 146 of 8022. Docker Image LifecycleFree lesson

Implementing Minimalist Distroless Base Images

Reduce your attack surface by replacing heavy OS-based base images with distroless alternatives that contain only your application and its dependencies.

In this lesson, you will learn how to harden your production containers by stripping away unnecessary operating system components using "distroless" base images.

Understanding Distroless Images

When you use a base image like ubuntu or alpine, you are including a package manager, a shell (/bin/sh), and various utility tools. While these are great for development, they become a liability in production. If an attacker manages to execute code inside your container, these pre-installed tools act as a "toolkit" that allows them to explore your file system, download malicious scripts, or escalate privileges.

A "distroless" image contains only your application binary and its direct runtime dependencies (like shared libraries). It does not contain a shell, package managers, or any other programs you might expect in a standard Linux distribution. By removing these, you reduce your attack surface significantly.

Implementation via Multi-Stage Builds

Because distroless images lack a shell and package manager, you cannot use apt-get or apk to install dependencies inside them. Instead, you must build your application in a "build" stage and copy the resulting binary into the distroless image.

Here is how a typical implementation looks:

# Stage 1: Build the application
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o my-app main.go

# Stage 2: Distroless production image
FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/my-app /my-app
ENTRYPOINT ["/my-app"]

In this example, the final image is incredibly small and secure. If an intruder gains access to the container, they cannot run ls, curl, or even sh, because those files simply do not exist in the environment. This forces the attacker to operate in a "blind" environment, making it substantially harder to conduct reconnaissance or move laterally within your Kubernetes cluster.

By shifting from a heavy OS-based image to a distroless one, you ensure that your production environment contains nothing but what is strictly necessary to run your code.

Key Takeaway: Distroless images remove unnecessary tools like shells and package managers from your final container, effectively neutralizing an attacker's ability to use your own environment against you.