Distroless containers for security and size?

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.

What is distroless

Distroless image is a type of Docker image that contains only the essential components for running the application. This approach is in line with the modern practices of deploying the application to the cloud in an immutable container, meaning that we have no need for introducing system changes or utilizing libraries not involved in app’s work.

7 questions about distroless and small Linux distros

1. “Is there really no distribution in distroless?”

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.

2. “Are distroless smaller than traditional Docker images?”

Well, the fact 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 July 25, 2024):

• gcr.io/distroless/static-debian12 — 2.9 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-debian12 — 31 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-debian12 — 34 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/java21-debian12 — 205 MiB — includes a base Linux image plus OpenJDK (Eclipse Temurin) with dependencies.

The more dynamic your application is, the more OS libraries it needs, so the image size bloats.

Distroless image size

3. “How to debug or configure a distroless image?”

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.

4. “Are distroless more secure than regular Docker images?”

It is believed that distroless images are more secure due to smaller attack surface.

It should be noted first that 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.

How to use distroless with Java

If you decide to try distroless out with your Java application, here’s how you can do that.

We will take Spring Petclinic as an example, but you can use your own project.

Copy the following Dockerfile:

FROM eclipse-temurin:21.0.3_9-jdk-alpine as builder

WORKDIR /home/app
ADD spring-petclinic-main /home/app/spring-petclinic-main
RUN cd spring-petclinic-main && ./mvnw -Dmaven.test.skip=true clean package


FROM gcr.io/distroless/java21-debian12

WORKDIR /home/app
COPY --from=builder /home/app/spring-petclinic-main/target/*.jar petclinic.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/petclinic.jar"]

We use Docker multi-stage builds to build the jar file and then place it into the fresh image. This way, the final image will be free of unnecessary layers.

At the final stage, we take Google’s distroless image for Java based on Eclipse Temurin 21 and Debian.

Build the image with the usual command:

docker build -t petclinic-distroless .

Now, check the image size:

docker images
REPOSITORY             TAG       IMAGE ID       CREATED          SIZE
petclinic-distroless   latest    ebb8f2b96dd6   53 seconds ago   263MB

Before we make any conclusions, let’s build another image using Liberica Runtime Container. 

Distroless vs Liberica Runtime Container: compare image sizes

BellSoft’s Liberica Runtime Container is based on Liberica JDK Lite optimized for cloud and Alpaquita Linux.

We will need the following Dockerfile: 

FROM bellsoft/liberica-runtime-container:jdk-21-stream-musl as builder

WORKDIR /home/app
ADD spring-petclinic-main /home/app/spring-petclinic-main
RUN cd spring-petclinic-main && ./mvnw -Dmaven.test.skip=true clean package


FROM bellsoft/liberica-runtime-container:jre-21-musl

WORKDIR /home/app
COPY --from=builder /home/app/spring-petclinic-main/target/*.jar petclinic.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/petclinic.jar"]

Here, we build the project using the base image with Liberica JDK. After that, we copy the resulting jar to a fresh container with Liberica JRE.

Build the image and check its size:

docker build -t petclinic-alpaquita .
docker images
REPOSITORY                                          TAG                                                   IMAGE ID       CREATED             SIZE
petclinic-alpaquita                                 latest                                                325ba5c52e28   7 seconds ago       200MB

As you can see, an image based on Liberica Runtime Container is 63 MB smaller than the distroless-based one!

Conclusion

To sum up, 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!

Go to Alpaquita Linux Docker Hub repository