Blog Viewer

In the world of containerized applications, selecting the right base image is crucial for performance, security, and resource management. While upstream Java images serve their purposes, there are specific use cases where a Bitnami Secure Image Java Minimal image can offer significant advantages. Let’s explore when opting for a minimal image is the optimal choice.

What is a Bitnami Secure Image Java Minimal Image?

A Bitnami Secure Image Java Minimal image is a streamlined container image designed to include only the essential components required to run a Java application. This stripped-down approach eliminates unnecessary libraries, tools, and dependencies, resulting in a smaller image size and reduced security risks.

Use Cases for a Bitnami Secure Image Java Minimal Image

Here are several scenarios where a Bitnami Secure Images Java Minimal image shines:

1. Microservices Deployments

Microservices architectures emphasize lightweight, independent services. A minimal Java image perfectly aligns with this philosophy by providing a small footprint, enabling rapid deployment, and minimizing resource consumption.

BSI Java Minimal images are ideal for resource-constrained environments like edge computing and IoT due to their smaller size, which minimizes storage usage.

2. Enhanced Security

By reducing the number of components in the image, the attack surface is minimized. This lowers the risk of vulnerabilities and makes security auditing more manageable. A BSI Java Minimal image only includes necessary elements, decreasing potential security holes.

3. Cost Optimization

Using smaller images reduces storage and bandwidth costs in cloud environments. Additionally, lower resource consumption leads to potential savings on server costs.

The Security Benefits of Bitnami Secure Images Java Minimal Images

The choice of the underlying operating system significantly impacts the overall security posture of a container image. Utilizing Photon 5 as the base for BSI Java Minimal images provides an additional layer of security. This is because Photon 5, a lightweight Linux distribution, using a distroless approach that boasts a minimal attack surface due to its reduced number of packages and services. Consequently, it has fewer potential entry points for malicious actors and a lower count of Common Vulnerabilities and Exposures (CVEs) compared to more comprehensive operating systems. This streamlined foundation contributes to a more secure and robust environment for running Java applications within containers.

This public and up-to-date image is available at https://hub.docker.com/u/bitnamisecure. You can use it to build your own images as described in this blog post.

Comparison

For this comparison, we start with an out-of-the-box Spring Boot 3.5.3 application with Spring Web MVC as a dependency. We know that the recommended approach for building the container image of a Spring Boot application is using Paketo Buildpacks, but sometimes you need more control over the container image created, and hence, you manually create the Dockerfile. For example, when you need to install some dependencies like ffmpeg, curl, or CLI utilities.

FROM gradle:8.13-jdk21 AS build
ENV GRADLE_USER_HOME=/home/gradle/.gradle
WORKDIR /app

COPY settings.gradle* build.gradle* gradlew ./
COPY gradle ./gradle
RUN ./gradlew dependencies --no-daemon
COPY src ./src
RUN ./gradlew clean bootJar --no-daemon

# REPLACE THE IMAGE FOR EACH ONE YOU WANT TO TEST
FROM bitnamisecure/java-min:latest AS run
WORKDIR /app
COPY --from=build /app/build/libs/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

For comparing the different base container images, we are building a container image with the only difference that for the run stage, we use a different Java 24 image. We are also splitting them into two groups, the first one for Debian-based and similar distros, and the second one for “minimal” ones:

eclipse-temurin:24-jre
eclipse-temurin:24-jre-ubi9-minimal
bellsoft/liberica-openjre-debian:24

eclipse-temurin:24-jre-alpine
bellsoft/liberica-openjre-alpine:24
bitnamisecure/java-min:latest
cgr.dev/chainguard/jre:latest

Now, we are going to use Trivy to analyze the vulnerabilities (CVEs) of the different container images created and compare them along with the final container image size in megabytes:

(*) The bitnamisecure/java-min:latest container image stands out in its collection due to its exclusive FIPS support (more on that later), a feature contributing to its larger size compared to other images in the set.

The number of CVEs varies based on the chosen container image.

To enable a more accurate comparison, we can now group images and compare them within their respective categories, rather than mixing them all together. This allows for a more apples-to-apples analysis.

Debian and similar distros

For the Debian and similar distros, we select the first group from the previous table:

You can see that regarding size and CVEs the Temurin JRE has the smallest size and also the least number CVEs, even though there are some Low and Medium CVEs.

Minimal distros

Here's the interesting part: all four container images initially have zero CVEs. If minimizing size is the primary concern and an Alpine distribution is acceptable for production, liberica-openjre-alpine is the smallest option. However, it's crucial to be aware of the potential drawbacks of Alpine-based container images for Java applications. These include compatibility problems due to the use of musl instead of glibc (affecting some Java libraries, tools, and cryptographic providers), slower performance in IO-intensive tasks, and specific CA certificates that might cause SSL issues. While this image might function, thorough testing is strongly recommended to ensure it meets your application's requirements. Finally, on top of all of that, there are known issues regarding DNS resolution (remember: It’s always DNS…) when using Alpine.

Alpine, while suitable, is not the only factor to consider. In today's landscape, simply having a Secure Supply Chain and adhering to general security compliance is often insufficient. Organizations operating in regulated industries or with stringent security requirements frequently need to meet more demanding standards. Consider the necessity of achieving Software-Level Supply chain Attacks (SLSA) Level 3 compliance, a framework that ensures the integrity of software throughout its lifecycle. Similarly, adherence to Federal Information Processing Standards (FIPS) 140-2 and its successor, FIPS 140-3, may be mandatory for cryptographic modules used in government or other sensitive applications. Furthermore, Security Technical Implementation Guides (STIGs) provide specific configuration standards to harden systems against known vulnerabilities.

Bitnami Secure Images are designed to address these elevated security and compliance needs comprehensively. They are engineered to comply with a range of rigorous standards, including SLSA Level 3, FIPS 140-2 and 140-3, and STIG guidelines. This commitment to compliance offers organizations the assurance that their foundational software components meet the necessary security benchmarks, simplifying their own compliance efforts and reducing potential risks associated with non-compliant software. By leveraging Bitnami Secure Images, development and operations teams can confidently build and deploy applications within demanding security frameworks, knowing that the underlying image provides a robust and compliant foundation. This proactive approach to security and compliance is crucial in today's evolving threat landscape and regulatory environment. In this scenario is where our bitnamisecure/java-min:latest container image shines.

Conclusions

The choice of a Docker container image for Java applications involves a critical trade-off between image size and security vulnerabilities (CVEs). While various images offer different characteristics, a clear winner emerges when balancing both factors.

The bitnamisecure/java-min:latest image stands out as the optimal choice. It offers a significantly smaller image size while simultaneously boasting the lowest number of total CVEs across all severity levels. This combination makes it ideal for environments where resource efficiency and a minimal attack surface are paramount.

Bitnami Secure Images offer a robust solution for regulated industries with stringent security needs. Engineered to comply with SLSA Level 3, FIPS 140-2/3, and STIG, they simplify compliance and reduce risks. The bitnamisecure/java-min:latest container image excels, providing minimal size, CVEs, and adherence to critical security and compliance frameworks.

In conclusion, for optimal performance, enhanced security, and adherence to stringent compliance standards in containerized Java applications, the bitnamisecure/java-min:latest image presents a compelling and highly recommended solution.