Log in / Register Account

What is attack surface anyway? In one of Aesop’s Fables, The Town Mouse & the Country Mouse, the country mouse says to the city mouse, "You may have luxuries and dainties that I have not," …  "but I prefer my plain food and simple life in the country with the peace and security that go with it." This is a concept familiar to even the ancient Greeks. In any system, there’s less headache, less stress, and less risk when you depend on fewer moving parts. In computer security, we refer to this concept as attack surface. And, we are in a constant battle to reduce the attack surface, a struggle between convenience and minimization.

The quest to reduce the attack surface of Linux containers

In the quest to reduce the attack surface, there’s always a tension between smaller individual container images and total software within an environment (see also: Container Tidbits: Can Good Supply Chain Hygiene Mitigate Base Image Sizes?). It’s important to remember that attack surface expands for several main reasons:

  1. Convenience. Particularly, with open source, it’s easy to go grab a new piece of software or library to cut down on the code you have to write yourself. Every new piece of software utilized adds to the attack surface.

  2. Lack of coordination. It’s easy to ignore what your colleagues are using, and just grab the latest version of some library or package. Every new version of the same library or package adds to the attack surface.

  3. Quality. It’s hard to research how well maintained a library is. It’s hard to know how security-minded its creators are. It’s difficult to know if they scan the code for security problems. Low quality or unmaintained libraries increase the attack surface.

Red Hat Enterprise Linux provides high-quality libraries that are maintained by security minded people. To make it convenient to consume these libraries in containers, Red Hat introduced Red Hat Universal Base Image (UBI). 

Introducing the UBI Micro image

Standardizing on UBI has always been a great way to reduce attack surface within a containerized environment (see also: Containers need standard operating environments too). Now, with Red Hat Enterprise Linux (RHEL) 8.4, we’re announcing UBI Micro to help reduce the attack surface of individual applications. 

UBI Micro is constructed from the exact same packages as UBI Standard, Minimal, and Init, but minimizes the individual image size by excluding a package manager and all of its dependencies which are normally pulled into a container image. 

Constructing a container image without the Linux distro’s packaging tools is sometimes referred to as distroless. By this criteria, UBI can be called a distroless container image built with RHEL content which is freely distributable for any use case you want. This reduces the attack surface of any individual image built upon it, as well as limiting the total amount of software within an environment when you standardize on RHEL (including OpenShift built on RHEL) and UBI (one glibc, one openssl, etc). Furthermore, the binaries and libraries in UBI come directly from RHEL. That means UBI has the same security response team, the same security hardening, and the same security metadata. 

UBI Micro is a high quality container image with a minimized attack surface and is great for some highly minimized applications, even if you use UBI Standard, Minimal, or Init for other applications.  Now, let’s see how it works in action.

Using UBI Minimal with Buildah

Let’s demonstrate how to build on the UBI Micro image using Buildah. The following commands will pull the image, mount it, install Apache and commit the image in the local container/storage cache:

microcontainer=$(buildah from registry.access.redhat.com/ubi8/ubi-micro)
micromount=$(buildah mount $microcontainer)
yum install \
    --installroot $micromount \
    --releasever 8 \
    --setopt install_weak_deps=false \
    --nodocs -y \
    httpd
yum clean all \
    --installroot $micromount
buildah umount $microcontainer
buildah commit $microcontainer ubi-micro-httpd

Now, check out how big it is:

podman images | grep ubi-micro-httpd

Output:

localhost/ubi-micro-httpd                                     latest                                                       7c557e7fbe9f  22 minutes ago  151 MB

That’s it, it’s that simple. Using the version of Buildah included in RHEL8, it’s that easy to build upon UBI Micro as a base image. This Apache image weighs in at 156MB on disk and 55MB across the wire. Not bad compared to the standard Apache httpd 2.4 image from Red Hat which is 403MB on disk and 147MB across the wire. 

For more technical information, check out the Building, running, and managing containers guide in the official RHEL 8 documentation.


About the author

Scott McCarty is technical product manager for the container subsystem team, which enables key product capabilities in OpenShift Container Platform and Red Hat Enterprise Linux. Focus areas includes container runtimes, tools, and images. Working closely with engineering teams, at both a product and upstream project level, he combines personal experience with customer and partner feedback to enhance and tailor strategic container features and capabilities.