Harbor: Robot Accounts und Scanning

Harbor ist mehr als ein Registry-Mirror. Wer es nur als “das Ding, wo die Docker-Images liegen” verwendet, lässt Features ungenutzt, die den Unterschied zwischen einer sicheren und einer unsicheren Supply Chain ausmachen können.

Robot Accounts: CI-Credentials ohne Karteileichen

Für CI/CD-Pipelines braucht es Credentials, um Images zu pushen und zu pullen. Der klassische Fehler: ein persönlicher Account wird in die Pipeline-Secrets kopiert. Zwei Jahre später verlässt die Person die Firma, der Account wird deaktiviert — und freitagnachmittags schlagen alle Builds fehl. Robot Accounts lösen genau das: nicht-menschliche Identitäten mit definierten Permissions, unabhängig von Personalfluktuation.

Harbor unterscheidet dabei zwei Ebenen. Projekt-Robots leben in einem einzelnen Projekt und sind der Normalfall: Der CI-Robot für das Payments-Team bekommt Push- und Pull-Rechte auf team-payments, sonst nichts. System-Robots können projektübergreifend berechtigt werden — sinnvoll für zentrale Tooling-Pipelines, aber sparsam einsetzen, denn ein geleakter System-Robot-Token ist ein deutlich größerer Schaden. Die Rechte sind feingranular (push, pull, delete, scan), und ein Expiry-Date ist konfigurierbar. Eine bewährte Praxis: Robots auf 90 Tage befristen und die Rotation in die Pipeline einbauen, statt -1 (nie ablaufend) zu setzen und zu hoffen.

Was in der Praxis schiefgeht: Der Robot-Token landet als Plaintext in einem Git-Repo oder in einer Jenkins-Konfiguration, die halb öffentlich ist. Robot Accounts schützen nicht vor schlechtem Secret-Handling — sie begrenzen nur den Blast Radius, wenn es passiert.

Scanning: Trivy ist eingebaut, die Policy musst du bauen

Harbor bringt Trivy als Standard-Scanner mit. Mit aktiviertem Scan on Push wird jedes Image direkt nach dem Upload gescannt, die CVE-Ergebnisse hängen am Artefakt und sind über UI und API abrufbar.

Interessant wird es bei den Konsequenzen. Harbor kann pro Projekt konfiguriert werden, dass Images ab einem Schweregrad nicht mehr gepullt werden dürfen (“Prevent vulnerable images from running”, z. B. ab Critical). Das ist ein harter Hebel — und genau deshalb mit Vorsicht zu aktivieren: Wenn über Nacht eine neue Critical-CVE in einem Basis-Image veröffentlicht wird, kann plötzlich kein Pod mehr neu starten, der dieses Image nutzt. Deshalb gehört zu dieser Policy zwingend eine CVE-Allowlist (pro Projekt oder systemweit), mit der bekannte, bewertete und akzeptierte CVEs ausgenommen werden, idealerweise mit Ablaufdatum.

Die Alternative bzw. Ergänzung: die Entscheidung in den Admission-Layer des Clusters verlagern, wo ein Webhook Scan-Ergebnisse und SBOMs prüft, bevor ein Deployment durchgeht. Wie das mit Trivy und Admission-Policies aussieht, steht in SBOM und Trivy in der Admission.

Für Signaturen integriert sich Harbor mit Cosign: Signaturen werden als Accessory neben dem Image im selben Repository gespeichert und wandern bei Replikation mit. Zusammen mit signierten Builds aus der Pipeline ergibt das eine nachvollziehbare Kette — mehr dazu in Cosign und SLSA.

Proxy Cache, Retention und die unspektakulären Gewinne

Proxy-Cache-Projekte sind ein unterschätztes Feature. Statt dass hunderte Pods direkt Docker Hub anfragen und gegen Rate-Limits laufen, zeigt der Cluster auf harbor.example.com/dockerhub-proxy/library/nginx, und Harbor zieht und cached das Image einmal. Das löst zwei Probleme gleichzeitig: Rate-Limiting und die Frage, welche externen Images überhaupt in der Umgebung landen — denn am Proxy-Projekt greifen dieselben Scan-Policies wie überall.

Retention Policies halten den Storage im Zaum. Eine typische Regel: die letzten zehn gepushten Artefakte pro Repository behalten, zusätzlich alles, was einem SemVer-Muster wie v*.*.* entspricht — und der Rest (CI-Tags wie sha-a1b2c3, pr-1234) wird nach 14 Tagen gelöscht. Ohne so eine Regel wächst eine aktiv genutzte Registry um etliche Gigabyte pro Woche, weil jede Pipeline jeden Commit pusht. Dazu passen Tag-Immutability-Regeln: v1.4.2 darf nach dem Push nicht überschrieben werden. Das klingt pedantisch, verhindert aber die Situation, dass “dasselbe Tag” auf zwei Clustern zwei verschiedene Images bedeutet.

Wer rootless baut — etwa mit Kaniko — pusht ohnehin direkt aus dem Build-Pod in die Registry; Harbor-Projektquoten verhindern dabei, dass ein einzelnes Team den Storage des gesamten Systems flutet.

Der ehrliche Teil: Betriebsaufwand

Harbor ist kein kleines Deployment. Core, Registry, Datenbank (PostgreSQL), Redis, Trivy-Adapter, Job-Service — das will überwacht, gesichert und upgegradet werden, und die Registry ist eine Komponente, deren Ausfall alle Deployments blockiert. Backup der Datenbank und des Object Storage gehört von Tag eins dazu. Für kleine Teams ohne Compliance-Druck ist eine Managed Registry (ECR, Artifact Registry) plus Trivy in der Pipeline oft die vernünftigere Wahl.

Die ehrliche Antwort im Interview lautet deshalb nicht “Harbor ist super”, sondern: Harbor lohnt sich, wenn man Scanning-Policies, Signatur-Verifikation, Proxy-Cache und Mandantentrennung als Plattform-Service anbieten will — und bereit ist, dafür eine kritische Komponente selbst zu betreiben. Wie das ins größere Bild passt, zeigt der Lernpfad Supply-Chain-Security.