Red Hat distributes container images by using two registries: registry.access.redhat.com (where no authentication is required), and registry.redhat.io (where authentication is required). The Red Hat Ecosystem Catalog, https://catalog.redhat.com/, provides centralized searching utility for both registries. You can search the Red Hat Ecosystem Catalog for technical details about container images. The catalog hosts a large set of container images, including from major open source projects, such as Apache, MySQL, and Jenkins.

Because the Red Hat Ecosystem Catalog is also searched for software products other than container images, you must navigate to https://catalog.redhat.com/software/containers/explore to specifically search for container images.

Figure 3.4: Red Hat Ecosystem Catalog

The details page of a container image gives relevant information, such as technical data, the installed packages within the image, or a security scan. You can navigate through these options by using the tabs on the website. You can also change the image version by selecting a specific tag.

Figure 3.5: The Red Hat Universal Base Image 9

The Red Hat internal security team vets all images in the container catalog. Red Hat rebuilds all components to avoid known security vulnerabilities.

Red Hat container images provide the following benefits:

Although the Red Hat Registry stores only images from Red Hat and certified providers, you can store your own images with Quay.io, another public image registry that Red Hat sponsors. Although storing public images in Quay is free of charge, some options are available only for paying customers. Quay also offers an on-premise version of the product, which you can use to set up an image registry in your own servers.

Quay.io introduces features such as server-side image building, fine-grained access controls, and automatic scanning of images for known vulnerabilities.

Quay.io offers live images that creators regularly update. Quay.io users can create their namespaces, with fine-grained access control, and publish their created images to that namespace. Container Catalog users rarely or never push new images, but consume trusted images from the Red Hat team.

Figure 3.6: The Quay.io welcome page

Image creators or maintainers might want to make their images publicly available. However, other image creators might prefer to keep their images private, for the following reasons:

In some cases, private images are preferred. Private registries give image creators control over image placement, distribution, and usage. Private images are more secure than images in public registries.

Other public registries, such as Docker Hub and Amazon ECR, are also available for storing, sharing, and consuming container images. These registries can include official images that the registry owners or the registry community users create and maintain. For example, Docker Hub hosts a Docker Official Image of a WordPress container image. Although the docker.io/library/wordpress container image is a Docker Official Image, the container image is not supported by WordPress, Docker, or Red Hat. Instead, the Docker Community, a global group of Docker Hub users, supports and maintains the container image. Support for this container image depends on the availability and skills of the Docker Community users.

Consuming container images from public registries brings risks. For example, a container image might include malicious code or vulnerabilities, which can compromise the host system that executes the container image. A host system can also be compromised by public container images, because the images are often configured with the privileged root user. Additionally, the software in a container image might not be correctly licensed, or might violate licensing terms.

Before you use a container image from a public registry, review and verify the container image. Also ensure that you have the correct permissions to use the software in the container image.

Skopeo is another tool to inspect and manage remote container images. With Skopeo, you can copy and sync container images from different container registries and repositories. You can also copy an image from a remote repository and save it to a local disk. If you have the appropriate repository permissions, then you can also delete an image from container registry. You also can use Skopeo to inspect the configuration and contents of a container image, and to list the available tags for a container image. Unlike other container image tools, Skopeo can execute without a privileged account, such as root. Skopeo does not require a running daemon to execute various operations.

Skopeo is executed with the skopeo command-line utility, which you can install with various package managers, such as DNF, Brew, and APT. The skopeo utility might already be installed on some Linux-based distributions. You can install the skopeo utility on Fedora, CentOS Stream 8 and later, and Red Hat Enterprise Linux 8 and later systems by using the DNF package manager.

[user@host ~]$ sudo dnf -y install skopeo

