Private vs. Public Container Registries: Pros, Cons and Best Practices
VMware sponsored this post.
Container image registries can offer significant advantages for developers but with one caveat attached: not all registries are created equally.
Public registry services are basic, simple to use and can work well for individuals and smaller teams. But once teams begin to scale up, they run into numerous issues with public registries. A private container registry with scanning capabilities and role-based access control offers more security, governance and efficient management. The open source Harbor project from the Cloud Native Computing Foundation (CNCF) is a good option, though there are numerous open source, private registries available.
Let’s get into more detail about why container image registries are a good tool for any developer, some of the most important features of good registries, and why private registries are a must for organizations running applications at scale.
Why Use a Container Image Registry?
In the pre-container world, developers directed running code to physical or virtual machines, creating install packages in unique versions for operating system and machine variants, often with co-dependencies and interactions with other software installed in the machines. Containers changed this, allowing developers to compose small, portable units (container images) that can be bundled with all necessary dependencies, run anywhere and be deployed using automation.
In the old model when a problem arose, developers were asked to analyze and patch running systems one at a time. In the new model, developers continuously produce new containerized versions to fix issues and add features. These flow into a pipeline and reside in specialized cataloged storage (container image registries) as they await processing steps, such as quality assurance testing, followed by deployment in production.
Here is where the registry comes into play: during the entire process, the registry remains a source of truth for the images you want to run. The first advantage is you have the same piece of code running everywhere. The second advantage is that piece of code is guarded in a repository controlled by IT so you can easily revert to a clean environment. The result is the end of “config drift” in production.
Instead of labor-intensive and error-prone manual patching, automated systems now monitor the running systems continuously, asking the question, “Is this running the desired (patched) version?” If not, the system automatically triggers an update.
Just Like a Warehouse
Not unlike a physical warehouse and a classic distribution supply chain, the points of continuous flow and container image storage present both security challenges and opportunities. Consider these problematic scenarios in a retail distribution supply chain:
- How do you detect and prevent tampering with products that end up on store shelves?
- How do you protect against counterfeits?
- When a tainted ingredient is reported: How do you quarantine bad inventory? How do you quantify exposure and identify at-risk customers?
- How do you restrict access to inventory to only those that are authorized?
These “supply chain” issues have analogies in container-based software — and some image registries have built-in features to deal with them.
Financial Stakes and Privacy Considerations
Public registry services are basic and simple to use, which helps to explain why they are so popular. But as they are shared among developers, and host images run by the 1,000s at multiple locations, vanilla “free” public registries can fall short.
Many popular software components are open source and readily found on the internet, often as pre-packaged container images. Allow these to go straight from the internet into production go wrong.
A variety of open source and commercially supported private container image registries are available. Some provide a smattering of enterprise features, such as container image security scanning. Other private registries are fully featured, with features such as strict governance and audit logging.
How a Registry with Scanning Capabilities Can Help
Containers are composed in such a way that it is possible to analyze the content and determine all the parts that are included within it. This means when a security vulnerability is newly discovered in one small package included in a container image, you can tell whether you are exposed to vulnerabilities.
Industry and government agencies sponsor frequently updated databases of known “common” vulnerabilities and exposures, or CVE’s. Some container image registries can utilize these to perform static analysis of inventoried images. Scans can be triggered whenever images are updated, consumed, or when new CVE database notifications occur.
Are those containers originally downloaded from the internet trustworthy? Often no, but your on-staff developers aren’t perfect either: Their code will include bugs, and they might incorporate libraries and packages subject to flaws.
If your system logs the flow and use of container images, you can even produce reports quantifying your risks with specific times, dates and locations — not unlike having security camera recordings in a warehouse.
Image Signing and Access Control for Governance
Container images can be signed, and signatures can be verified at the time of deployment. This is analogous to a laser hologram identifying the provenance of a manufactured item.
Some open source code may not be licensed for your particular use, putting you in legal jeopardy.
A private registry lets you decide who gets to approve the containers that get to run on your systems and allows verification later that the image hasn’t been tampered with.
Role-based access control enforces user permission related to specific activities, locations, and departments — who gets to publish updated images, and who gets to consume them.
Governance supplements scanning. Without specific procedures and protections in place, bugs and malicious code — or code that wasn’t licensed for your use — could metastasize throughout your org.
The Advantages of Replication Support
When you run at scale, a single central registry is unlikely to meet your needs. Running registries close to the systems running the containers cuts deployment latency and reduces exposure to network outages. Running multiple registry instances behind a load balancer brings scale and high availability advantages. Sometimes it is also desirable to segregate development, test, and production registries as part of an automated CI/CD pipeline.
If your registry supports policy-driven automated image replication, multiple registries can support automated continuous container development workflows, load balancing, high availability and global scale multi-cloud operation — all with minimal operational overhead and delays. You don’t want to run this with manual operations and inter-departmental “tickets.
Final Thoughts
Many popular container registries are open source, but some have wider adoption and broader community backing than others. Since you have options, it can pay in the long run to look for a solution with a vibrant community (with a large number of actively contributing developers and organizations), under the governance of an effective organization such as the CNCF. This can increase the odds that bugs will be identified and fixed quickly and new features and functionality will be added in the future.
Software application development is a never-ending process, but container image registries keep things as clear-cut and straightforward as possible. They keep everyone singing from the same songbook, and prevent “bad apples” from tainting the health of your organization. Don’t just settle for a simple container image registry that offers basic functionality and an API.
Feature image via Pixabay.