Building security into your applications is critical for cloud-native deployments. Securing your containerized applications requires that you:
- Use trusted container content.
- Use an enterprise container registry.
- Control and automate building containers.
- Integrate security into the application pipeline.
1. Use trusted container content
When managing security, what is inside your container matters. For some time now, applications and infrastructures have been composed from readily available components. Many of these are open source packages, such as the Linux OS, Apache Web Server, Red Hat JBoss® Enterprise Application Platform, PostgreSQL, and Node.js. Containerized versions of these packages are also available so you can avoid building your own. However, as with any code you download from an external source, you need to know where the packages originated, who built them, and whether they contain any malicious code. Ask yourself:
- Will the container contents compromise my infrastructure?
- Are there known vulnerabilities in the application layer?
- Are the runtime and OS layers in the container up to date?
- How frequently will the container be updated and how will I know when it is updated?
Red Hat has been packaging and delivering trusted Linux content for years in Red Hat® Enterprise Linux and across our portfolio. Red Hat now delivers that same trusted content packaged in Linux containers. With the introduction of Red Hat Universal Base Images, you can take advantage of the greater reliability, security, and performance of Red Hat container images wherever Open Container Initiative (OCI)-compliant Linux containers run. This means you can build a containerized application on Red Hat Universal Base Image, push it to the container registry of your choice, and share it freely without any subscription required.
Red Hat also provides a large number of certified images and operators for various language runtimes, middleware, databases, and more via the Red Hat Ecosystem Catalog. Red Hat certified containers and operators run anywhere Red Hat Enterprise Linux runs, from bare metal to VMs to cloud, and are supported by Red Hat and our partners.
Red Hat continuously monitors the health of the images we deliver. The Container Health Index grades the security risk of each container image, detailing how container images should be curated, consumed, and evaluated to meet the needs of production systems. Containers are graded based in part on the age and impact of unapplied security errata to all components of a container, providing an aggregate rating of container safety that can be understood by security experts and nonexperts alike.
When Red Hat releases security updates—such as fixes to run CVE-2019-5736, MDS CVE-2019-11091, or VHOST-NET CVE-2019-14835—we also rebuild our container images and push them to the public registry. Red Hat security advisories alert you to any newly discovered issues in certified container images and direct you to the updated image so that you can, in turn, update any applications that use the image.
There may be times when you need content that Red Hat does not provide. We recommend using container scanning tools that use continuously updated vulnerability databases to be sure you always have the latest information on known vulnerabilities when using container images from other sources.
Because the list of known vulnerabilities is constantly evolving, you need to check the contents of your container images when you first download them and continue to track vulnerability status over time for all your approved and deployed images, just as Red Hat does for Red Hat container images.
2. Use an enterprise container registry for more secure access to container images
Your teams are building containers that layer content on top of the public container images you download. You need to manage access to, and promotion of, the downloaded container images and the internally built images the same way you manage other types of binaries. A number of private container registries support storage of container images—we recommend selecting a private registry that helps you automate policies for the use of stored container images.
Red Hat OpenShift includes a private registry that provides basic functionality to manage your container images. Red Hat Quay is available as a standalone enterprise registry, offering many additional enterprise features including team-based access control, geographic replication, and build image triggers.
The Clair project is an open source engine that powers the Red Hat Advanced Cluster Security for Kubernetes scanner and the Red Hat Quay vulnerability scanner. Scanning at the registry level is crucial in hardening your pipelines and catching vulnerabilities as early as possible. Later in the life cycle, you will want a solution that uses similar vulnerability scanning in your build, deploy, and runtime stages to discover and address issues as soon as possible.
Red Hat OpenShift also supports integration with other private registries you may already be using, such as JFrog’s Artifactory and Sonatype Nexus.
3. Control and automate building container images
Managing this build process is key to better securing the software stack. Adhering to a “build once, deploy everywhere” philosophy means that the product of the build process is exactly what is deployed in production. It is also important to maintain the immutability of your containers. In other words, do not patch running containers—rebuild and redeploy them instead.
Red Hat OpenShift provides a number of capabilities for automating builds based on external events, as a way to improve the security of your custom images.
- Red Hat Quay triggers provide a mechanism for spawning a repository build of a Dockerfile from an external event such as a GitHub push, BitBucket push, GitLab push, or webhook.
- Source-to-image (S2I) is an open source framework for combining source code and base images (Figure 3). S2I allows your development and operations teams to collaborate on a reproducible build environment. When a developer commits code with git, under S2I, Red Hat OpenShift can:
- Trigger automatic assembly of a new image from available artifacts—including the S2I base image—and the newly committed code (via webhooks on the code repository or some other automated CI process).
- Automatically deploy the newly built image for testing.
- Promote the tested image to production status and automatically deploy the new image through the continuous integration/continuous delivery (CI/CD) process.