diff --git a/Standards/scs-0210-v1-k8s-new-version-policy.md b/Standards/scs-0210-v1-k8s-new-version-policy.md index 55b26657c..7d996ed0a 100644 --- a/Standards/scs-0210-v1-k8s-new-version-policy.md +++ b/Standards/scs-0210-v1-k8s-new-version-policy.md @@ -37,7 +37,7 @@ The remaining 2 months are only for: ## Motivation -Kubernetes is a fast paced project. +Kubernetes is a fast-paced project. We want to achieve that providers keep up to date with upstream and do not fall behind Kubernetes releases. This ensures that users are able to upgrade their clusters to address security issues, bug fixes and new features when using SCS compliant clusters in regards of Kubernetes. However, providers should have reasonable time to implement the new Kubernetes versions and test them. diff --git a/Standards/scs-0212-v1-requirements-for-container-registries.md b/Standards/scs-0212-v1-requirements-for-container-registries.md new file mode 100644 index 000000000..445110606 --- /dev/null +++ b/Standards/scs-0212-v1-requirements-for-container-registries.md @@ -0,0 +1,128 @@ +--- +title: Requirements for container registries +type: Standard +status: Draft +track: KaaS +--- + +## Introduction + +A container registry is an infrastructure service to enable storing and accessing container +images. Images can be pushed to the registry by e.g. Continuous integration pipelines and +be pulled from by runtime environments like Kubernetes clusters. + +Container registries come in various forms, e.g. publicly accessible ones like Docker Hub or +self-hosted and cloud-hosted services. The latter examples may apply various access control +mechanisms to restrict access. Both solutions offer a wide range of features that may or may not +attract potential users and CSPs. + +## Terminology + +Cloud Service Provider (abbr. CSP) + Entity that provides scalable computing resources + +Identity Provider (abbr. IdP) + System that creates, maintains, and manages identity information + +## Motivation + +This standard is motivated by different use cases identified through the topics in the SCS project. +One use case would be the offering of private registries for customers by CSPs, which means that a CSP could +offer private container registries either as a service or as a provided "recipe" to deploy a private registry +utilizing the CSPs infrastructure. +Another use case would be the selection of a registry for the SCS reference implementation. + +The idea and purpose of this document is to specify what requirements a specific technical container +registry implementation (i.e. software solution) needs to fulfill for an SCS-compliant registry. + +## Design considerations + +There are numerous features that should be evaluated for a container registry solution. +It is important to assess the registries based on the requirements of the OSS health checks and +desired features defined by the SCS. The following two subsections show these requirements. + +### OSS health check + +It is important to evaluate the health of a project before even evaluating the project for its feature set. +A project should therefore fulfill all OSS health checks be defined by the +[OSS-Health](https://github.com/SovereignCloudStack/standards/blob/main/Drafts/OSS-Health.md) document. +This document evaluates the health of the open-source projects that were selected from +the currently available solutions. The container registry software must fulfill all OSS +health checks defined below: + +- Four Opens (code is fully open source, community is open and diverse, development process is open, design process is open) +- Maturity +- Security +- Activity +- Lock-in risk assessment + +### Required and desirable features check + +A container registry provides a specific feature set, which can be mapped out against the requirements +described in this section. The registry should generally be robust (e.g. operate under heavy load) and +secure in order to be acceptable for the SCS standard. Therefore, a required and optional feature set +were defined, to which a container registry must abide and be evaluated against. + +#### Required features + +- Audit Logs + - ability to record use in auditable logs so that activity can be traced to a single user +- Authentication of system identities + - support for authenticating system identities like Kubernetes clusters + - possibly support for dynamic identity tokens from some IdP +- Authentication of users + - support for multiple authentication systems (IdM integration) + - user and user account management +- Authorization + - role-based access control to ensure strict access controls +- Automation + - integration with CI/CD tools e.g. via webhooks +- Vulnerability scanning + - reveal security vulnerabilities in container images +- Content Trust and Validation + - verify image authenticity before running + - image signing +- Multi-tenancy + - container registry is able to serve multiple tenants (projects, teams, namespaces) + - implementation on the storage level, see e.g. [Keppel](https://github.com/sapcc/keppel#overview), which uses + multi-tenant-aware storage drivers +- Backup and restore + - possible strategies for disaster recovery and data migration scenarios +- Monitoring + - observability is a key feature for operating a service in production so the container registry should expose key metrics +- HA mode + - enable the possibility of system uptime, even if a failure of some sort could occur +- Registry replication + - replication allows users to replicate container images between registries of the same instances and between registries of different instances as well +- Proxy cache (pull-through cache) + - Proxy cache enables the use of a container registry to proxy and cache images from a target public or private registry +- Quota management + - ability to control resource use of components or the whole registry +- Garbage collection + - removing blobs from the filesystem when they are no longer referenced by a manifest +- Retention policy + - reduce the number of image tags, many of which might not be required after a given time or once a subsequent image tag has superseded them + +#### Desirable features + +- Additionally supported artifacts + - Additional artifacts that the registry is able to store in addition to OCI artifacts, e.g. Java, Node.js, or Python packages +- Integration possibilities + - Ability to cooperate with another software solution in order to improve own feature set (e.g. integration of P2P solution for improving container image distribution (download speed and stability, high scalability, ...)) +- Deployment capabilities + - ways to deploy a container registry (only "official" ways are mentioned) +- Administration capabilities "as a code" + - ability to manage container registry via "as a code" solutions, e.g. Ansible role + +## Standard + +It is very unlikely, that every Container registry can fulfill every requirement defined by this document, and probably +not all deployments require every feature listed here. The required feature set should therefore be carefully considered +by the provider of the registry. We nevertheless RECOMMEND using most of the feature set provided in this document. + +If the features mentioned above are all considered, a possible registry solution SHOULD fulfill the majority of +the required features. But this is again dependent on the specific use case and the surrounding architecture. + +## Related Documents + +[OSS-Health](https://github.com/SovereignCloudStack/standards/blob/main/Drafts/OSS-Health.md) diff --git a/Standards/scs-0212-v1-requirements-for-container-registry.md b/Standards/scs-0218-v1-container-registry-for-scs-standard-implementation.md similarity index 56% rename from Standards/scs-0212-v1-requirements-for-container-registry.md rename to Standards/scs-0218-v1-container-registry-for-scs-standard-implementation.md index 51f31ac7c..6a1abc8ef 100644 --- a/Standards/scs-0212-v1-requirements-for-container-registry.md +++ b/Standards/scs-0218-v1-container-registry-for-scs-standard-implementation.md @@ -1,5 +1,5 @@ --- -title: Requirements for container registry +title: Container registry for SCS standard implementation type: Decision Record status: Draft track: KaaS @@ -11,65 +11,35 @@ A container registry is an infrastructure service to enable storing and accessin images. Images can be pushed to the registry by e.g. Continuous integration pipelines and be pulled from by runtime environments like Kubernetes clusters. -Container registries could be publicly accessible e.g. Docker Hub, could be -self-hosted or hosted by cloud service providers (CSP). These container registries may -apply various access control mechanisms to restrict public access and make them private. -Both solutions offer a wide range of features that may or may not attract potential -users and CSPs. +In the standard document ["Requirements for container registries"], requirements for a +registry in the context of SCS were introduced. These are based on the principals, that +a usable project should be open source, active and feature-rich, especially with regard +to security. -## Motivation - -This proposal is motivated by use cases in which CSPs would like to offer -private container registries to their customers. The specific use cases should be -discussed, but overall CSP could offer a private container registry as a service or -CSP could offer a recipe (maintained by SCS) for customers to deploy the private -registry themselves utilizing CSP infrastructure. In both cases, the private -container registry should fulfill a set of needed requirements e.g. for security and -privacy. - -The idea and purpose of this document is to specify what requirements a -specific technical container registry implementation (i.e. software solution) needs to -fulfill in the context of SCS. - -Another purpose is the selection of an appropriate container registry -implementation that meets all defined requirements to make architectural -decision on what implementation will be used by the SCS. - -## Design considerations +## Terminology -There are numerous features to look for when evaluating a container registry solution. -Our decision process goes through two main stages: +Cloud Service Provider (abbr. CSP) + Entity that provides scalable computing resources -1. [OSS health check](#oss-health-check) -2. [Required and desirable features check](#required-and-desirable-features-check) +Cloud Native Computing Foundation (abbr. CNCF) + Organization that hosts and develops open source projects for cloud native computing -The open-source software (OSS) health check is the first filter stage. This stage is -crucial in the context of SCS and container registry implementation should pass it to -promote itself to the second consideration stage. The second stage provides an overview -over the feature set of open source container registry implementations and map out -requirements (and nice-to-haves) against it to have a well-documented decision. - -Note: Keep in mind that at the time of writing this document, we've made our best effort -to survey the container registry landscape based on publicly available materials. -If you find something outdated (with respect to the time of writing this document) or -outright erroneous, please submit a PR or raise an issue, and we'll fix it right away. +## Motivation -### OSS health check +In order to provide a usable, complete experience for the SCS reference implementation, it must be decided +on a registry in accordance with requirements set by the ["Requirements for container registries"] standard +as well as other dependencies set by the SCS project, including the [OSS requirements](https://github.com/SovereignCloudStack/standards/blob/main/Drafts/OSS-Health.md). -This section evaluates the health of the open-source projects that were selected from -the currently available solutions. The container registry software must fulfill all OSS -health checks defined by the [OSS-Health](https://github.com/SovereignCloudStack/standards/blob/main/Drafts/OSS-Health.md) -document. The main health checks are: +This document should finally lead to a decision about the container registry used as a reference implementation of the SCS container registry. -- Four Opens (code is fully open source, community is open and diverse, development - process is open, design process is open) -- Maturity -- Security -- Activity -- Lock-in risk assessment +### Evaluated projects -Each selected OSS project is evaluated based on the above checks, and it is classified -into one of three categories as follows: +A few open source projects were evaluated for this document in order to find suitable candidates +for the SCS reference implementation. These projects can be found in the following list of +evaluated projects with their classified categories and comments. An initial assessment was +done with the checks for [OSS healthiness](https://github.com/SovereignCloudStack/standards/blob/main/Drafts/OSS-Health.md) +and a general overview of the features described in ["Requirements for container registries"], which enables +classifying the projects into one of three categories as follows: - :heavy_check_mark: The project passed all OSS health checks and will be considered further as a valid candidate. @@ -82,10 +52,9 @@ into one of three categories as follows: showstoppers have been found (e.g. open core software, not actively maintained). The project is filtered at this stage and won't be considered further. -Refer to the list of evaluated projects with their classified categories and comments. - -- :heavy_check_mark: [Harbor][harbor] +The following list contains these projects with a small assessment listed below them: +- :heavy_check_mark: [Harbor](https://github.com/goharbor/harbor) - Harbor project meets all "four opens" - Source code is open and available under the [Apache 2 license](https://github.com/goharbor/harbor/blob/main/LICENSE) - Community is [open](https://github.com/goharbor/harbor#community), structured and @@ -120,8 +89,7 @@ Refer to the list of evaluated projects with their classified categories and com maintainers/contributors that differ over various companies, we therefore deem the lock-in risk arising from a single point of failure to be low -- :heavy_check_mark: [Dragonfly][dragonfly] - +- :heavy_check_mark: [Dragonfly](https://github.com/dragonflyoss/Dragonfly2) - Dragonfly project meets all "four opens" - Source code is open and available under the [Apache 2 license](https://github.com/dragonflyoss/Dragonfly2/blob/main/LICENSE) - Community is [open](https://github.com/dragonflyoss/Dragonfly2#community) @@ -149,8 +117,7 @@ Refer to the list of evaluated projects with their classified categories and com includes contributors from various companies and the [companies contributing dashboard](https://dragonfly.devstats.cncf.io/d/7/companies-contributing-in-repository-groups) shows that ~10 companies are actively contributing to a repository group -- :grey_question: [Project Quay][projectquay] - +- :grey_question: [Project Quay](https://github.com/quay/quay) - Project Quay meets all "four opens" - Source code is open and available under the [Apache 2 license](https://github.com/quay/quay/blob/master/LICENSE) - Community is [open](https://github.com/quay/quay#community) organized via mailing @@ -160,7 +127,7 @@ Refer to the list of evaluated projects with their classified categories and com - Design process is open via [JBoss JIRA](https://issues.redhat.com/projects/PROJQUAY/issues) issues. The project's roadmap is available on the project's [webpage](https://www.projectquay.io/#contribute) - Maturity - - Project Quay is an open-source project that starts [~9 years ago](https://github.com/quay/quay/commit/0349af754204375d74ac5833713b607398981ff7). + - Project Quay is an open-source project that started [~9 years ago](https://github.com/quay/quay/commit/0349af754204375d74ac5833713b607398981ff7). It powers Red Hat enterprise products Red Hat Quay and Quay.io, which are used in a productive way by many. Therefore, the project's maturity is at the good level - Security @@ -174,25 +141,22 @@ Refer to the list of evaluated projects with their classified categories and com - The project's owners/maintainers list is not publicly available and is stored in the [downstream repository](https://github.com/quay/quay-docs#how-do-i-set-up). Therefore, it is hard to distinguish the risk of project failure caused by low - diversity across the companies. This should be improved + diversity across the companies. This should be improved. - :x: [Keppel](https://github.com/sapcc/keppel) - - The project seems to be not widely used in a productive way and also the activity around is currently not on a good level (5+ contributors). The development - process as well as the design process seem to be open, but not documented yet + process as well as the design process seem to be open, but neither of them are + documented yet. - :x: [Nexus](https://github.com/sonatype/nexus-public) - - Nexus is an **open core** software that offers paid [pro version](https://www.sonatype.com/products/repository-oss-vs-pro-features) with advanced features - :x: [JFrog](https://jfrog.com/community/open-source/) - - JFrog Artifactory is shipped as an **open core** [software](https://jfrog.com/community/open-source/) with limited features. The software is primarily offered as a paid [pro version](https://jfrog.com/pricing/#devops-onprem) - :x: [Kraken](https://github.com/uber/kraken) - - It seems that the project is not actively maintained as is discussed in the related project's [issue](https://github.com/uber/kraken/issues/313) @@ -200,131 +164,35 @@ Refer to the list of evaluated projects with their classified categories and com - It seems that the project is not actively maintained as is discussed in the related project's [issue](https://github.com/SUSE/Portus/issues/2352) -### Required and desirable features check - -This section provides an overview of the feature set of open source container registry -implementations (which passed the OSS health stage above) and map out requirements -(and nice-to-haves) against it. The container registry software must be robust enough, -to be able to operate under heavy load (e.g. high availability (HA) mode, federation, etc.) and -the crucial feature is security. -We defined a set of required features that the container registry implementation must -have and also a set of desirable (nice to have) features are defined and evaluated here. - -#### Required features - -- Audit Logs - - Ability to record use in auditable logs so that activity can be traced to a single user -- Authentication of system identities - - Support for authenticating system identities like Kubernetes clusters. Ideally supporting dynamic identity tokens from some IdP; Less ideal: Supporting static "system tokens" -- Authentication of users - - Support for multiple authentication systems (IdM integration). User and user account management -- Authorization - - Role-based access control to ensure strict access controls -- Automation - - Integration with CI/CD tools e.g. via webhooks -- Vulnerability scanning - - Reveal security vulnerabilities in container images -- Content Trust and Validation - - Verify image authenticity before running - image signing -- Multi-tenancy - - Container registry is able to serve multiple tenants (projects, teams, namespaces). It can be implemented also on the storage level, see e.g. [Keppel](https://github.com/sapcc/keppel#overview) -- Backup and restore - - It is important for disaster recovery and data migration scenarios -- Monitoring - - Observability is a key feature for operating a service in production so the container registry should expose key metrics -- HA mode - - Ensure system uptime even in the event of a failure -- Registry replication - - Replication allows users to replicate container images between registries of the same instances and between registries of different instances as well -- Proxy cache (pull-through cache) - - Proxy cache allows you to use a container registry to proxy and cache images from a target public or private registry -- Quota management - - Control over resource use -- Garbage collection - - Removing blobs from the filesystem when they are no longer referenced by a manifest -- Retention policy - - Reduce the number of image tags, many of which might not be required after a given time or once a subsequent image tag has superseded them - -#### Desirable features - -- Additionally supported artifacts - - Additional artifacts that the registry is able to store in addition to OCI artifacts, e.g. Java, Node.js, or Python packages -- Integration possibilities - - Ability to cooperate with another software solution in order to improve own feature set (e.g. integration of P2P solution for improving container image distribution (download speed and stability, high scalability ...)) -- Deployment capabilities - - How could be a container registry deployed (only "official" ways are mentioned) -- Administration capabilities "as a code" - - Ability to manage container registry via "as a code" solutions, e.g. Ansible role - -Refer to the table of evaluated projects with their features. Note that only container -registry implementations that passed the OSS health stage (Harbor, Quay, and Dragonfly) -are evaluated here. - -| Features | Harbor | Quay | Dragonfly | -| ----------------------------------- | -------------------------------------- | ------------------------------------------------------------------- | ----------------------------- | -| Audit Logs | ✓ | ✓ | ✗ | -| Authentication of system identities | ✓ Robot Accounts | ✓ Robot Accounts | ✗ | -| Authentication of users | ✓ Local database, LDAP, OIDC, UAA | ✓ Local database, LDAP, Keystone, JWT | ✓ Local database | -| Authorization | ✓ | ✓ | ✓ | -| Automation | ✓ Webhooks (HTTP, Slack) | ✓ Webhooks (HTTP, Slack, E-mail ...), building images | ✗ | -| Vulnerability scanning | ✓ Trivy, Clair | ✓ Clair | ✗ | -| Content Trust and Validation | ✓ Cosign | ✓ Cosign | ✗ | -| Multi-tenancy | ✓ (not on the storage level) | ✓ (not on the storage level) | ✓ (not on the storage level) | -| Backup and restore | ✓ | ✓ | ✗ | -| Monitoring | ✓ Prometheus metrics, Tracing | ✓ Prometheus metrics, Tracing (only for Clair) | ✓ Prometheus metrics, Tracing | -| HA mode | ✓ | ✓ | ✗ | -| Registry replication | ✓ | ✓ | ✓ | -| Proxy cache | ✓ | ✓ Feature is in the technology preview stage (non production ready) | ✗ | -| Quota management | ✓ Based on storage consumption | ✓ Based on storage consumption | ✗ | -| Garbage collection | ✓ Non-blocking | ✓ Non-blocking | ✗ | -| Retention policy | ✓ Multiple tag retention rules | ✓ Only tag expiration rules | ✗ | -| Additional supported artifacts | ✗ (only OCI artifacts) | ✗ (only OCI artifacts) | ✓ Maven, YUM | -| Integration possibilities | ✓ Dragonfly (P2P), Kraken (P2P) | ✗ | ✓ Harbor, Nydus, eStargz | -| Deployment capabilities | ✓ Docker-compose, Helm chart, Operator | ✓ Docker-compose, Operator | ✓ Docker-compose, Helm chart | -| Administration capabilities | ✓ Terraform, CRDs, Client libraries | ✓ Ansible, Client libraries | ✓ Client libraries | - -Notes: - -- Automation: Harbor should support webhooks following CloudEvents spec in the [next release](https://github.com/goharbor/harbor/issues/17748) -- Content Trust and Validation: Harbor announced the deprecation of [Notary](https://github.com/goharbor/harbor/discussions/16612) - integration, hence it is not mentioned in the table -- Multi-tenancy: Harbor, Quay, as well as Dragonfly, operates on a single storage - backend (e.g. S3), i.e. the storage of container images is shared between tenants -- Additional supported artifacts: Harbor announced the deprecation of [Chartmuseum](https://github.com/goharbor/harbor/discussions/15057) - integration, hence it is not mentioned in the table - -### Conclusion +### Deeper look into selected projects -A wide range of open-source container registry projects (Quay, Harbor, Dragonfly, +In the previous section, 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. 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 +pass it. It 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][harbor] -- [Project Quay][projectquay] -- [Dragonfly][dragonfly] +- [Harbor](https://github.com/goharbor/harbor) +- [Project Quay](https://github.com/quay/quay) +- [Dragonfly](https://github.com/quay/quay) The above projects were then evaluated from the "supported features" perspective. -The [Required and desirable features check](#required-and-desirable-features-check) -investigated the feature set of open-source container registry implementations and -mapped 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). +The document ["Requirements for container registries"] provides a "Required and desirable features check", which +provides desired feature sets for open-source container registry implementations according to +SCS requirements (and nice-to-haves). 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). These requirements should ensure that the selected container registry implementation could be offered by CSPs as a secure and enterprise-ready solution. -The following section compares projects Dragonfly, Quay, and Harbor. +The following section compares the selected projects Dragonfly, Quay, and Harbor. -[Dragonfly][dragonfly] is a healthy open-source project with a growing community +[Dragonfly](https://github.com/dragonflyoss/Dragonfly2) is a healthy open-source project with a growing community and CNCF incubating maturity level. It is considered stable, and widely 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. @@ -337,7 +205,7 @@ both parties may benefit from the integration. Harbor profits from Dragonfly's p distribution capabilities and on the other hand the Dragonfly project profits from Harbor's feature-rich container registry "frontend". -[Quay][projectquay] is an open-source project maintained by Red Hat. Its OSS health is +[Quay](https://github.com/quay/quay) is an open-source project maintained by Red Hat. Its OSS health is on a good level, the surrounding community is growing, and we consider it to be quite mature as it powers enterprise solutions like Red Hat Quay and Quay.io. Besides this, there is still a place for OSS health improvement. It is hard to @@ -358,7 +226,7 @@ using a set of workers on e.g. Kubernetes. Build triggers, such as GitHub webhoo 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 +[Harbor](https://github.com/goharbor/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 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 @@ -377,13 +245,51 @@ storage drivers instead so that each customer gets their own separate storage ba CSP that considers offering container registry "as a service" solution based on Harbor should be aware of this shared storage backend architecture. +In the following table, the feature sets of the evaluated projects that passed the OSS health state +are listed and matched against. This enables a better understanding of the decision-making for this document. + +| Features | Harbor | Quay | Dragonfly | +|-------------------------------------|-----------------------------------------|---------------------------------------------------------------------|-------------------------------| +| Audit Logs | ✓ | ✓ | ✗ | +| Authentication of system identities | ✓ Robot Accounts | ✓ Robot Accounts | ✗ | +| Authentication of users | ✓ Local database, LDAP, OIDC, UAA | ✓ Local database, LDAP, Keystone, JWT | ✓ Local database | +| Authorization | ✓ | ✓ | ✓ | +| Automation | ✓ Webhooks (HTTP, Slack) | ✓ Webhooks (HTTP, Slack, E-mail ...), building images | ✗ | +| Vulnerability scanning | ✓ Trivy, Clair | ✓ Clair | ✗ | +| Content Trust and Validation | ✓ Cosign | ✓ Cosign | ✗ | +| Multi-tenancy | ✓ (not on the storage level) | ✓ (not on the storage level) | ✓ (not on the storage level) | +| Backup and restore | ✓ | ✓ | ✗ | +| Monitoring | ✓ Prometheus metrics, Tracing | ✓ Prometheus metrics, Tracing (only for Clair) | ✓ Prometheus metrics, Tracing | +| HA mode | ✓ | ✓ | ✗ | +| Registry replication | ✓ | ✓ | ✓ | +| Proxy cache | ✓ | ✓ Feature is in the technology preview stage (non production ready) | ✗ | +| Quota management | ✓ Based on storage consumption | ✓ Based on storage consumption | ✗ | +| Garbage collection | ✓ Non-blocking | ✓ Non-blocking | ✗ | +| Retention policy | ✓ Multiple tag retention rules | ✓ Only tag expiration rules | ✗ | +| Additional supported artifacts | ✗ (only OCI artifacts) | ✗ (only OCI artifacts) | ✓ Maven, YUM | +| Integration possibilities | ✓ Dragonfly (P2P), Kraken (P2P) | ✗ | ✓ Harbor, Nydus, eStargz | +| Deployment capabilities | ✓ Docker-compose, Helm chart, Operator | ✓ Docker-compose, Operator | ✓ Docker-compose, Helm chart | +| Administration capabilities | ✓ Terraform, CRDs, Client libraries | ✓ Ansible, Client libraries | ✓ Client libraries | + +Notes: + +- Automation: Harbor should support webhooks following CloudEvents spec in the [next release](https://github.com/goharbor/harbor/issues/17748) +- Content Trust and Validation: Harbor announced the deprecation of [Notary](https://github.com/goharbor/harbor/discussions/16612) + integration, hence it is not mentioned in the table +- Multi-tenancy: Harbor, Quay, as well as Dragonfly, operates on a single storage + backend (e.g. S3), i.e. the storage of container images is shared between tenants +- Additional supported artifacts: Harbor announced the deprecation of [Chartmuseum](https://github.com/goharbor/harbor/discussions/15057) + integration, hence it is not mentioned in the table + ## Decision -Based on the research and conclusion above we've decided to use the **Harbor** project -as a container registry implementation for the SCS ecosystem. +Based on the requirements laid out in ["Requirements for container registries"], the OSS health check +and the possible software solutions presented in this document, it was decided to use the **Harbor** project +as the container registry for the SCS reference implementation. - +## Related Documents -[harbor]: https://github.com/goharbor/harbor -[dragonfly]: https://github.com/dragonflyoss/Dragonfly2 -[projectquay]: https://github.com/quay/quay +["Requirements for container registries"](scs-0212-v1-requirements-for-container-registries.md) +[harbor](https://github.com/goharbor/harbor) +[dragonfly](https://github.com/dragonflyoss/Dragonfly2) +[projectquay](https://github.com/quay/quay)