Harbor: Die Referenz-Architektur für sichere und souveräne Container Registries

TL;DR

Die Container Registry ist das Herzstück Ihrer Software-Lieferkette. Wer hier blind auf Cloud-Services wie AWS ECR vertraut, behandelt seine Images lediglich als Dateien in einem Bucket. Harbor hingegen ist eine aktive Sicherheits-Plattform. Als CNCF-graduierte Lösung bietet es integriertes Vulnerability Scanning, Image-Signierung und Replikation über Cloud-Grenzen hinweg. Es garantiert, dass nur sichere, geprüfte Software in Ihre Cluster gelangt – und dass Sie die Hoheit über Ihre Artefakte behalten.

1. Das Architektur-Prinzip: Gatekeeper statt Dateilager

Proprietäre Registries wie AWS ECR sind im Grunde nur dumme Datenspeicher (“Blob Storage”). Sie nehmen Images an und geben sie heraus. Sicherheitsprüfungen sind oft optional oder kostenpflichtige Add-ons.

Harbor agiert als aktiver Gatekeeper.

• Policy Enforcement: Sie können Regeln definieren wie: “Verhindere den Pull, wenn das Image kritische Sicherheitslücken (CVEs) hat” oder “Erlaube nur Images, die von der QS-Abteilung signiert wurden”.
• RBAC & Projekte: Harbor bietet ein extrem granulares Rechtesystem. Sie erstellen Projekte (analog zu Namespaces), weisen User via OIDC/AD zu und steuern exakt, wer pushen, pullen oder scannen darf.

2. Kern-Feature: Proxy Cache & Performance

Ein oft unterschätztes Problem in Kubernetes-Clustern ist die Abhängigkeit von öffentlichen Registries (Docker Hub, Quay).

• Rate Limits: Docker Hub blockiert IP-Adressen, die zu viele Images ziehen.
• Bandbreite: Jedes Mal, wenn ein Pod auf einem neuen Node startet, wird das Image erneut aus dem Internet geladen. Das ist langsam und teuer.

Harbor fungiert als Proxy Cache. Der Cluster fragt Harbor, Harbor holt das Image einmalig von Docker Hub und speichert es lokal. Alle weiteren Pulls kommen mit LAN-Geschwindigkeit direkt aus Harbor. Das umgeht Rate Limits und spart massive Bandbreite.

3. Sicherheit: Vulnerability Scanning & Signing

In Zeiten von Supply-Chain-Attacken (wie SolarWinds) muss Software vertrauenswürdig sein.

• Trivy Integration: Harbor scannt Images automatisch beim Push und (optional) zeitgesteuert. Es gleicht die Pakete gegen aktuelle CVE-Datenbanken ab und warnt proaktiv.
• Notary / Cosign: Harbor unterstützt das Signieren von Images. Damit wird kryptografisch sichergestellt, dass das Image, das im Cluster läuft, exakt dem Image entspricht, das Ihre CI-Pipeline gebaut hat – unverändert und unverfälscht.

4. Betriebsmodelle im Vergleich: AWS ECR vs. ayedo Managed Harbor

Hier entscheidet sich, ob Ihre Images gefangen sind oder ob sie frei beweglich bleiben.

Szenario A: AWS ECR (Der Egress-Kostentreiber)

ECR ist tief in AWS integriert, aber unflexibel für hybride Welten.

• Die Egress-Falle: ECR ist günstig, solange Sie innerhalb derselben AWS-Region bleiben. Sobald Sie Images in eine andere Region, zu einem anderen Cloud-Provider oder in Ihr lokales Rechenzentrum ziehen, zahlen Sie massive Data Transfer Fees.
• Keine echte Replikation: ECR kann zwar zwischen AWS-Regionen replizieren, aber nicht zu Azure oder Google. Ein Multi-Cloud-Deployment wird zum administrativen Albtraum (Auth-Tokens jonglieren).
• Begrenzter Lifecycle: Die Möglichkeiten, alte Images aufzuräumen (Garbage Collection), sind in ECR rudimentär und oft schwer zu debuggen.

Szenario B: Harbor mit Managed Kubernetes von ayedo

Im ayedo App-Katalog ist Harbor die Zentrale für Artefakte.

• Multi-Cloud Replikation: Harbor hat eine leistungsfähige Replikations-Engine. Es kann Images aktiv zu AWS ECR, Azure ACR, Google GCR oder anderen Harbor-Instanzen pushen und pullen. Harbor wird zum zentralen Hub, der alle Satelliten bedient.
• Datenhoheit: Die Images liegen auf Ihrem Storage (PVCs oder S3-Bucket Ihrer Wahl). Sie haben die volle Kontrolle.
• Robot Accounts: Harbor bietet ein hervorragendes System für Maschinen-User (CI/CD), die Tokens mit Ablaufdatum und engem Scope erhalten, ohne dass echte IAM-User angelegt werden müssen.

Technischer Vergleich der Betriebsmodelle

FAQ: Harbor & Supply Chain Strategy

Ist Harbor nur für Docker Images gedacht?

Nein. Harbor ist eine OCI-kompatible Registry. Das bedeutet, es kann alles speichern, was dem OCI-Standard entspricht: Docker Images, Helm Charts, Singularity Container und sogar andere Artefakte (via ORAS). Es dient somit als zentrales Repository für alle Kubernetes-Deployments.

Warum sollte ich Harbor nutzen, wenn ich nur auf AWS bin?

Selbst dann lohnt es sich wegen der Sicherheits-Features. ECR bietet zwar Scans via AWS Inspector, aber Harbor erlaubt es, Deployment-Policies durchzusetzen (“Lass den Pod nicht starten, wenn CVE > High”). Diese aktive Blockade-Funktion fehlt ECR weitgehend oder muss komplex über Admission Controller selbst gebaut werden.

Wie gehe ich mit riesigen Datenmengen um?

Container Registries wachsen schnell an. Harbor besitzt eine aggressive Garbage Collection. Sie können Regeln definieren wie “Behalte nur die letzten 5 Tags, die auf ‘prod-’ matchen, und lösche alles, was seit 30 Tagen nicht gepullt wurde”. Das hält den Speicherverbrauch und die Kosten niedrig.

Kann Harbor auch Images spiegeln (Mirroring)?

Ja. Das ist ein klassischer Use-Case für “Air-Gapped” oder Enterprise-Umgebungen. Harbor kann so konfiguriert werden, dass es nachts automatisch Images von einer externen Quelle zieht und lokal bereitstellt, damit Ihre Entwickler nicht auf das öffentliche Internet zugreifen müssen.

Fazit

Software-Sicherheit beginnt nicht erst im Cluster, sondern schon beim Image. AWS ECR ist ein guter Speicher, aber kein guter Wächter. Harbor schließt diese Lücke. Es kombiniert Speicherung mit Governance, Security-Scanning und intelligenter Verteilung. Mit dem ayedo Managed Stack erhalten Unternehmen eine Enterprise-Grade Registry, die sicherstellt, dass die Software-Lieferkette transparent, sicher und unabhängig von einem einzelnen Cloud-Anbieter bleibt.