4 SLE Base Container Images #

SLE Base Container Images (SLE BCI) are minimal SLES 15-based images that you can use to develop, deploy, and share applications. There are two types of SLE BCIs:

SLE Base Container Images are available from https://registry.suse.com. It contains tested and updated SLE base container images. All images in the SUSE Registry undergo a maintenance process. The images are built to contain the latest available updates and fixes. The SUSE Registry’s Web user interface lists a subset of the available images. For information about the SUSE Registry, see Section 3.1, “SUSE Registry”.

SLE base images in the SUSE Registry receive security updates and are covered by the SUSE support plans. For more information about these support plans, see Chapter 15, Compatibility and support conditions.

SLE BCIs offer a platform for creating SLES-based custom container images and containerized applications that can be distributed freely. SLE BCIs feature the same predictable enterprise lifecycle as SLES. The SLE_BCI 15 SP3 and SP4 repository (which is a subset of the SLE repository) gives SLE BCIs access to 4000 packages available for the AMD64/Intel 64, AArch64, PowerPC, and IBM Z architectures. The packages in the repository have undergone quality assurance and security audits by SUSE. The container images are FIPS-compliant when running on a host in FIPS mode. In addition to that, SUSE can provide official support for SLE BCIs through SUSE subscription plans.

4.2.1 Highlights #

 

• SLE BCIs are fully compatible with SLES, but they do not require a subscription to run and distribute them.

• SLE BCIs automatically run in FIPS-compatible mode when the host operating system is running in FIPS mode.

• Each SLE BCI includes the RPM database, which makes it possible to audit the contents of the container image. You can use the RPM database to determine the specific version of the RPM package any given file belongs to. This allows you to ensure that a container image is not susceptible to known and already fixed vulnerabilities.

• All SLE BCIs (except for those without Zypper) come with the container-suseconnect service. This gives containers that run on a registered SLES host access to the full SLES repositories. container-suseconnect is invoked automatically when you run Zypper for the first time, and the service adds the correct SLES repositories into the running container. On an unregistered SLES host or on a non-SLES host, the service does nothing. See Section 5.2, “container-suseconnect” for more information.

Note: SLE_BCI repository

There is a SLE_BCI repository for each SLE service pack. This means that SLE BCIs based on SP4 have access to the SLE_BCI repository for SP4, all SLE BCIs based on SP5 use the SLE_BCI repository for SP5, and so on. Each SLE_BCI repository contains all SLE packages except kernels, bootloaders, installers (including YaST), desktop environments, and hypervisors (such as KVM and Xen).

There are four general purpose SLE BCIs, and each container image comes with a minimum set of packages to keep its size low. You can use a general purpose SLE BCI either as a starting point for building custom container images, or as a platform for deploying specific software.

SUSE offers several general-purpose SLE BCIs that are intended as deployment targets or as foundations for creating customized images: SLE BCI-Base, SLE BCI-Minimal, SLE BCI-Micro, and SLE BCI-BusyBox. These images share the common SLES base, and none of them ship with a specific language or an application stack. All images feature the RPM database (even if the specific image does not include the RPM package manager) that can be used to verify the provenance of every file in the image. Each image includes the SLES certificate bundle, which allows the deployed applications to use the system’s certificates to verify TLS connections.

The table below provides a quick overview of the differences between SLE BCI-Base, SLE BCI-Minimal, SLE BCI-Micro, and SLE BCI-BusyBox.

4.3.1 SLE BCI-Base and SLE BCI-Init: When you need flexibility #

 

This SLE BCI comes with the Zypper package manager and the free SLE_BCI repository. This allows you to install software available in the repository and customize the image during the build. The downside is the size of the image. It is the largest of the general-purpose SLE BCIs, so it is not always the best choice for a deployment image.

A variant of SLE BCI-Base called SLE BCI-Init comes with systemd preinstalled. The SLE BCI-Init container image can be useful in scenarios requiring systemd for managing services in a single container.

Important: Using SLE BCI-init with Docker

When using SLE BCI-init container with Docker, you must use the following arguments for SYSTEMD to work correctly in the container:

> docker run -ti --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup:rw --cgroupns=host registry.suse.com/bci/bci-init:latest

To correctly shut down the container use the following command:

> docker kill -s SIGRTMIN+3 CONTAINER_ID

Language stack SLE BCIs are built on top of the SLE BCI-Base general-purpose SLE BCI. Each container image comes with the Zypper stack and the free SLE_BCI repository. Additionally, each image includes most common tools for building and deploying applications in the specific language environment. This includes tools like a compiler or interpreter as well as the language specific package manager.

Below is an overview of the available language stack SLE BCIs.

