Registry Standard from DR SCS-0212

[cah-hbaum]

This MR splits the for now Decision Record for K8s registries into a Standard and a Decision Record.
A standard for this topic was long due and the Decision Record already contained much of the work.
The DR itself will now showcase the internal decision of SCS to use Harbor, but doesn't influence external decisions.

Closes SovereignCloudStack/issues#470

[cah-patrickthiem]

Just a suggestion, but maybe a section on "compliance and security" in the "Requirements for container registries" document would be beneficial. The following aspects could be considered for that section:

• importance on cyber security standards, see e.g. https://www.docker.com/trust/compliance/
• data protection and privacy laws, e.g. General Data Protection Regulation (GDPR) in Europe
• intellectual property laws

[cah-patrickthiem]

I am not quite sure if that was done in any other standards so far, but maybe something should be mentioned like the following in the "Container registry standard document" :
"This standard will be updated or revised in response to technological advancements or changes in best practices."

[cah-patrickthiem]

Suggestion: add a closing/conclusion section to the "Container registry standard document" describing the importance of adhering to these standards and the expected impact on the SCS project and its users.

[cah-patrickthiem]

Although this is mentioned: "This document should finally lead to a decision about the container registry used in the implementation."
Another section in the "Container registry standard document" could reference the importance (if it is important to SCS) of interoperability between container registries. This could be achieved by the Open Container Initiative (https://opencontainers.org/) or API Compatibility standards like Docker Registry HTTP API V2.
Another aspect worth mentioning might be the authentication and authorization mechanisms, e.g. OAuth2 or OpenID Connect.

[cah-hbaum]

Just a suggestion, but maybe a section on "compliance and security" in the "Requirements for container registries"
document would be beneficial. The following aspects could be considered for that section:

• importance on cyber security standards, see e.g. https://www.docker.com/trust/compliance/
• data protection and privacy laws, e.g. General Data Protection Regulation (GDPR) in Europe
• intellectual property laws

Interesting idea, although I'm not sure if the projects themself even do stuff like compliance. In the end, it's probably more the responsibility of the providers (using these projects) and their way of setting them up thats matters for compliance and security as well as data protection. Its probably possible for most of these projects to be compliant to standard X, but the project owners most of the time won't have time (or even money) to do that. And even if that would be the case, on what basis would you do a compliance test? The "best, most secure" setup? This wouldn't automatically translate to compliant setups for users of their software.
(Additionally while shortly looking through the best solutions presented in the DR, I didn't find any standard/guideline mentioned anywhere (I only had a really short look) regarding this topic)

I am not quite sure if that was done in any other standards so far, but maybe something should be mentioned like the following in the "Container registry standard document" :
"This standard will be updated or revised in response to technological advancements or changes in best practices."

I think we shouldn't do that either. Normally (at least IMO) a revision process should be started after some time in order to check if the standard is up-to-date. If changes are done, a new version is created, so SCS won't change the old standard.

Suggestion: add a closing/conclusion section to the "Container registry standard document" describing the importance of adhering to these standards and the expected impact on the SCS project and its users.

If someone is committed to SCS and the provided standards, I don't think they would need a conclusion. The introduction/motivation section for the standards should be reasoning enough and an additional section only creates extra "overhead".

Although this is mentioned: "This document should finally lead to a decision about the container registry used in the implementation."
Another section in the "Container registry standard document" could reference the importance (if it is important to SCS) > of interoperability between container registries. This could be achieved by the Open Container Initiative (https://opencontainers.org/) or API Compatibility standards like Docker Registry HTTP API V2.
Another aspect worth mentioning might be the authentication and authorization mechanisms, e.g. OAuth2 or OpenID Connect.

Hmmm, interoperability could be interesting, though I'm not quite sure for whom. Providers don't really need it, except if they would change the deployed registry, which probably won't really happen that much. API interoperability is probably on the same level, since customers only see a very small endpoint (to download their images) and since most registries work with the normal types of container solutions, I would assume that they're at least interoperable in this regard.

Possible auth mechanisms in the registries are indeed interesting and should be checked and mentioned.

[cah-patrickthiem]

My comments were resolved, therefore I approve this PR.

[matofeder]

LGTM