Chapter 13. Working with containers

Containers include all the necessary components like libraries, frameworks, and other additional dependencies that are isolated and self-sufficient within their own executable. A Red Hat container certification ensures supportability of both the operating system and the application layers. It provides enhanced security by vulnerability scanning and health grading of the Red Hat components, and lifecycle commitment whenever the Red Hat or partner components are updated.

However, containers running in privileged mode, or privileged containers, stretch their boundaries and interact with their host to run commands or access the host’s resources. For example, a container that reads or writes to a filesystem mounted on the host must run in privileged mode.

Privileged containers might create a security risk. A compromised privileged container might also compromise its host and the integrity of the environment as a whole.

Moreover, privileged containers are susceptible to incompatibilities with the host as operating system interfaces such as commands, libraries, ABI, and APIs might change or deprecate over time. This can put privileged containers at risk of interacting with the host in an unsupported way.

Containers must run in unprivileged mode unless approved by Red Hat during the certification process as described in the policy guide.

You must ensure that your containers can run on any supported hosts in the customer’s environment. Red Hat encourages you to adopt a continuous integration model that lets you test your containers with public betas or earlier versions of Red Hat products to maximize compatibility.

The following diagram gives an overview of container certification workflow:

Figure 13.1. Container certification workflow

View larger image

Task Summary

The certification workflow includes the following three primary stages-