26 / 75 · 08 Infrastructure as Code Testing · Minimal Container Images← prev⊞ allnext →☰ Read as one page
5.4Distroless Images: The Sweet Spot
Google's distroless images contain only the language runtime and your application. No shell, no package manager, no OS utilities. This makes them ideal for production because even if an attacker gets code execution, they have no tools to work with.
Available Distroless Images
| Image | Contents | Use Case |
|---|---|---|
gcr.io/distroless/static-debian12 |
CA certs, tzdata | Static binaries (Go, Rust) |
gcr.io/distroless/base-debian12 |
glibc, libssl, CA certs | C/C++ applications |
gcr.io/distroless/cc-debian12 |
glibc, libgcc, libstdc++ | C++ applications |
gcr.io/distroless/nodejs24-debian12 |
Node.js 24 (LTS) runtime | Node.js applications |
gcr.io/distroless/python3-debian12 |
Python 3 runtime | Python applications |
gcr.io/distroless/java21-debian12 |
OpenJDK 21 | Java applications |
Debugging Distroless Containers
The lack of shell makes debugging harder. Use debug variants in non-production:
# Debug variant includes busybox shell
# Use ONLY in development/staging, never production
docker run -it gcr.io/distroless/nodejs24-debian12:debug sh
# For production debugging, use ephemeral containers in K8s
kubectl debug -it myapp-pod --image=busybox --target=myapp-container