Application SLE BCIs are SLE BCI-Base container images that include specific applications, such as the PostgreSQL database and the Performance Co-Pilot a system-level performance analysis toolkit. Application SLE BCIs are available in the dedicated section of SUSE Registry.

All container images, except for base, are currently classified as tech preview, and SUSE does not provide official support for them. This information is visible on the web on registry.suse.com. It is also indicated via the com.suse.supportlevel label whether a container image still has the tech preview status. You can use the skopeo and jq utilities to check the status of the desired SLE BCI as follows:

> skopeo inspect docker://registry.suse.com/bci/bci-micro:15.4 | jq '.Labels["com.suse.supportlevel"]'
"techpreview"

> skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | jq '.Labels["com.suse.supportlevel"]'
"l3"

In the example above, the com.suse.supportlevel label is set to techpreview in the bci-micro container image, indicating that the image still has the tech preview status. The bci-base container image, on the other hand, has full L3 support. Unlike like the general purpose SLE BCIs, the language stack SLE BCIs may not follow the lifecycle of the SLES distribution: they are supported as long as the respective language stack receives support. In other words, new versions of SLE BCIs (indicated by the OCI tags) may be released during the lifecycle of a SLES Service Pack, while older versions may become unsupported. Refer to suse.com/lifecycle to find out whether the container in question is still under support.

Important

A SLE Base Container Image is no longer updated after its support period ends. You will not receive any notification when that happens.

podman inspect registry.suse.com/suse/sle15
[...]
"Labels": {
            "com.suse.bci.base.created": "2023-01-26T22:15:08.381030307Z",
            "com.suse.bci.base.description": "Image for containers based on SUSE Linux Enterprise Server 15 SP4.",
            "com.suse.bci.base.disturl": "obs://build.suse.de/SUSE:SLE-15-SP4:Update:CR/images/1477b070ae019f95b0f2c3c0dce13daf-sles15-image",
            "com.suse.bci.base.eula": "sle-bci",
            "com.suse.bci.base.image-type": "sle-bci",
            "com.suse.bci.base.lifecycle-url": "https://www.suse.com/lifecycle",
            "com.suse.bci.base.reference": "registry.suse.com/suse/sle15:15.4.27.14.31",
            "com.suse.bci.base.release-stage": "released",
            "com.suse.bci.base.source": "https://sources.suse.com/SUSE:SLE-15-SP4:Update:CR/sles15-image/1477b070ae019f95b0f2c3c0dce13daf/",
            "com.suse.bci.base.supportlevel": "l3",
            "com.suse.bci.base.title": "SLE BCI 15 SP4 Base Container Image",
            "com.suse.bci.base.url": "https://www.suse.com/products/server/",
            "com.suse.bci.base.vendor": "SUSE LLC",
            "com.suse.bci.base.version": "15.4.27.14.31",
            "com.suse.eula": "sle-bci",
            "com.suse.image-type": "sle-bci",
            "com.suse.lifecycle-url": "https://www.suse.com/lifecycle",
            "com.suse.release-stage": "released",
            "com.suse.sle.base.created": "2023-01-26T22:15:08.381030307Z",
            "com.suse.sle.base.description": "Image for containers based on SUSE Linux Enterprise Server 15 SP4.",
            "com.suse.sle.base.disturl": "obs://build.suse.de/SUSE:SLE-15-SP4:Update:CR/images/1477b070ae019f95b0f2c3c0dce13daf-sles15-image",
            "com.suse.sle.base.eula": "sle-bci",
            "com.suse.sle.base.image-type": "sle-bci",
            "com.suse.sle.base.lifecycle-url": "https://www.suse.com/lifecycle",
            "com.suse.sle.base.reference": "registry.suse.com/suse/sle15:15.4.27.14.31",
            "com.suse.sle.base.release-stage": "released",
            "com.suse.sle.base.source": "https://sources.suse.com/SUSE:SLE-15-SP4:Update:CR/sles15-image/1477b070ae019f95b0f2c3c0dce13daf/",
            "com.suse.sle.base.supportlevel": "l3",
            "com.suse.sle.base.title": "SLE BCI 15 SP4 Base Container Image",
            "com.suse.sle.base.url": "https://www.suse.com/products/server/",
            "com.suse.sle.base.vendor": "SUSE LLC",
            "com.suse.sle.base.version": "15.4.27.14.31",
            "com.suse.supportlevel": "l3",
            "org.openbuildservice.disturl": "obs://build.suse.de/SUSE:SLE-15-SP4:Update:CR/images/1477b070ae019f95b0f2c3c0dce13daf-sles15-image",
            "org.opencontainers.image.created": "2023-01-26T22:15:08.381030307Z",
            "org.opencontainers.image.description": "Image for containers based on SUSE Linux Enterprise Server 15 SP4.",
            "org.opencontainers.image.source": "https://sources.suse.com/SUSE:SLE-15-SP4:Update:CR/sles15-image/1477b070ae019f95b0f2c3c0dce13daf/",
            "org.opencontainers.image.title": "SLE BCI 15 SP4 Base Container Image",
            "org.opencontainers.image.url": "https://www.suse.com/products/server/",
            "org.opencontainers.image.vendor": "SUSE LLC",
            "org.opencontainers.image.version": "15.4.27.14.31",
            "org.opensuse.reference": "registry.suse.com/suse/sle15:15.4.27.14.31"
        },