The skopeo utility is currently not available as a packaged binary for Windows-based systems. However, the skopeo utility is available as a container image from the quay.io/skopeo/stable container repository. For more information about the Skopeo container image, refer to the skopeoimage overview guide in the Skopeo repository (https://github.com/containers/skopeo/blob/main/contrib/skopeoimage/README.md).

You can also build skopeo from source code in a container, or build it locally without using a container. Refer to the installation guide in the Skopeo repository (https://github.com/containers/skopeo/blob/main/install.md#container-images) for more information about installing or building Skopeo from source code.

The skopeo utility provides commands to help you to manage and inspect container images and container image registries. For container registries that require authentication, you must first log in to the registry before you can execute additional skopeo commands.

[user@host ~]$ skopeo login quay.io

After you log in to a container registry (if required), you can execute additional skopeo commands against container images in a repository. When you execute a skopeo command, you must specify the transport and the repository name. A transport is the mechanism to transfer or move container images between locations. Two common transports are docker and dir. The docker transport is used for container registries, and the dir transport is used for local directories.

The oc image command and other tools default to the docker transport, and so you do not need to specify the transport when executing commands. However, the skopeo utility does not define a default transport; you must specify the transport with the container image name. Most skopeo commands use the skopeo command [command options] transport://IMAGE-NAME format. For example, the following skopeo list-tags command lists all available tags in a registry.access.redhat.com/ubi9/httpd-24 container repository by using the docker transport:

[user@host ~]$ skopeo list-tags docker://registry.access.redhat.com/ubi9/httpd-24
{
    "Repository": "registry.access.redhat.com/ubi9/httpd-24",
    "Tags": [
        "1-229",
        "1-217.1666632462",
        "1-201",
        "1-194.1655192191-source",
        "1-229-source",
        "1-194-source",
        "1-201-source",
        "1-217.1664813224",
        "1-217.1664813224-source",
        "1-210-source",
        "1-233.1669634588",
        "1",
        "1-217.1666632462-source",
        "1-233",
        "1-194.1655192191",
        "1-217.1665076049-source",
        "1-217",
        "1-233.1669634588-source",
        "1-210",
        "1-217.1665076049",
        "1-217-source",
        "1-233-source",
        "1-194",
        "latest"
    ]
}

The skopeo utility includes other useful commands for container image management.

Some registries require users to authenticate. For example, Red Hat containers that are based on RHEL typically require authenticated access:

[user@host ~]$ skopeo inspect docker://registry.redhat.io/rhel8/httpd-24
FATA[0000] Error parsing image name "docker://registry.redhat.io/rhel8/httpd-24": unable to retrieve auth token: invalid username/password: unauthorized: Please login to the Red Hat Registry using your Customer Portal credentials. Further instructions can be found here: https://access.redhat.com/RegistryAuthentication

You might choose a different image that does not require authentication, such as the UBI 8 image:

[user@host ~]$ skopeo inspect docker://registry.access.redhat.com/ubi8:latest
{
    "Name": "registry.access.redhat.com/ubi8",
    "Digest": "sha256:70fc...1173",
    "RepoTags": [
        "8.7-1054-source",
        "8.6-990-source",
        "8.6-754",
        "8.4-203.1622660121-source",
...output omitted....

Alternatively, you must execute the skopeo login command for the registry before you can access the RHEL 8 image.

[user@host ~]$ skopeo login registry.redhat.io
Username: YOUR_USER
Password: YOUR_PASSWORD
Login Succeeded!
[user@host ~]$ skopeo list-tags docker://registry.redhat.io/rhel8/httpd-24
{
    "Repository": "registry.redhat.io/rhel8/httpd-24",
    "Tags": [
        "1-166.1645816922",
        "1-209",
        "1-160-source",
        "1-112",
...output omitted...

Skopeo stores the credentials in the ${XDG_RUNTIME_DIR}/containers/auth.json file, where the ${XDG_RUNTIME_DIR} refers to a directory that is specific to the current user. The credentials are encoded in the base64 format:

[user@host ~]$ cat ${XDG_RUNTIME_DIR}/containers/auth.json
{
	"auths": {
		"registry.redhat.io": {
			"auth": "dXNlcjpodW50ZXIy"
		}
	}
}
[user@host ~]$ echo -n dXNlcjpodW50ZXIy | base64 -d
user:hunter2

The OpenShift command-line interface provides the oc image command. You can use this command to inspect, configure, and retrieve information about container images.

The oc image info command inspects and retrieves information about a container image. You can use the oc image info command to identify the ID/hash SHA and to list the image layers of a container image. You can also review container image metadata, such as environment variables, network ports, and commands. If a container image repository provides a container image in multiple architectures, such as amd64 or arm64, then you must include the --filter-by-os tag. For example, you can execute the following command to retrieve information about the registry.access.redhat.com/ubi9/httpd-24:1-233 container image that is based on the amd64 architecture:

[user@host ~]$ oc image info registry.access.redhat.com/ubi9/httpd-24:1-233 \
--filter-by-os amd64
Name:          registry.access.redhat.com/ubi9/httpd-24:1-233
Digest:        sha256:4186...985b
...output omitted...
Image Size:    130.8MB in 3 layers
Layers:        79.12MB sha256:d74e...1cad
               17.32MB sha256:dac0...a283
               34.39MB sha256:47d8...5550
OS:            linux
Arch:          amd64
Entrypoint:    container-entrypoint
Command:       /usr/bin/run-httpd
Working Dir:   /opt/app-root/src
User:          1001
Exposes Ports: 8080/tcp, 8443/tcp
Environment:   container=oci
...output omitted...
               HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/
               HTTPD_APP_ROOT=/opt/app-root
               HTTPD_CONFIGURATION_PATH=/opt/app-root/etc/httpd.d
               HTTPD_MAIN_CONF_PATH=/etc/httpd/conf
               HTTPD_MAIN_CONF_MODULES_D_PATH=/etc/httpd/conf.modules.d
               HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d
               HTTPD_TLS_CERT_PATH=/etc/httpd/tls
               HTTPD_VAR_RUN=/var/run/httpd
               HTTPD_DATA_PATH=/var/www
               HTTPD_DATA_ORIG_PATH=/var/www
               HTTPD_LOG_PATH=/var/log/httpd
...output omitted...

The oc image command provides more options to manage container images.