Going Distroless with Minimus

​

Distroless explained

Distroless container images are minimal container images without a traditional Linux distribution such as Alpine, Red Hat UBI, Debian, Ubuntu, and Fedora. Distroless images are greatly slimmed down so they contain only the essential runtime dependencies required for an application to run and exclude package managers, shells, and debugging tools.

​

Faster pace of release

Since Minimus images are built directly from source, they are not dependent on a third-party operating system like Alpine or Debian. As a result, Minimus is able to release the updated packages within hours of the change in the upstream code and build images with the updated packages on a daily basis.

​

Reduced attack surface

Container images built on traditional Linux distributions carry significant security and operational overhead. They include package managers, shells, and numerous other utilities that expand the attack surface and increase image size. By removing everything except the runtime requirements and direct dependencies, distroless container images drastically reduce their package count and thereby their attack surface. Without shells, package managers, or development utilities, distroless images provide a minimal, hardened foundation for production workloads that align with security best practices: the less code in your production image, the fewer vulnerabilities now and in the foreseeable future.

​

The Minimus distroless solution

​

The challenge: building without traditional tools

The primary challenge when adopting distroless images is the build process itself. Traditional Dockerfiles rely on distribution package managers like apt-get, yum, or dnf to install dependencies during image construction. A pure distroless image cannot accommodate these commands, creating a migration barrier.

​

The Minimus solution: production & dev image pairs

The packages necessary to build an app often differ from the packages necessary to run the app. This understanding led Minimus to solve the distroless challenge through the complementary image pair strategy. Every Minimus image version comes in two variants: a production image and a dev image. The production image is lean and distroless, containing only runtime essentials. The dev variant includes development tools, a shell, a package manager, and anything else needed to build and test applications using familiar workflows. Learn more about Minimus dev images

​

General process adjustments

Adopting the Minimus solution can help you drastically improve your security posture. The distroless approach also involves the following practices:

• Moving out dev libraries from the production image. Learn more
• Separating the build stage from the runtime final build using multi-stage builds. Learn more
• Escalating privileges temporarily in the Dockerfile build stage to compensate for the non-root default user. Learn more
• Using Python virtual environments (venv) and other similar options. See example
• Switching to sidecar debugging tools so the production image doesn’t always include the extra packages. Learn more

​

What’s included in a distroless image?

A Minimus production image, like any distroless image, contains only the essentials to run:

• The application binary and its required dependencies
• Core runtime libraries (e.g., glibc)
• Certificates (for TLS)
• Language runtimes, if required (e.g., Python, Java, Node.js)

Since the fully distroless image is often too slim to work with during development, every Minimus production image has a complementary dev image variant that includes required developer tools, such as a package manager, shell, etc.

​

Package count comparisons

The SBOM of Minimus production images will (almost) always show a drastic reduction in the number of packages compared to the equivalent Ubuntu, Debian, and even Alpine image. Minimus production images are that much slimmer because they exclude the following:

• Shells (/bin/sh, bash)
• Package managers (apt, apk, yum)
• Core utilities (ls, cat, cp, etc.)
• Compilers and interpreters (unless essential for the application)
• System services or init systems

Minimus dev images will include these tools to allow users to keep their workflows and leverage multi-stage build techniques to produce more secure apps. Multi-stage builds with Minimus

​

nginx example

The nginx image is an interesting case in point. The standard image on Docker Hub has over 240 packages. The Minimus nginx image has 15 packages. That’s well over a 90% reduction in the number of packages. The SBOM for the nginx latest image shows the packages in the image include nginx-{version} and associated packages, ca-certificates-bundle, the core runtime library glibc and associated packages, and zlib for compression.

​

Migrating to distroless images with Minimus

​

Using multi-stage builds

You can instantly benefit from Minimus distroless images while still maintaining your existing build processes by adopting multi-stage builds and leveraging Minimus production-dev image pairs. In a multi-stage Dockerfile, you use the dev image (for example, dotnet-sdk:latest-dev) for the build stage which requires a package manager and development tools. Then you copy your artifacts and use the production image for the final runtime stage (for example, dotnet-sdk:latest). See multi-stage build tutorials for go This approach will allow you to maintain your existing build processes. You can continue using apt-get, curl, and other familiar commands in your build stages, while your final image remains minimal and secure.

​

Experimenting with direct package access

If you prefer, you can install Minimus packages directly using a package manager with Minimus images. Package access allows you to add Minimus packages directly in your Dockerfile. With direct package access, you’ll be responsible for rebuilding when packages are updated to fix CVEs. Image Creator - available with Enterprise Edition - automates this process, which is why it’s recommended. Learn more

​

Customizing private images (Enterprise Edition)

Once comfortable with Minimus images, you can move security forward with the Minimus Image Creator. Instead of installing packages at build time, you can pre-configure your private image with exactly what you need. This simplifies Dockerfiles, reduces build complexity, and further optimizes your container security posture. Image Creator enables you to customize Minimus images to meet your application requirements by adding specific packages, defining custom environment variables and more. Private images built with the Image Creator are actively maintained by Minimus just like any standard Minimus image, including daily updates, continuous vulnerability scanning, compliance reports, signatures, and a complete SBOM (Software Bill of Materials) report.

​

Building off static (Enterprise Edition)

If you are used to building an image from scratch by pulling a starter base image from Alpine or another distribution on Docker Hub and adding your own packages, Minimus Creator offers an optimal solution. Here’s how it works: If you are starting from a language framework, you can select the relevant image as your starter image, whether it is Ruby, Golang, etc. Otherwise, you can build off of Static, Glibc-Dynamic, Glibc-Dynamic-FIPS or another base image from the Minimus gallery. As the next stage, you can add any number of packages as suits your needs. The package selector offers every package available from the MinimOS distro, including FIPS alternatives. You can build anything you set your mind to. The Minimus build pipelines take care of building the image and maintaining and updating it daily, and will alert you of any conflicts or other issues if encountered. Building your private distroless image from scratch is truly effortless with Minimus Creator. As an added benefit, Creator also supports bundling certificate files and custom configuration files, and managing environment variables as part of the build. Minimus Creator outputs a single-layer image which has the advantage of being smaller and faster to pull than an image built with Dockerfile.