Container images in the Red Hat Ecosystem Catalog are scanned for security vulnerabilities, with new versions created to align with RHEL releases and to include critical security patches. Red Hat systems have been enhanced specifically to provide secure environments for developing and running containers. The following topics and questions address how the Red Hat Ecosystem Catalog handles container security and how Red Hat’s container ecosystem is built for security.
Images are produced by Red Hat or by certified Independent Software Vendor (ISV) partners. When you display an image page, the company or person responsible for that image is identified in the “By” line, while the product it is associated with is cited on the “In Product” line.
Red Hat container security begins by building images based on tested and secured RHEL RPM packages. But, Red Hat’s approach to securing containers goes beyond securing container contents. To run containers, Red Hat secures the operating systems on which the containers run (RHEL and RHEL Atomic) and the tools for deploying, managing, and updating containers (OpenShift, Kubernetes, and other features). See Keeping Up with Docker Security and Docker Security in the Future, to learn about how Red Hat secures containers from container security expert Dan Walsh.
In Red Hat Enterprise Linux systems, namespaces isolate features from host systems such as IPC, file systems, network interfaces, process tables, user accounts, and hostname. To manage and restrict running containers, Red Hat leverages operating system features including cgroups, SELinux, systemd, and system call filtering (seccomp). To scan images for security vulnerabilities yourself, you can use the atomic scan command. Introducing atomic scan and the Atomic CLI Reference are good places to start. You can even create atomic scan plugins.
Red Hat defines some container images based not on what they provide, but on how they run. For example:
Super Privileged Container (SPC) images are designed to run with extra privileges (such as access to the host filesystem, devices, user account, IPC, and so on) to a container’s host system. With that privilege, the container can manage or otherwise access the host system directly.
System Container images are those that are configured to run without the docker service, allowing them to either start before the docker service or run on systems that don’t include the docker service. System containers typically use systemd unit files and the runc command to start, stop, and manage those containers.
Red Hat uses a “health index” for security risk with containers that Red Hat provides through the Red Hat Container Catalog. These containers consume software provided by Red Hat and our errata process, so old, stale containers are insecure whereas new, fresh containers are more secure. To illustrate the age of containers, we use a grading system.
The Container Health Index is a measure of the oldest and most severe security errata available for an image. “A” is more up-to-date than “F”. Further details here.
Advisories are available from Red Hat Errata Page for each official Red Hat container image. Those advisories include a list of updated packages in each image and errata associated with those packages. You can view errata for updates to container images, such as the Atomic Tools Container Image and the Atomic etcd Container Image. For general information on Red Hat errata, see Red Hat Enterprise Linux Life Cycle.
To date, errata created by Red Hat are applied on the RPM level. Red Hat is in the process of developing a strategy for applying errata to container images, as well as other image types, such as its ISO installer images and a variety of RHEL-based cloud images.
The Red Hat Container Image Updates page describes the current approach Red Hat takes to updating the container images in the Red Hat Ecosystem Catalog, as well as other container registries under its control.