Why Devs and ISVs Need to Rethink their Base Container Image Strategy
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
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.
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.
SUSE provides two sets of images through its registry, the base ones:
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:
Check out the registry!
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
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
$ 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
[...] 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
➜ 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.
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.