WavebreakmediaMicro - Fotolia
The rise of the cloud has also brought about an increase in the use of containers, as well as the use of container image repositories. But do repositories for container images carry the same risk as code repositories like GitHub? For many of the same reasons, the answer is likely yes.
Container image repositories are widely considered an integral element of development and deployment practices that make use of containers and PaaS environments. Many development, operations and DevOps teams are readily making use of containers, and most will pull a variety of container images from numerous sources to enable more rapid, flexible application development and enablement practices.
That said, not all container image repositories are created equal. Most of the major cloud providers have internal registries that can be used as part of the cloud services environment, such as Amazon's Elastic Container Registry, Microsoft's Azure Container Registry and Google's Container Registry. If an organization creates and configures its own private registry for images within their cloud development and deployment pipelines, they can easily be restricted and monitored in accordance with existing security policies and standards.
However, many teams pull container images from more open, community-focused registries, like Docker Hub, or from third-party registries, such as Quay and Sonatype Nexus. These registries host container images from organizations and individuals in the community, and not all of them are validated or checked for security vulnerabilities.
To add even more complexity, most well-known software vendors like IBM and Oracle also host official repositories, and there are also many open community repositories that are wholly unmonitored.
Choosing container image repositories
For a number of reasons, security teams need to better understand the container images their teams use and also look at a number of options for where to host these images. In most application lifecycles, developers and QA testers will need to test and make use of many images for different functional requirements. Ideally, security teams should discuss the various types of registries with all the teams that plan to use them. There are definitely pros and cons to every option.
Registries within the major cloud providers' tools -- like Amazon Enterprise Container Service or Azure Container Registry -- can use policies configured for access control, native logging enabled for monitoring, and integration with the provider's APIs, and possibly other features and services such as encryption and identity management.
These registries may be somewhat limited outside of the associated cloud environments, however, and may make open or multi-cloud deployments more difficult. Some registries, such as the one operated by GitLab, can be run internally or in a hosted environment and offer benefits for teams using the GitLab software development platform, including access controls, monitoring and integration with project lifecycles.
It's important to monitor container images and perform ongoing checks to track which repositories and registries are in use. In recent years, some registries have begun scanning for vulnerabilities, as well as cryptographic signing for official container images hosted by the image hosts.
Docker Security Scanning was released in 2016 for all the official images hosted in Docker Hub, and it can be acquired as an add-on for private Docker repositories. Docker Content Trust can enable digital signature verification for any official images hosted in third-party registries. Docker Trusted Registry is a fully self-managed registry you can run on premises that includes access controls and integration with Active Directory, scanning, image signing and logging.
Security teams should discuss the options for container image repositories with all the teams using containers and determine which provide the best balance of security and usability. There are many safer options available today beyond the original community repositories, and defining security policies and controls for any images and repositories is a step in the right direction.