You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit adds list of required and desirable features of container registry as well as table comparison for selected container registries(Harbor, Quay, Dragonfly)
Signed-off-by: Roman Hros <[email protected]>
Copy file name to clipboardExpand all lines: Decisions/scs-XXXX-v1-requirements-for-container-registry.md
+61-1Lines changed: 61 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -209,7 +209,67 @@ have and also a set of desirable (nice to have) features are defined and evaluat
209
209
210
210
**Required features**
211
211
212
-
TODO
212
+
- Audit Logs
213
+
- Ability to record use in auditable logs so that activity can be traced to a single user
214
+
- Authentication
215
+
- Support for multiple authentication systems (IdM integration). User and user account management
216
+
- Authorization
217
+
- Role-based access control to ensure strict access controls
218
+
- Automation
219
+
- Integration with CI/CD tools e.g. via webhooks
220
+
- Vulnerability scanning
221
+
- Reveal security vulnerabilities in container images
222
+
- Content Trust and Validation
223
+
- Verify image authenticity before running - image signing
224
+
- Multi-tenancy
225
+
- Container registry is able to serve multiple tenants (projects, teams, namespaces)
226
+
- Backup and restore
227
+
- It is important for disaster recovery and data migration scenarios
228
+
- Monitoring
229
+
- Observability is a key feature for operating a service in production so the container registry should expose key metrics
230
+
- HA mode
231
+
- Ensure system uptime even in the event of a failure
232
+
- Registry replication
233
+
- Replication allows users to replicate container images between registries of the same instances and between registries of different instances as well
234
+
- Proxy cache (pull-through cache)
235
+
- Proxy cache allows you to use a container registry to proxy and cache images from a target public or private registry
236
+
- Quota management
237
+
- Control over resource use
238
+
- Garbage collection
239
+
- Removing blobs from the filesystem when they are no longer referenced by a manifest
240
+
- Retention policy
241
+
- 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
242
+
243
+
**Desirable features**
244
+
245
+
- Additionally supported artifacts
246
+
- Additional artifacts that the registry is able to store in addition to container images, e.g. Java, Node.js, or Python packages
247
+
- Integration possibilities
248
+
- 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 ...))
249
+
250
+
Refer to the table of evaluated projects with their features. Note that only container
251
+
registry implementations that passed the OSS health stage (Harbor, Quay, and Dragonfly)
0 commit comments