From 3a4f9a2f847dfc7fb08118ce08988f10a837cce4 Mon Sep 17 00:00:00 2001 From: Matej Feder Date: Tue, 14 Feb 2023 11:25:47 +0100 Subject: [PATCH] Add ADR: Requirements for container registry This commit adds the conclusion and decision parts of ADR. Signed-off-by: Matej Feder --- ...-v1-requirements-for-container-registry.md | 85 +++++++++++++++++-- 1 file changed, 78 insertions(+), 7 deletions(-) diff --git a/Decisions/scs-XXXX-v1-requirements-for-container-registry.md b/Decisions/scs-XXXX-v1-requirements-for-container-registry.md index 924fa0f1f..3d596047f 100644 --- a/Decisions/scs-XXXX-v1-requirements-for-container-registry.md +++ b/Decisions/scs-XXXX-v1-requirements-for-container-registry.md @@ -276,16 +276,87 @@ are evaluated here. ## Conclusion -A wide range of open-source container registry projects (Quay, Harbor, Dragonfly, -Keppel, Portus, Kraken, etc.) has been carefully evaluated based on the two main -factors that reviewed their open-source health as well as their range of supported -features. - -TODO +A wide range of open-source container registry projects (Quay, Harbor, Dragonfly, +Keppel, Portus, Kraken, etc.) has been carefully evaluated based on the two main +factors: the open-source health and range of supported features. + +The open-source software health is crucial and container registry implementation should +pass it to be SCS-compliant. The OSS health check evaluates several important metrics +of an open source software like whether the code/community/development/design is +fully open or whether the project's maturity, security, and activity are on the desired +level. This check also evaluates the lock-in risk due to possible single points of +failure or internal project conflicts and several other aspects. +Overall, three projects passed the OSS health checks: +- Harbor +- Project Quay +- Dragonfly + +The above projects were then evaluated from the "supported features" perspective. +The [Required and desirable features check](#required-and-desirable-features-check) +did an overview of the feature set of open-source container registry implementations +and map SCS requirements (and nice-to-haves) against it. The list of required features +is quite long and contains features that are primarily focused on security +(authentication, vulnerability scanning, content trust, and validation, etc.), +scalability (HA mode, registry replication, p2p integration, etc.) and visibility +(monitoring), see the full list [here](#required-and-desirable-features-check). +These requirements should ensure that the selected container registry implementation +could be offered by the CSPs as a secure and enterprise-ready solution. + +Let's discuss and compare the projects Dragonfly, Quay, and Harbor in the following +section. + +[Dragonfly][dragonfly] is a healthy open-source project with a growing community +and CNCF incubating maturity level. It is considered stable, and it is used by many +companies in their production environments. We currently see that it is not as +feature-rich as Harbor or Quay, hence it is not considered the best choice here. +It seems, that its main aim (currently) is to offer (an efficient, stable, and secure) +container distribution solution based on p2p technology. This improves download +efficiency and saves bandwidth across CSPs. It also offers integration possibilities +that allow one to use it as a p2p distribution network via a "preheat" API. This +integration was implemented in the Harbor project via Dragonfly "preheat" adapter, and +both parties may benefit from the integration. The Harbor profits from Dragonfly's p2p +distribution capabilities and on the other hand the Dragonfly project profits from +Harbor's feature-rich container registry "frontend". + +[Quay][projectquay] is the Red Hat open-source project. Its OSS health is on a good level, +the community around is growing, the maturity is considered also well as the project +represents the code that powers enterprise solutions Red Hat Quay and Quay.io. +Besides this, there is still a place for OSS health improvement. It is hard to +distinguish the risk of project failure caused by low diversity across the companies +because the project's owners/maintainers list is not publicly available and is stored in +the Red Hat private repository. +Its feature set is impressive and this project fulfills all must-haves defined in +this document. Quay gives you security over your repositories with image +vulnerability scanning (Clair integration), content validation (Cosign integration), +and access controls. Harbor stands out here as it allows users to use also project Trivy +for vulnerability scanning and project Notary for content trust and validation. +Project Quay also provides a scalable open-source platform to host container images +across any size organization. One drawback in comparison to Harbor is that the proxy cache +feature is still marked as a [Technology Preview](https://docs.projectquay.io/use_quay.html#quay-as-cache-proxy), +hence this feature may not be completely production-ready yet. On the other hand, +the project Quay supports [building Dockerfiles](https://docs.projectquay.io/use_quay.html#build-support) +using a set of workers on e.g. Kubernetes. Build triggers, such as GitHub webhooks +can be configured to automatically build new versions of repositories when new code is +committed. This feature is not supported by the [Harbor project](https://github.com/goharbor/harbor/issues/6235). + +[Harbor][harbor] is an outstanding open-source, community-led project with fully open and +well-documented processes. Its large and thriving community powers the fast-growing +the feature set and attracts more and more developers and companies to active contributions. +Harbor’s CNCF graduation in 2020 made it one of the best choices for enterprise +customers that want to operate container registries securely and in a large scale. +Its community size, landscape, and CNCF graduation make a significant difference in +comparison to Quay's open-source health capabilities. +The list of supported features is also impressive. This project fulfills all must-haves +defined in this document and overcome project Quay with a production-ready proxy cache +feature and more options that the user may use in case of image vulnerability scanning +and content validation. In addition, Harbor is able to store non-OCI Helm charts +via ChartMuseum integration and profits from p2p distribution capabilities via +integration of p2p solutions like Kraken and Dragonfly. # Decision -_Decision_ +Based on the research and conclusion above we've decided to use the **Harbor** project +as an SCS-compliant container registry implementation.