Are Distroless Images Worth the Trade-Offs?

Personally, as I got more familiar with Kubernetes and honed my debugging skills, I found I hardly ever needed to exec into a pod. Maybe just once or twice a year at most. For those rare situations, having debugging tools on every pod isn't practical.

We often start with FROM scratch for our images. This approach means you have a single executable with no unnecessary bloat. If we ever hit a limit where that's not feasible, then we will look at other options.

Many distroless images come with debug versions that include essential tools. It's also easy to use these images as a base and add your own debugging tools when needed. The point of distroless images is that if you can't access certain commands for debugging, neither can a malicious actor.

You can actually use kubectl debug to bring any additional debugging tools you might need directly into the same namespace as your container. The idea is to keep your production image clean and free from unnecessary debugging tools, which helps reduce the attack surface. Plus, using a multi-stage Dockerfile can help you separate your build and runtime dependencies, making your final image smaller and safer.

That's the idea behind distroless images! You shouldn't need to exec into production pods. If there's a problem, addressing it should be done in a way that doesn't require such access.