7 questions for distroless and small Linux distros
Distroless container images fit perfectly into the trend of downsizing every tool we use in our daily lives — cars, headphones, laptops — with the single purpose of doing more while occupying less space. As such, distroless containers seem to bring a double profit — decreased cloud expenses and minimized attack surface.
But if you opened this article, you likely have some questions about the actual value of distroless images, and we will try to answer them.
1. “Why do I need a full-blown Linux distro if an application can run without it? That’s the beauty of distroless — get rid of an OS, save space and trouble.”
To set the record straight — distroless images are not distroless.
Although they are served up as ones containing only the application and runtime dependencies without an OS, the only genuinely distroless images are built from scratch. Such OS-less scratch images can be used to run simple statically linked hello-world apps. But the absence of an OS deems running any enterprise-grade application impossible, as there are no
- Certificate data for proper TLS management;
- libc for dynamically compiled languages;
- Necessary components for regular work: timezone, passwd, group folders, etc.
So distroless images (which should be called “almost distroless” but it won’t make a good selling point, will it?) do contain a Linux distribution, albeit an incredibly stripped-down one, without a package manager, shell, or other typical Linux components. This approach is in line with the modern practices of running an application in the immutable container, meaning that we have no need for introducing system changes or utilizing libraries not involved in app’s work.
2. “Even if there is a Linux distro in distroless, what’s in it for me? They are still smaller than average Docker images.”
Well, the fact that the application relies on the operating system makes it hard to keep the image slim. Let’s take a look at the most popular distroless images produced by GoogleContainerTools (the data is valid as of January 9, 2023):
- gcr.io/distroless/static-debian11 — 2.34 MiB — includes ca-certificates, timezone data, a etc/passwd entry, and a /tmp directory. Statically-linked applications will benefit from this image, but what if your application has dynamic features and requires libc?
- gcr.io/distroless/base-debian11 — 17.3 MiB — is built upon the static image and includes glibc, libssl, and openssl. The image is optimal for dynamically-linked programs, but even in this case, you may require additional shared libraries, which takes us to another level (or layer, for that matter).
- gcr.io/distroless/cc-debian11 — 19.6 MiB — is built upon the base image and includes libgcc1 with dependencies. What about interpreted or VM-based languages (Java, Python, JavaScript)?
- gcr.io/distroless/java11-debian11 — 210 MiB — includes a base Linux image plus OpenJDK with dependencies.
The more dynamic your application is, the more OS libraries it needs, so the image size bloats.
Distroless image size
3. “How do I configure a distroless image if my app doesn’t fit?”
Unless your application functions perfectly with distroless/static, you are engaging in a zero-sum game. By winning a few MiB of space, you make significant sacrifices in terms of functionality:
- Distroless containers are hard to debug due to the absence of shell access. You need to master advanced Kubernetes techniques (if you are planning to manage your containerized application with a container orchestration platform) or introduce other technologies into your project, such as ephemeral containers.
- Configuration of distroless images is anything but simple. To adjust Google's images, you need to know bazel, and adding new packages is complicated without a package manager. A limited range of out-of-the-box distroless images increases the risk of the image being incompatible with your app.
To sum up, it is wiser to save resources by selecting an optimal Linux base image (some modern OSs are similar to or smaller than distroless/base) or mastering at least one Docker container image reduction technique.
You can also tune the JDK for resource constraint containers. Learn how to do that in a dedicated guide.
4. “Even if distroless images are not the smallest possible solutions, they are still more secure thanks to a smaller attack surface.”
The attack surface is not the sum of all software components but of attack vectors — the potentially exploitable paths or scenarios. It means that not all files in your container can be used by attackers. Such components as config files, locale, man pages. etc., are less likely to contribute to the attack surface than files sitting in the direct execution path: web servers, libc, encryption modules, etc.
Although distroless images indeed have few Linux components left, they cannot guarantee foolproof security for several reasons:
- As we saw, they still contain a Linux distribution. Therefore, they can have nested vulnerabilities. A missed CVE bears a more significant risk of exploits than a bunch of files off the direct execution path.
- Distroless updates are aligned with upstream Debian releases. Debian is a community-based distribution without commercial support. If you encounter a security issue in your container, you must submit a request and wait for the community to provide a patch, which may take time.
- Software standardization that contributes to enhanced security and accelerated remediation is challenging with distroless images. The inability to use the same distroless image with the same Linux distro and version for all workloads increases the attack surface.
- Apart from Linux, the dependencies you use for your project and the runtime for VM-based languages are also associated with security risks. A distroless image for Java apps includes an OpenJDK-based Java runtime, so you have to be sure it is updated just as regularly as Linux and includes all the latest security patches.
Summarizing, regular software updates, standardization, and lack of CVEs impact the attack surface much more than the number of components. A distroless image with critical vulnerabilities that you are unaware of or can’t fix properly won’t do you any good.
5. “How do I choose a Linux distribution that is both small and secure?”
Luckily, the sun doesn’t rise and set on distroless. But if you ask yourself the above question, you have already considered Alpine Linux — the compact distro of only 5 MiB in size — and rejected it as unfit for your project. Perhaps, you need LTS releases for a convenient upgrade schedule? Or optional commercial support to receive prompt fixes and security patches? Or you could have burned yourself on musl libc and found that solving compatibility and performance issues is not an option. Either way, Alpine Linux is off the table.
The idea behind Alpine Linux — make a Linux distro as clean and compact as possible — inspired BellSoft engineers to create an enterprise-grade Alpine: vendor-backed, affordable, secure, and flexible. And this is how Alpaquita Linux came to be.
6. “Is Alpaquita Linux more performant than Alpine?”
Alpaquita is based on Alpine, and therefore boasts the same size reduction strategies with a few significant bonuses:
- musl libc at the core of Alpine and Alpaquita has a cleaner code base and is much smaller than another widespread C library implementation, glibc. We went even further and optimized the standard musl implementation to meet or exceed the glibc performance. As a result, Alpaquita with musl perf demonstrates impressive performance compared to popular Linux distributions.
- Additional Alpaquita version with glibc is intended for companies wishing to avoid migration headaches. Our glibc is more compact than the default one, so glibc-based Alpaquita is still at least three times smaller than other popular distros (see the chart below).
- Busybox, OpenRC, and apk utilized in Alpaquita are lightweight alternatives to utilities used in other Linux distributions.
- If you need additional packages, they can be easily installed from Alpaquita repositories using apk.
The picture below shows the comparison of the most widely used Linux distros in terms of size.
Linux container image size
And here is the comparative graph for base Docker images with and without a JDK:
Linux Docker image size with and without JDK
As you can see, you can have a minuscule yet fully functional Linux that can be tailored to your application without inflating the Docker container image.
7. “Is Alpaquita Linux more secure than Alpine?”
To make Alpaquita an optimal choice for enterprise applications, we hardened the kernel and userspace security, including but not limited to the following:
- Kernel lockdown, including early in boot and kernel signing with SHA-512;
- Userspace compilation options:
- -fPIE, -pie 一 position independent executable to protect from memory corruption attacks;
- -fstack-protector-strong 一 enables stack overflow security checks for routines with any buffer;
- -Wformat-security 一 warns about possible security problems;
- -Wtrampolines 一 warns when generating a trampoline in an object that requires an executable stack.
- Support for Secure Boot, a UEFI security protocol validating the authenticity of the loaded code.
In addition, we provide LTS Alpaquita releases with a strict update schedule, security advisory (underway), and 24/7 commercial support.
Coupled with advanced security features, you can ensure your image safety thanks to timely updates and swift security patches offered by a reliable vendor.
Discover more tips and recommendations on keeping your containers secure in our guide.
“So distroless images are not a perfect solution, after all.”
It would be more precise to say that distroless is not a one-size-fits-all solution. Some applications will run with distroless/static, while others may be a perfect fit for distroless/base. In most cases, however, the complicated workflow and constant image monitoring for vulnerabilities may outweigh the possible pros of distroless.
A viable alternative to distroless images is to optimize the Docker images by reducing the OS layer and cutting the runtime for VM-based apps.
We recommend considering Alpaquita Linux for your project — we already optimized it for you and made it as small, flexible, performant, and secure as required for enterprise applications. Visit our Docker Hub repository, choose an image, and try it with your app!
And for Spring Boot developers, we created Alpaquita Containers that will reduce the RAM consumption of Spring Boot apps by up to 30 %. Try them with your project and tell us what you think!