[...]

podman inspect registry.suse.com/bci/bci-base:15.4 | \
jq '.[0].Labels'

podman inspect registry.suse.com/bci/bci-base:15.4 | \
jq '.[0].Labels["com.suse.sle.base.supportlevel"]'

skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | \
jq '.Labels'
skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | \
jq '.Labels["com.suse.sle.base.supportlevel"]'

To verify a SLE BCI, run Cosign in the container. The command below fetches the signing key from the SUSE server and uses it to verify the latest BCI-Base container image.

> podman run --rm -it gcr.io/projectsigstore/cosign verify \
    --key https://ftp.suse.com/pub/projects/security/keys/container–key.pem \
    registry.suse.com/bci/bci-base:latest | tail -1 | jq

[
  {
    "critical": {
      "identity": {
        "docker-reference": "registry.suse.com/bci/bci-base"
      },
      "image": {
        "docker-manifest-digest": "sha256:52a828600279746ef669cf02a599660cd53faf4b2430a6b211d593c3add047f5"
      },
      "type": "cosign container image signature"
    },
    "optional": {
      "creator": "OBS"
    }
  }
]

The signing key can be used to verify all SLE BCIs, and it also ships with SLE 15 (the /usr/share/container-keys/suse-container-key.pem file).

You can also check BCI container images against rekor, the immutable tamper resistant ledger. For example:

> podman run --rm -it -e COSIGN_EXPERIMENTAL=1 gcr.io/projectsigstore/cosign \
    verify --key https://ftp.suse.com/pub/projects/security/keys/container–key.pem \
    registry.suse.com/bci/bci-base:latest | tail -1 | jq
[
  {
    "critical": {
      "identity": {
        "docker-reference": "registry.suse.com/bci/bci-base"
      },
      "image": {
        "docker-manifest-digest": "sha256:52a828600279746ef669cf02a599660cd53faf4b2430a6b211d593c3add047f5"
      },
      "type": "cosign container image signature"
    },
    "optional": {
      "creator": "OBS"
    }
  }
]

If verification fails, the output of the cosign verify command is similar to the one below.

Error: no matching signatures:
crypto/rsa: verification error
main.go:62: error during command execution: no matching signatures:
crypto/rsa: verification error

If you have a working knowledge of containers, you will not have any difficulties using SLE BCIs. However, there are certain features that set SLE BCIs apart from similar offerings, like images based on Debian or Alpine Linux. And understanding the specifics can help you to get the most out of SLE BCIs in the shortest time possible.

The SLE BCIs are available as OCI-compatible container images directly from registry.suse.com and can be used like any other container image. For example, using one of the general purpose containers:

> podman run --rm -it registry.suse.com/bci/bci-base:15.4 grep '^NAME' /etc/os-release
NAME="{sles}"

Alternatively, you can use a SLE BCI in Dockerfile as follows:

FROM registry.suse.com/bci/bci-base:15.4
RUN zypper -n in python3 && \
    echo "Hello Green World!" > index.html
ENTRYPOINT ["/usr/bin/python3", "-m", "http.server"]
EXPOSE 8000

You can then build container images using the docker build . or buildah bud . commands:

> docker build .
Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM registry.suse.com/bci/bci-base:15.4
 ---> e34487b4c4e1
Step 2/4 : RUN zypper -n in python3 &&     echo "Hello Green World!" > index.html
 ---> Using cache
 ---> 9b527dfa45e8
Step 3/4 : ENTRYPOINT ["/usr/bin/python3", "-m", "http.server"]
 ---> Using cache
 ---> 953080e91e1e
Step 4/4 : EXPOSE 8000
 ---> Using cache
 ---> 48b33ec590a6
Successfully built 48b33ec590a6

> docker run -p 8000:8000 --rm -d 48b33ec590a6
575ad7edf43e11c2c9474055f7f6b7a221078739fc8ce5765b0e34a0c899b46a

> curl localhost:8000
Hello Green World!