Ever tried to shrink your container images to reduce their attack surface? If you have, you’ve likely discovered a frustrating paradox: shrinking a container often blinds your vulnerability scanners to what’s inside.

We’re facing an industry-wide tension between reducing container attack surfaces and maintaining the security visibility you need. To understand how we got here, and how we can solve it, we have to look at how we historically built containers, and why the current approaches fall short for Day 2 operations.

For a long time, full container images were the industry standard. The workflow was simple: developers pulled a base image that included a complete operating system, bundled their application code on top, and shipped it to production.

KubeCon + CloudNativeCon is taking place in Salt Lake City from November 9 to 12. Register Now!

While convenient, this posed a massive security problem. These images included a shell, a package manager, and countless tools and utilities the application never used at runtime. Every piece of unused software in that container represented a potential vulnerability and an unnecessarily large attack surface. If a malicious actor breached the application, they suddenly had a full toolkit to download additional utilities and escalate the attack.

To address these security concerns, the “distroless” movement emerged. The idea made sense: while full container images had a larger attack surface because of countless unnecessary components, the distroless approach sought to strip the container down to the bare-minimum dependencies needed for the application to run. No shell, no package manager, no extra utilities.

Source link