Harbor, the open-source container image registry, has reached version 2.0, becoming the first open-source registry to fully support the Open Container Initiative (OCI) image specification.
There are quite a few registries that allow you to store container images – which represent blueprints for launching containerized applications – and other cloud app artifacts that describe related metadata like Helm charts, OPAs (Open Policy Agents), and other configuration-related files.
Perhaps the best known is the open source Docker Registry and Docker Hub, a hosted implementation of that code.
There’s also Portus, an authorization server and front-end for Docker Registry made by SUSE. And there are various commercial offerings from cloud providers like Alibaba Container Registry, Amazon Elastic Container Registry (ECR), Azure Container Registry, GitLab Container Registry, Google Container Registry, and Red Hat Quay.
Harbor was developed by VMware and put under the oversight of the Cloud Native Computing Foundation in 2018. It’s used by thousands of enterprise organizations that want to run their own container image registries, said Michael Michael, director of product management at VMware and Harbor maintainer, in an interview with The Register.
The OCI defines an image specification, for building the application, and a runtime specification, for creating the application environment.
So Harbor’s OCI-compliance means that it supports the full set of APIs for defining what can be stored in a Harbor registry.
“Now you have more ways to describe what a container image looks like and how it can be deployed,” said Michael. “It enables you to store in any OCI-complaint registry all of the cloud-native artifacts that are important to you.”
These cloud-native artifacts, he explained, allow policy rules to be applied to ensure that containers are handled securely.
Version 2.0 brings several noteworthy features.
For example, Harbor now supports the OCI image index specification, by which platform-specific versions of an image can be declared via an index. Also, charts for Helm, the Kubernetes package manager, can now be stored within Harbor, using Helm v3, instead of separately in a Helm-specific repository known as Chart Museum.
AWS revamps Fargate serverless containers, but wait – where’s Docker Engine? Ah, ‘deemed unnecessary’
Also, the Clair image scanner, which looks for vulnerabilities in Harbor-stored images, is being replaced, though it will still be supported.
“We’re making Aqua’s image scanner Trivy the default scanner for all your projects,” said Michael.
Version 2.0 adds the ability to set expiration dates on individual robot accounts, instead of just a single system-wide setting. It also introduces the ability to configure Harbor services to use SSL, a significant security improvement.
And it adds the ability to trigger webhooks – API callbacks – individually, so users can configure them, on a project basis, to target HTTP or Slack.
Michael said the 2.0 update also lays the groundwork for future improvements to how Harbor handles container image garbage collection – containers create a lot of files that need to be removed. The Docker model of garbage collection, he said, isn’t scalable because it adds downtime. Harbor now tracks all the layers in an image and in the future will be able to handle garbage collection without downtime. ®
Follow me for more information.