Cloud-native: Harbor 2.0 beherbergt als offenes Quellenregister Container & Co.

Die offene Source Registry verwaltet mit Kubernetes erzeugte Artefakte gemeinsam und ist jetzt konform zu den Standards der Open Container Initiative (OCI).

In Pocket speichern vorlesen Druckansicht 6 Kommentare lesen
Cloud-native: Harbor 2.0 beherbergt als offenes Quellenregister Container & Co.

(Bild: Travel mania/Shutterstock.com)

Lesezeit: 4 Min.
Von
  • Silke Hahn
Inhaltsverzeichnis

Mit Harbor 2.0 ist nun die erste Open-Source-Registry für Kubernetes und Cloud-native Artefakte wie Container-Images, Helm-Charts, OPAs und Singularity allgemein verfügbar. Harbor vermag offenbar als erste und bislang einzige Source Registry, Cloud-native Objekte gemäß den Vorgaben der Open-Container-Initiative zu speichern (OCI-konform).

Entwickler, die nach dem OCI-Standard entwickeln, sollten Harbor 2.0 ohne größere Änderungen verwenden können, um ihre Artefakte zu speichern, teilte die Cloud Native Computing Foundation (CNCF) in der Ankündigung mit. Aber auch bestehende Nutzer von Harbor 1.x sollten laut Ankündigung nichts zu befürchten haben, da die gewohnten Operationen wie push, pull, delete, retag, copy, scan und sign indexes sich wohl leicht auf den neu implementierten OCI-Standard übertragen lassen.

OCI sei ein bewährter Industriestandard, der Spezifikationen zu Format, Laufzeit und Verteilung von z.B. Docker-Images und Helm-Charts definiert – der Standard bringe Autoren und Registry-Anbieter unter einem gemeinsamen Dach zusammen. Bislang war es offenbar notwendig, Helm-Charts separat in einem ChartMuseum aufzubewahren. Helm 3 soll nun Helm-Charts in den Harbor verschieben können, wo sie gemeinsam mit Docker-Images und Cloud Native Application Bundles (CNAB) lagern dürfen.

Zwei Spezifikationen stehen im Zentrum von OCI: eine für Images und eine für die Runtime. Sie definieren, wie ein Image aussehen muss, bis hin zum Archivierungsformat und den Inhalten, die in der Regel das Manifest, einen (optionalen) Image-Index, die Anordnung der Dateisystemebenen und eine Konfigurationsdatei umfassen. Die OCI-Runtime wandelt die Konfigurationsdatei in eine ausführbare Datei um, die das Dateisystembündel gemäß Laufzeitspezifikation konsumiert. Für Images bietet OCI also den Rahmen zum Erstellen interoperabler Werkzeuge für die Erstellung, den Transport und die Vorbereitung von Images zur Ausführung – die Runtime-Richtlinien hingegen geben die Konfiguration, Ausführungsumgebung und den Lebenszyklus des Containers vor.

Blick ins Backend von Harbor 2.0, einer Source Registry für Kubernetes und Cloud-Artefakte, die hier nach OCI-Standard zentral beherbergt werden

(Bild: Cloud Native Computing Foundation (CNCF))

Die OCI-Konformität versetzt Harbor offenbar in die Lage, Manifeste auf einer Metaebene zu verarbeiten: Der OCI-Index stelle eine Bündelung von Image-Manifesten dar, wodurch Harbor sich auch zum Verwalten von Szenarien mit mehreren unterschiedlichen Architekturen anbieten dürfte. CNAB unterstützen offenbar diese Form der Indexstruktur zur Verwaltung verteilter, Cloud-agnostischer Anwendungen.

Neuerungen gebe es laut Pressemeldung beim Scannen von Schwachstellen und bei den Projekt-Richtlinien, die als Schlüssel für Sicherheit und Übereinstimmung gelten. Aqua Trivy kommt als neuer Standardscanner zum Einsatz und soll auch Tiefenscans ausführen und Schwachstellen in Distributionen wie CentOS, Debian und Ubuntu finden können. Der bisherige Standardscanner Clair bleibt Bestandteil der Registry und kann optional weiterhin zum Einsatz kommen.

Vor allem bedeutet die Unterstützung von OCI-kompatiblen Images in Harbor wohl, dass ein festgelegter Satz an APIs unterstützt und Schlüsselinformation übersetzt werden: Die Registry müsse die Layer nicht mehr zuerst beziehen und dann zerlegen. Harbor bezieht offenbar die Informationen über die Medientypen eines Artefakts aus dessen Manifest- und der Konfigurationsdatei, womit das zu speichernde Artefakt sich gegenüber der Registry identifiziert. Die Definition der Dateisystem-Layer hingegen beziehe Harbor aus dem layer.mediaType.

Weitere Neuerungen umfassen einen optionalen Dark Mode, Webhooks für die Slack-Integration und die Möglichkeit, SSL für Kerndienste von Harbor zu definieren, um die interne Service-to-Service-Kommunikation zu verschlüsseln. Dies diene vor allem dazu, Angriffe nach dem Schema "Man-in-the-Middle" zu reduzieren.

Mehr Details lassen sich wahlweise der Ankündigung auf GoHarbor entnehmen oder der parallelen Ankündigung der Cloud Native Computing Foundation. Informationen zu den Index-Spezifikationen finden sich auf der GitHub-Seite. Wer sich mit dem neuen Standardscanner vertraut machen möchte, findet das Projekt Aqua Trivy auf GitHub. Die CNCF bietet am 28. Mai 2020 um 18 Uhr (MEZ) ein Webinar zur Einführung in Harbor 2.0. (sih)