Why Devs and ISVs Need to Rethink their Base Container Image Strategy 

Introduction

In a world where stability, agility and security compliances are hot topics, it is important to decide the base image for the applications (current and new ones). In this blog I will talk about the most widely used images by application developers, introducing SUSE BCI, its registry and their multiple features. I will finish with a hands-on using the images and performing some buildings.

I started working as a Linux system administrator in 2007. I have worked in several verticals, public sector (emergency services), retail, pharmaceutical, energy and fintech. During this time, I have served as a Linux and Databases (SQL/NOSQL) administrator, Services (former consultant), Architect, Instructor, and now a Technical Marketing Manager at SUSE.

In the past few years, I have seen many environments where individuals and corporations are using Alpine or Ubuntu images to build their applications. The latest market research confirms that most organizations usually use base images that avoid vendor lock-in

Source: All About That Base Image, Vulnerable Base Container Images, Noisy Scanners, and the Case for “Quiet” Images.

Along with the language-specific images, with no more than 10 packages and a very tiny fingerprint, Alpine is the most used image by developers in GitHub.

Why SLE BCI?

SUSE recently announced:

“SUSE Linux Enterprise Base Container Images (SLE BCI) provide truly open, flexible, and secure container images and application development tools. The images consist of container environments based on SUSE Linux Enterprise and designed to be a secure base for any containerized workload.”

While Alpine is the most used base image, when it comes to an enterprise use case, we should consider more variables before making a choice. Here are some of the reasons why SLE BCI (which I will shorten to simply BCI for now) is potentially a great fit.

Maximum Security

When it comes to developing applications, the world is moving and working in a cloud-native ecosystem because of its emphasis on flexibility, agility and cost effectiveness. However, application security is often an afterthought in the initial stages of developing a new app. If developers do not choose their base image wisely, their application could be affected by security vulnerabilities, or it simply will not pass the required security certifications.

When developing the SLE family of products, SUSE has worked to ensure they meet the highest levels of security and compliance including FIPS (Federal Information Processing Standard), EAL4+, FSTEC, USG, CIS and DISA/STIG. All this work flows downstream to SLE BCI, making it one of the industry’s most secure base images for enterprise developers or independent software vendors to leverage.

Available images

SUSE provides two sets of images through its registry, the base ones:

• bci-base
• bci-minimal
• bci-micro
• bci-init

While the four images and the language-specific ones are available in our official registry, only bci-base is supported so far.

Along with the above images, SUSE also provides SDK and Runtime specific ones, so you can use Golang, rust, OpenJDK and many others

Some of them are:

• bci/golang 
• bci/node 
• bci/openjdk 
• bci/python
• bci/ruby

[…]

Check out the registry!

Supportability

One of the key factors that made me give BCI a try is the supportability matrix.

So far, if I must test my application locally or for a Proof of Concept, I could use an Alpine or a specific language/runtime image. But when it comes to creating an enterprise-grade application, sooner than later, I will need to migrate to a supported one.

bci-base is fully supported by SUSE. Customers with an active subscription agreement can open support cases or request new features through the official channels.

Something else that captured my attention: the supportability matrix of BCI has no bounds with the underlying host where the application is running, which allows more flexibility and mixed ecosystems while keeping your application covered by the SUSE support umbrella.

Getting into Base Container Images

Considerations

SLES (SUSE Linux Enterprise Server) images are rpm-based distributions like many others. SUSE uses zypper to manage packages, so you must move from yum/rpm to zypper.

First some basic usage

FROM registry.suse.com/bci/bci-base
RUN zypper install --non-interactive apache2

Output

$ docker build -t t6:latest .
[...]
COMMIT t6:latest
--> c3467aa85eb
Successfully tagged localhost/t6:latest

Looks good — let’s try a sample application.

FROM registry.suse.com/bci/bci-base
RUN zypper refresh && zypper install -y apache2 curl
COPY ./httpd.conf /usr/local/apache2/conf/httpd.conf
COPY ./index.html /srv/www/htdocs/index.html

RUN chmod -R 775 /srv/www/htdocs/
CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]

EXPOSE 80

Output

[...]
COMMIT t7:latest
--> be602649633
Successfully tagged localhost/t7:latest
be602649633c9606828d313db0a78e0cfa8f1bdca5d8c6cd3153f1a699b9dc56

After running the container:

$ docker run -dit -p 1234:80 t7:latest 
2fe712f4807af813af9f58fa545c0936d932ddba7c6dc8870a70c9a382b4fb5b 

You have a httpd server running bci-base with SUSE stability and performance inherited from the OS.

Testing language-specific images

To this example, I am going to use a repository my colleague Matt Farina created: https://github.com/mattfarina/dc-hello-world

# syntax=docker/dockerfile:1.3

# Build the Go Binary

FROM registry.suse.com/bci/golang:1.17 as build

WORKDIR /app

COPY go.mod ./

COPY go.sum ./

RUN go mod download

COPY *.go ./

RUN CGO_ENABLED=0 go build -o /dc-hello-world

# Create image to bundle app

FROM scratch

COPY --from=build /dc-hello-world /dc-hello-world  EXPOSE 3000  CMD ["/dc-hello-world"]

The application consists of a hello-world Golang application built with golang:1.17 image

Let’s see the building

[…]
Successfully tagged localhost/farina:1 
10e7922ea3a644592242e923a9b18f11543a2de3f195ada4bd83d9ec560b52e5

Output:

➜  dc-hello-world git:(main) docker run farina:1
2022/05/08 00:21:06 [INFO]   Starting Hello World

Compilers and Libraries

Some applications need to be compiled and, of course, BCI also comes with the following compilers.

[...]

gcc                    | The system GNU C Compiler
maven               | Java project management and project comprehension tool
libgcc_s1 | C compiler runtime library
python3-pycryptodome | Cryptographic library for Python
libcryptopp-devel    | Development files for libcryptopp, a cryptographic library for C++
[...]

Testing BCI security

As per any application, you also need to be sure about the security, there are several container scans out there. For this article, I used Trivy:

2022-05-08T02:26:11.177+0200 INFO Need to update DB
2022-05-08T02:26:11.177+0200 INFO DB Repository: ghcr.io/aquasecurity/trivy-db
2022-05-08T02:26:11.177+0200 INFO Downloading DB...
31.69 MiB / 31.69 MiB [-------------------------------------------------------------------------------------------------------------] 100.00% 18.58 MiB p/s 1.9s
2022-05-08T02:26:14.484+0200 INFO Number of language-specific files: 1
2022-05-08T02:26:14.484+0200 INFO Detecting gobinary vulnerabilities...
dc-hello-world (gobinary)
=========================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

Ok, looks like there is nothing to be worried about because the images have a tiny fingerprint where the packages are well identified and the minimum required, so almost no space to risks. The specific language files are detected, and the scan works on the gobinary vulnerabilities.

Conclusion

SUSE brings the latest SLES capabilities and more than 20 years industry experience to the container field, providing not only availability of libraries, packages and performance but also a platform where users can develop, deploy, and use applications securely.

BCI are used widely for projects where stability, security and agility are important like Rancher, our platform for Kubernetes cluster management.

Look at what BCI has to offer: review the Base Container Images Documentation.