Pros and cons of public vs internal container image repositories
Docker registry is a key component in IT environments that use containers. Small businesses and individuals can rely on publicly available registry services such as Docker Hub. However, when it comes to enterprise environments the amount of people using these registries as well as the amount of images being used begin to scale up, in which case we will start to see various issues with publicly available image registries like Docker Hub.
This article provides an overview of these registries and the pros and cons of public and private container images repositories.
Purpose of image repositories
The primary purpose of Docker registries is to store and distribute docker images. Devs/Ops users push images into these registries and pull them when they need to spin containers from these stored images. Each of these images can have multiple versions identified by their tags. The registry is considered a trusted source to pull images from. When containers are run from the images, it means the same code is running everywhere giving us a benefit of easily updating to a new version or rolling back to a previous version at scale.
Pulling images from Docker hub looks as follows:
|$ docker pull api-project/api:v1|
Pulling images from a private registry looks as follows:
|$ docker pull harbor-registry:8085/library/api:v1|
Pulling an image from a private registry requires the domain name, port along with the image name.
Privacy and financial considerations
Public registry services such as Docker Hub are easy to use, which is why they are so popular among newcomers. Since anyone can push an image, the free public repositories come with their own set of limitations. For example, anonymous and free Docker Hub users are limited to 100 and 200 container image pull requests per six hours. We may need to scale up the number of pushes and pulls in an enterprise environment.
In such cases, private repositories are a better option. In environments, where privacy is a concern private registries are a better fit as anyone can push and pull images in public registries. Several open source and commercial private container image registries are available for our consideration with various features catered to enterprise environments. Harbor is one such popular free and open source container registry solution, which can be configured in a local environment. Similarly, cloud providers such as AWS and Google Cloud provide their own private registries as paid services.
Private image repositories let us define specific policies and prevent deployment of images that are not inline with the set policies. For instance, we can set a policy stating that an image with high risk vulnerabilities cannot be deployed. A library with a specific license cannot be used in our environment as it can lead to legal complications.
Public registry services such as come with their own downsides. Anyone with a docker hub account can upload a malicious image and it is the users’ responsibility to decide whether or not to install these images. On the other hand, private registries provide the flexibility to control who can push images and pull images. In addition to it, Role-based access control can be enforced to have granular control over users by specifying which department or environment a specific user has access to.
Private image repositories can enforce image signing so only signed images are pushed and used in a given environment. In our earlier example with harbor, notary is a tool that is supported for image signing.
One of the key features of private repositories is vulnerability scanning of docker images. Most private registries support policy driven vulnerability scanning. Automated vulnerability scans can be performed in various stages. For instance, we can enforce a vulnerability scan immediately after a new image is uploaded to the private registry. Similarly, we can trigger a scan whenever there is an update to the image or a whenever a new CVE is released.
In large enterprises with many teams using an image registry, it is unlikely that a single central registry can server the needs. At some point, it will lead to performance disruptions and it is a good idea to choose a private registry that supports replication support and load balancing for high availability.
The idea is to be able to run multiple registry instances and load balance them for high availability. It is also a good idea to segregate various environments (Dev, UAT, Staging and Production) by maintaining registries separately.
Private registries definitely bring far more advantages in an enterprise environment than public registries. Majority of the private image repositories provide support for different features such as replication providing high availability, Role Based Access Control providing control on users, support for SSL/TLS, support for external storage and support for vulnerability scanning.
One should look for these basic features at a minimum when considering private image registry solutions.