Registry Risks

Gaining Visibility into NIST SP 800-190, Part Four

In my previous post (Part Three: Image Risks) I described how native AWS tools and third-party solutions can address image risks identified in section 3.1 of NIST SP 800-190 Application Container Security Guide. This post will dive into section 3.2 (Registry Risks) and 4.2 (Registry Countermeasures).

3.2.1 Insecure connections to registries: The image registry is the location of image builds used in container deployments. Similar to communication with other sensitive data, connections to image registries should be maintained in a secure manner. These registries can contain sensitive information and should be treated as connecting to sensitive data. NIST provides the following guidance on risks and countermeasures:

AWS

As described in the preceding blog post on Kubernetes Test Lab, these registries are located within each project of the GitLab server, which is an EC2 instance. The use of HTTPS access to project registries was defined on the GitLab server. However, security group inbound/outbound access restrictions to include only secure connections could be placed on the EC2 instance of the GitLab server as a way of mitigating some risk.

In terms of what AWS offers for connection logging to our registry, VPC flow logs provide some connection visibility but it isn’t perfect and takes some work to find. Below is the output of a CloudWatch search from VPC flow that was filtered based on the GitLab server and the port 4567, used for the registry. Unfortunately, it is difficult to discern if the connection was encrypted. The number 6 in the protocol only tells us that it was a TCP connection.

Prisma Cloud/Third-Party Tools

Prisma Cloud (formerly Twistlock) doesn’t have the ability to enforce registries to enable HTTPS communication. However, policies can be created within the product to prevent the pull of images from unknown registries.

3.2.2 Stale images in registries: Stale images are those that are old and potentially running out-of-date software. The hosting of stale images does not present immediate risk unless that image is used by a container. NIST provides the following guidance on risks and countermeasures:

AWS

AWS did not have visibility into the image registries for this project. Amazon Elastic Container Registry (ECR) was not used for this project.

Prisma Cloud

Prisma Cloud doesn’t report on stale images but would have the ability to prune images using the API integration.

Other

Stale images can be found using the docker images command:

Use filters to prune images within Docker. As an example, the image below shows how to delete all images before 10-13-2019, about 30 days from when this image was taken.

3.2.3 Insufficient authentication and authorization restrictions: Images within a registry may contain sensitive data. The lack of authentication or authorization restrictions to private registries could pose multiple risks to an organization. NIST provides the following guidance on risks and countermeasures:

AWS

Our registries were located within each project on the GitLab server. Access to the registries are defined on the GitLab server, and authentication lockdown can be performed there. Above and beyond that, security group inbound/outbound access restrictions could be placed on the EC2 instance of the GitLab server as a way of mitigating some risk and only allowing needed groups.

Prisma Cloud

Prisma Cloud can integrate with an organization’s directory service, like Active Directory, to define policy around who can push to and pull from defined registries. The example policy below prevents all members in the PRS group from pushing images to the registry.

Hopefully this analysis proves helpful to security practitioners and others that are looking for methods to obtain visibility into registry risks. Stay tuned for the next blog post in this series, which will cover orchestrator risks and countermeasures.