Container Service: Deploying an Application - Container Image Suggestions

Overview

As outlined on the Container Service website, updating applications and application images is a customer responsibility. This starts with selecting an appropriate base image, regularly checking for image updates, rebuilding your application to utilize updated images, and regularly moving your base image forward to keep it current. Although no one suggestion will address all situations, some guidelines apply to most.

Choosing Base Images

Image security starts with the base images that you use to build your containerized application. Here are some suggestions for choosing base images:

• Use Base Images from the openshift namespace: The Container Service provides a set of images within the openshift namespace. These images are sourced from Docker Hub, in the case of debian based images, and from the Red Hat image registry. All images are updated daily and scanned for vulnerabilities.
• Red Hat Images: Red Hat images are generally very secure, are updated regularly by Red Hat, and available to all Container Service customers. A good starting point is the ubi or universal base image. ubi is a small and secure base image from which you can base your application. Examples of the use of Red Hat images, including ubi, can be found here. These images can be found in the openshift namespace, and have a -rhel suffix appended to the tag name. For example, the Red Hat image tag for Python 3.6 is named python:3.6-rhel.
• Use Trusted Images: When beginning your project, it is important to choose a base image that is updated regularly, and comes from a trusted source. Many users start with images from Docker Hub. If you are going to do so, only use those images that are listed as official. Official images are are generally kept current. It should be noted that they are maintained by Docker staff, not by the software (e.g. Drupal, Python, Debian) community itself. As such, the images may lag behind the security releases of the software community. However, official images do have a dedicated maintainer, which may not be the case for non-official images.
• Using -slim tag variants when available: Some images from seemingly trusted sources have significant vulnerabilities. The python images from Docker Hub are frequently used, but often contain a significant number of vulnerabilities. If you are going to use these images, choosing the -slim--e.g. python:3.8-slim instead of python:3.8--variant of a tag is always smaller and most often will have fewer security vulnerabilities. The smaller size will frequently leading to shorter build times as well.

Here are instructions for updating the base image used by your application build process.

Keeping Application Images Current

Here are some suggestions for keeping your application images current:

• Update Stale Base Layers: Customers can import base images into their project when their desired base image is not available within the openshift namespace. In cases such as these, ensure that image is updated regularly. OpenShift documentation for setting up an update schedule for your images is available here. Look for the text about setting an importPolicy of scheduled: true This setting tells OpenShift to check daily and import and updates to the base image.
• Rebuild Application Regularly: Your application will need to be rebuilt and redeployed in order to utilize updated base layers. A good practice is to reference base images by tag name instead of hash id in your build configuration. This way, rebuilding the application will pick up any base image updates. OpenShift documentation for configuring the base image within a build configuration can be found here.
• Periodically Bypass Build Caching: OpenShift aggressively caches image layers in order to speed up the build process. Commands are run at build time when the cached equivalent of that command is being utilized. To ensure that commands like apt-get upgrade are run at build-time, place a dummy command immediately after the FROM line in your Dockerfile, to invalidate the cache for the rest of the layers without impacting application functionality. One example of this is an environment variable that contains the date of your current commit: ENV build_date 02sep2020. Adjusting the build date of the variable will invalidate the cache of remaining layers.
• Remove Unused Tags: In some cases, the security reports will reference image tags that are old and no longer in use by your application. If your vulnerabilities are related to tags that are not in use, they can be deleted from your project. The OpenShift documentation for deleting tags is available here.

Questions?

Contact the ITS Container Service be sending email to: [email protected], or contact 4-HELP.