Container image registry Harbor has made the jump to version 2.0, which sees the project switching to a different image scanner and taking on OCI compliance.

OCI, the open container initiative, is a Linux Foundation project aiming to promote formal specifications for the container image format and runtime, which were released in July 2017. Some time has passed since then, but for a while issues like security had, quite understandably, been more pressing to the Harbor team. Implementing proper support for OCI images and their indexes, hasn’t been exactly cheap either, project maintainer Michael Michael writes in an email.

“Harbor already supported Helm charts and container images, satisfying the majority of use cases from our adopters. Once we prioritized OCI, we worked with the community to deliver first-class support for OCI compliant images. This meant evaluating everything, from how to make OCI the key artifact story in Harbor, to ensuring that all of the rest of the Harbor policies apply well to OCI. Such policies include quotas, retention policies, scanning, compliance, immutability, replication, and many more.”

The work has paid off, though, allowing the tool to handle OCI indexes like Docker manifest lists, and users to push Helm charts into Harbor through Helm3 or delete image tags without losing the underlying manifest. It also lays the foundation for future capabilities, Michael reports. “An additional net benefit of OCI is that even though we still rely on the Docker distribution to store the images, Harbor is now managing all the metadata about the artifacts in its database.” 

But that’s not all that is new in this major release. The Harbor team for example decided to replace Clair with Trivy as the default for image scanning, mainly due to it being easy to integrate into CI/CD systems and its wide coverage. It will however only be the standard for new installations, leaving old projects set on Clair unaffected, since the scanner will continue to be a built-in option. Another security relevant change is the option of enabling TLS between Harbor components.

To keep up with the surging Slack uptake, webhooks come with integration for the chat platform (in addition to HTTP) and can be individually triggered in Harbor 2.0. Meanwhile users can now set individual expiration times for each robot in the robot account. A list of fixed issues can be found in the project repository.

Despite all these changes, updating should be “fairly easy” according to Michael. “Harbor 2.0 introduces incompatibility only at the API layer. Essentially all the Harbor APIs will bump up their version to 2.0. We are however not changing the mechanics of the requests (API call, API parameters, etc), just the version increase.”

Harbor was started by VMware in 2014. It made its way into the Cloud Native Computing Foundation’s sandbox in summer 2018, moving into the Incubator only a couple of months later. Comparable products include Red Hat’s Quay, which also recently saw an update. 

Highlights of the Quay 3.3 release include deeper integration with Red Hat OpenShift via a newly released Quay Bridge Operator, and “a completely overhauled version of the Clair container security scanner”, which is now in version 4. Red Hat sticking with Clair may be due to its acquisition of CoreOS, who initially started the project.

Quay 3.3 also comes with tech previews of OCI specifications, which goes to show that Harbor isn’t as late to the game as it might seem to some.