Securing Container Images and Builds With Red Hat OpenShift And Quay

Previously in this series, we've discussed the different types of container threats and securing container infrastructure. This last article looks at container deployment best practices, including the sources of container images, image vulnerability scanning and DevSecOps pipelines to incorporate security gating.

Using trusted images

The first step towards securing container deployment is to use images from trusted sources. Public container image repositories such as Docker Hub facilitate ease of testing a container based application, however, this does not guarantee that the images are free of malware or backdoors. As mentioned earlier in the series, the use of publicly available untrusted images has caused already created serious security breaches.

Trusted image registries such as registry.redhat.io address these types of challenges. Images available in the Red Hat container image registry are signed images that have undergone hundreds of vulnerability scans and testing. Red Hat has a large database of CVEs to compare for known vulnerabilities and the images have a scoring mechanism to indicate which versions (tags) have the most updated versions.

Red Hat uses the Container Health Index to identify 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 container images are much more likely to contain security risks, while new, fresh containers are less likely.

In addition, the images are signed and confirmed to be run as an unprivileged user. Red Hat Rebuilds images when vulnerabilities are identified and security fixes are released.

Once trusted container image registries are identified, the following measures should be implemented:

validation of image signatures before executing image to ensure they are from trusted sources and have not been tampered with; and
ongoing monitoring and maintenance of these repositories to ensure images within them are maintained and updated as vulnerabilities.

Image scanning

It is not always possible to use the signed, secured and certified images from a trusted source. Some use cases require enterprises to use third party images provided by the vendors. A good example is how telecom services providers have to use virtual network functions (VNFs) provided by the VNF vendors in network function virtualization (VNF) application deployments. Also, once the developers add layers of code on top certified images, its trusted nature changes.

It is critical to run image vulnerability scans before these images are deployed to production. An example of image scanning incorporated with an image registry is Red Hat Quay. Red Hat Quay has a built-in vulnerability scanning engine, Clair. The following shows a sample scanning of an image inside Quay.

Quay integrates with Clair to continually scan the container images for vulnerabilities. It provides complete visibility into known CVEs and how to fix them.

CI/CD DevSecOps pipelines

DevOps processes involved with deploying applications to containers are a critical step in the overall security lifecycle of container-based applications. CI/CD pipelines can be the first step in defense finding vulnerabilities in the application code and container images in an automated way. CI/CD pipelines can also be used to execute compliance checks against containers before being deployed into production.

The following shows typical CI/CD pipelines with gating introduced to evaluate code quality, vulnerability scanning and compliance.

Code quality and best practices with Sonarqube: Secure coding practices can be applied by using static code analysis tools against common weakness enumeration (CWE), open web security project (AWSP) top 10 and SANS top 25 dangerous errors list.
Image vulnerability scanning with Red Hat Quay and Clair: Once the image is built with application code, uploading to Red Hat Quay and triggering a Clay scan can incorporate the vulnerability scanning into the CICD pipeline.
Executing Open SCAP scanning for US government security compliance: Security Content Automation Protocol (SCAP) is a U.S. standard maintained by the National Institute of Standards and Technology (NIST).The OpenSCAP project is a collection of open-source tools for implementing and enforcing this standard. Government agencies and their contractors are often required by law to implement cybersecurity programs and policies. Under the U.S. Federal Information Security Management (FISMA) Act,government agencies are required to implement SCAP protection, and similar laws apply in many other countries as well. OpenSCAP scans can be triggered inside CICD pipelines as it provides capabilities to scan images as well as running containers.

How we can help

Teams from WWT's security practice can sit with you and evaluate the existing container security processes, infrastructure, applications and requirements. Whether it is a greenfield or brownfield deployment, we can work with you to architect container security solutions to meet your application and compliance security requirements.

Get started today with one of our various hands-on labs: