Mandantenfähigkeit via OIDC und RBAC: Feingranulare Zugriffskontrolle in Enterprise-Registries

In der Anfangsphase von Container-Projekten ist die Welt meist noch einfach: Ein kleines Entwicklungsteam baut eine Handvoll Microservices, teilt sich einen gemeinsamen Zugang zur Container Registry und schiebt alle Images in ein großes, offenes Repository. Doch sobald die containerisierte Infrastruktur im Unternehmen wächst, mehrere Abteilungen parallel auf Clustern arbeiten oder externe Dienstleister und Agenturen in die CI/CD-Pipelines eingebunden werden, stößt dieses unregulierte Modell an gefährliche Grenzen.

Wenn alle Beteiligten alles sehen, modifizieren oder löschen dürfen, ist der nächste folgenschwere Konfigurationsfehler oder Sicherheitsvorfall nur eine Frage der Zeit. Enterprise-Umgebungen und stark regulierte Branchen (unter Vorgaben wie NIS-2 oder DORA) erfordern eine strikte, logische Trennung von Projekten und Teams, eine echte Mandantenfähigkeit (Multi-Tenancy). Die architektonische Herausforderung besteht darin, diese Isolation an der zentralen Container Registry abzubilden, ohne für jedes Team ein neues Datensilo aufzubauen. Das Werkzeug der Wahl ist die nahtlose Verschmelzung von OpenID Connect (OIDC) und rollenbasierter Zugriffskontrolle (RBAC) direkt auf Basis von Harbor.

Das Problem: Das “All-or-Nothing”-Dilemma beim Zugriff

Viele einfache oder proprietäre Registry-Dienste bieten oft nur eine sehr grobe Rechteverwaltung. Entweder authentifizieren sich alle Systeme über globale Administrator-Tokens, oder die Zugriffskontrolle wird komplett vernachlässigt.

Aus diesem Mangel an feingranularer Isolation ergeben sich in der Enterprise-Praxis drei gravierende Risiken:

1. Das Risiko des versehentlichen Überschreibens (Image Poisoning)

Wenn Team A (Finanzen) und Team B (Logistik) im selben unstrukturierten IP-Raum arbeiten, kann eine Fehlkonfiguration in der CI/CD-Pipeline von Team B dazu führen, dass ein Image von Team A unabsichtlich überschrieben wird. Da Kubernetes das veränderte Image beim nächsten Pod-Restart blind anfordert, kommt es in der Produktionsumgebung von Team A zu unvorhersehbaren Ausfällen.

2. Der unbefugte Abfluss von geistigem Eigentum (Data Leakage)

Externe Entwicklungsdienstleister benötigen für ihre Arbeit zwingend Zugriff auf die Registry, um Base-Images zu pushen. Besitzt die Registry keine echte Mandantenfähigkeit, können die externen Mitarbeiter im schlimmsten Fall auch die Repositories der internen Kernentwicklung einsehen und sensible Quellcodes oder proprietäre Algorithmen unbefugt kopieren.

3. Das “Token-Chaos” im Identity-Management

Müssen Passwörter und Zugangs-Tokens für die Registry manuell im Web-Interface des Anbieters angelegt, verteilt und regelmäßig rotiert werden, verliert die IT-Sicherheit schnell den Überblick. Verlässt ein Mitarbeiter das Unternehmen oder wird ein Dienstleister gekündigt, bleiben verwaiste Zugangsdaten oft monatelang in den Systemen aktiv, weil es keine zentrale Deaktivierung gibt.

Die Architektur der Isolation: Harbor-Projekte gesteuert durch OIDC

Eine souveräne und mandantenfähige Registry-Architektur bricht mit der manuellen Account-Verwaltung. Sie verlagert die Authentifizierung an den zentralen Identity Provider (IdP) des Unternehmens und setzt die Autorisierung über das logische Projekt-Konzept von Harbor durch.javascript [ Entwickler / CI/CD-Pipeline ] | v (Login-Anfrage via OIDC) [ Zentraler Identity Provider ] <— (Active Directory / Okta / Keycloak) | v (Ausstellung eines signierten JWT-Tokens inkl. Gruppen) [ Managed Harbor Container Registry ] | (Prüfung der RBAC-Rollen im Ziel-Projekt) | +—–+—–+ | | v v [ Projekt ‘Finanzen’ ] [ Projekt ‘Logistik’ ] (Nur Gruppe Finanzen) (Nur Gruppe Logistik)

1. Zentrale Authentifizierung via OIDC

Niemand loggt sich mehr mit einem lokalen Harbor-Passwort ein. Die Container Registry wird über OpenID Connect (OIDC) direkt an das führende Identitätssystem des Unternehmens gekoppelt (z. B. Keycloak, Okta, Microsoft Entra ID oder ein lokales Active Directory). Beim Login authentifiziert sich der Nutzer an diesem zentralen IdP. Harbor erhält nach erfolgreicher Prüfung ein kryptografisch signiertes JSON Web Token (JWT), welches nicht nur die Identität des Nutzers, sondern auch seine Gruppenzugehörigkeiten enthält.

2. Logische Isolation durch Harbor-Projekte

In Harbor ist jedes Repository zwingend einem Projekt zugewiesen (z. B. registry.ayedo.de/finanzen/api). Ein Projekt bildet die logische Isolationsgrenze. Jedes Projekt verfügt über eigene Speicher-Kontingente (Quotas), eigene Sicherheits-Policies für das CVE-Scanning und - am wichtigsten - über eine eigene, dedizierte RBAC-Tabelle.

3. Rollenbasierte Autorisierung (RBAC) in der Praxis

Anstatt Berechtigungen mühsam für jeden einzelnen Nutzer manuell zu konfigurieren, ordnet Harbor den via OIDC übermittelten Unternehmensgruppen feste Rollen innerhalb der Projekte zu. Harbor bietet hierfür standardisierte, feingranulare Rollen:

• Project Admin: Darf Repositories verwalten, Scanner-Policies definieren und Zugriffsrechte innerhalb des Projekts steuern.
• Developer: Besitzt volle Schreib- und Leserechte (push und pull), um Images im Projekt zu verwalten.
• Guest: Darf Images lediglich lesen (pull), aber keine Änderungen vornehmen, ideal für das Einbinden von Kubernetes-Clustern über imagePullSecrets.

Strategischer Mehrwert: Das Zero-Trust-Prinzip in der Lieferkette

Die konsequente Umsetzung von OIDC und RBAC an der Registry schafft die kaufmännische und technische Sicherheit, die moderne Cloud-Native-Plattformen benötigen:

• Zentraler “Kill-Switch” für die IT-Sicherheit: Scheidet ein Mitarbeiter aus oder wird eine Pipeline kompromittiert, genügt eine einzige Sperrung im zentralen Identity Provider. Der Zugriff auf die Container Registry erlischt im selben Sekundenbruchteil weltweit – ohne, dass Passwörter in Harbor angefasst werden müssen.
• Garantierte Mandatentrennung (Compliance-ready): Für Multi-Tenant-Umgebungen, in denen eine IT-Abteilung als interner Dienstleister für verschiedene Tochtergesellschaften fungiert, liefert das Projekt-Konzept den rechtssicheren Nachweis der Datentrennung nach DSGVO und ISO 27001.
• Sichere Automatisierung via Robot Accounts: Für CI/CD-Pipelines, die rein maschinell agieren müssen, nutzt Harbor sogenannte Robot Accounts. Diese kurzlebigen, präzise eingeschränkten Token-Verbindungen werden exakt für ein bestimmtes Projekt und eine definierte Aktion (z. B. nur push im Projekt logistik) ausgestellt. Sie verhindern, dass eine kompromittierte Pipeline das gesamte System gefährden kann.

Fazit: Identität ist die neue Netzwerkgrenze

Im modernen Enterprise-Betrieb ist die IP-Adresse als alleiniges Sicherheitsmerkmal längst überholt. Wahre Netzwerksicherheit und Ausfallsicherheit entstehen, wenn die Identität und die damit verknüpften Rechte unbestechlich an jeder Schnittstelle geprüft werden. Die Kombination aus OIDC-Zentralisierung und Harbors mächtigem RBAC-Projektmodell verwandelt die Container Registry von einem einfachen Ablageort in eine hochsichere, mandantenfähige Governance-Plattform. Sie gibt IT-Verantwortlichen die absolute Kontrolle darüber zurück, wer welchen Code in die Infrastruktur einbringt, und legt das unerschütterliche Fundament für eine lückenlos auditierbare Software-Lieferkette.

FAQ: RBAC & OIDC in der Praxis

Können wir trotz OIDC-Anbindung weiterhin Docker-CLI-Befehle auf der Kommandozeile nutzen?

Ja, absolut. Da die Docker-CLI und Tools wie containerd das interaktive OIDC-Loginverfahren (OAuth2-Web-Flows) auf der Kommandozeile nicht nativ unterstützen, bietet Harbor ein elegantes Feature namens CLI Secrets. Nach dem erfolgreichen Login über die Weboberfläche kann sich der Entwickler ein persönliches, langlebiges CLI-Passwort generieren lassen. Dieses nutzt er dann für den klassischen Befehl docker login. Alternativ und bevorzugt werden für CI/CD-Pipelines dedizierte Robot Accounts eingesetzt.

Was passiert mit den Rechten in Harbor, wenn sich eine Gruppenzugehörigkeit im Active Directory ändert?

Die Rechte werden dynamisch aktualisiert. Da Harbor bei jeder API-Anfrage das übermittelte OIDC-Token validiert und die darin enthaltenen Gruppen-Mitgliedschaften ausliest, greifen Änderungen im zentralen IdP sofort. Wird ein Mitarbeiter im Active Directory aus der Gruppe „Entwickler-Finanzen" entfernt, verliert er im selben Moment und ohne zeitliche Verzögerung seine Schreibrechte im Harbor-Projekt „Finanzen".

Unterstützt Harbor auch granulare Rechte für das Löschen von Images?

Ja. Über das RBAC-Modell lässt sich präzise steuern, wer das Recht besitzt, Container-Tags oder ganze Repositories physisch zu löschen. In der Praxis wird diese Berechtigung meist restriktiv vergeben (nur an Project Admins), um zu verhindern, dass Entwickler oder automatisierte Skripte im Eifer des Gefechts historische Image-Stände löschen, die von älteren, noch aktiven Pods im Kubernetes-Cluster benötigt werden.