Red Hat is moving toward putting the open source Quay container registry at the center of its DevSecOps strategy for securing containers.
The latest 3.2 version of Quay adds support for Container Security Operator, which integrates Quay’s image vulnerability scanning capabilities with Kubernetes. Dirk Herrmann, senior principal product manager for Red Hat, says that capability will make it possible to leverage the open source Clair vulnerability scanning tool developed by CoreOS. Red Hat acquired CoreOS in 2018.
Going forward, Red Hat also will be working with other providers of container security platform to make Quay the hub around which best DevSecOps processes are applied to containers, Herrmann says. While most organizations that have adopted containers employ a registry, Herrmann notes very few are employing tools to scan containers for vulnerabilities before they are deployed in production environments. By integrating Quay with Clair and other similar tools, Red Hat is looking to foster the adoption of DevSecOps among organizations that have adopted Kubernetes distributions such as the Red Hat OpenShift platform, he says.
The latest release of Quay also makes it easier to extend DevSecOps processes across multiple instances of the container registry. Version 3.2 of Quay includes a mirroring capability that makes it possible to replicate instances of Quay container registries across multiple locations. In fact, Herrmann says one of the things that differentiates Quay most from other container registries is its ability to scale.
Other capabilities added to Quay include support for OpenShift Container Storage 4, which is enabled via NooBaa Operator for data management, based on the S3 application programming interface (API) for cloud storage developed by Amazon Web Services (AWS).
Finally, version 3.2 makes Quay Setup Operator software for deploying Quay on Kubernetes clusters generally available.
While Red Hat is focused on tightly integrating Quay and OpenShift, Herrmann notes Quay, as an open source project, also can be used with other distributions of Kubernetes. The goal is to advance DevSecOps by making it easier to make security an extension of the container registry and its associated Kubernetes distribution, he says, noting Red Hat has been working with the National Institute of Standards and Technology (NIST) to help define best DevSecOps practices.
In most cases, organizations that adopt containers will embrace DevSecOps simply because existing approaches to applying cybersecurity policies using network firewalls can’t be applied to cloud-native applications based on containers. The first step to securing any cloud-native application is to make sure the containers that comprise it are secure. In many cases, the developers who pull containers from registries are now being held accountable for the integrity of code packaged in those containers.
It may be a while before best DevSecOps practices are pervasive across the enterprise. However, as more cloud-native applications are built and deployed it’s only a matter of time before the thousands of containers strewn across an extended enterprise finally force the issue.