Module 05 · Lesson 01
Base Image Footprint
Why a smaller image is a smaller attack surface, and how to actually shrink one.
- Explain what a smaller base image removes, in concrete terms.
- Prove a capability is gone rather than assuming from the tag.
- Weigh distroless against debuggability.
What an attacker inherits from your base image
Anyone who executes code in your container gets whatever the image ships. A full distribution base hands them a package manager to install tools, a shell to script with, and networking utilities to move around with. A minimal image hands them their own binary and very little else.
The security claim is not "the image name looks minimal". It is that these specific capabilities are unavailable to anyone who compromises the container. That is a testable statement, and the command above is the test.
A spectrum, not a binary
| Base | Contains | Trade-off |
|---|---|---|
ubuntu, debian | Package manager, shell, full userland | Easy to debug, large attack surface |
alpine | Shell, busybox utilities, apk | Small, still fully interactive |
busybox | A shell and basic utilities only | Smaller, no package manager |
| distroless | The application and its runtime, no shell at all | Nothing to get a shell in, and kubectl exec -- sh no longer works |
scratch | Nothing | Only viable for static binaries |
With no shell, kubectl exec gives you nothing, which is exactly the point
and also a real operational cost. The answer is ephemeral debug containers, which attach
a tooling image to a running pod without the workload image carrying those tools
permanently: kubectl debug -it POD --image=busybox --target=app.
Fewer packages, fewer CVEs
A scan of a full distribution base routinely reports hundreds of findings in packages your application never calls. They are still findings, they still need triage, and they still appear on the report someone has to sign off. Shrinking the base is the cheapest way to make that list short enough to act on, which connects directly to scanning.
You change a Deployment from ubuntu to busybox. How do you confirm the security benefit?
Size correlates with surface but does not prove anything specific. The claim you are making is about which capabilities exist, so test that directly.
What is the operational cost of a distroless image?
That absence is the security property and the inconvenience at once. Ephemeral debug containers exist precisely to give the tooling back temporarily without shipping it in the image.
Why does base image choice affect your vulnerability report so much?
The CVEs are real; the exposure often is not, because nothing calls the affected code. Removing the packages removes the finding entirely, which is cheaper than triaging it every month.
A smaller base removes the tools an attacker would otherwise inherit, and the property to verify is their absence rather than the tag. Distroless goes furthest and costs you interactive debugging, which ephemeral debug containers give back. Next: proving where an image came from.