Einheit 6.4: Container-Registrierung und Plattformauswahl

Einführung

Jede Container-Plattform benötigt einen vertrauenswürdigen Speicherort für Images und eine plausible Erklärung dafür, wer diese pushen und pullen kann. Bei IONOS bietet das Container-Registrierungssystem diesen Speicher, regelt jedoch den Zugriff auf eine Weise, die einen Architekten überraschen wird, der das rollenbasierte Modell der Hyperscaler-Registrierungssysteme erwartet: Der Zugriff erfolgt nur über Token, und die Disziplin, die Sie bei diesen Token anwenden, ist die gesamte Zugriffssteuerung. Diese Einheit etabliert zunächst das Governance-Modell und die Plattform-Auswahlentscheidung hinter jedem Container-Anwesen, und endet dann damit, ein Registrierungssystem zu erstellen, einen Token zu definieren und einen Client innerhalb des Data Center Designer anzumelden.

FinCorp, unser regulierter deutscher Fintech, richtet eine CI/CD-Pipeline ein, um seine neuen künstliche-Intelligenz-nahen Dienste auf Managed Kubernetes bereitzustellen. Das Registrierungssystem sitzt zwischen der Build-Farm und dem Cluster, sodass das Zugriffsmodell, das es auferlegt, eine Governance-Steuerung wird, die von FinCorps Auditoren geprüft wird. Die Plattform-Auswahlfrage läuft parallel dazu: FinCorp muss entscheiden, ob Managed Kubernetes seine Container-Workloads trägt oder ob eine kundenseitig bereitgestellte Distribution gerechtfertigt ist, und diese Entscheidung hängt ausschließlich davon ab, wer bereit ist, den Lebenszyklus der Steuerungsebene zu übernehmen.

1. Token-Only-Zugriff und Governance durch Token-Discipline

Das Container-Register verfügt über keine rollenbasierte Zugriffskontrolle. Es gibt keine Rollen, keine Benutzer, die auf Berechtigungen im Register abgebildet sind, und keine Richtliniensprache. Der Zugriff wird ausschließlich durch Register-Zugriffstoken gewährt, sodass die Sicherheitspostion des Registers genau der Disziplin entspricht, die Sie auf diese Token aufprägen. Ein Architekt, der von einem Register mit RBAC kommt, muss diese Inversion internalisieren: Sie weisen einem Prinzipal keine Rolle zu, sondern prägen ein Credential und begrenzen dessen Umfang.

Ein Token trägt einen Umfang, der aus drei Teilen aufgebaut ist. Der Typ ist entweder Registry, der es dem Token ermöglicht, die Repositorys im Register aufzulisten, oder Repository, der es dem Token ermöglicht, den Inhalt eines oder mehrerer benannter Repositorys zu verwalten. Der Pfad benennt die Repositorys, auf die der Token zugreift, wobei * ein Platzhalter ist, der den Zugriff auf alle Repositorys gewährt. Die Aktion ist eine oder mehrere von Pull, Push und Admin, wobei Admin es dem Token ermöglicht, Artefakte zu löschen. Ein push-fähiger Token muss auch pull-fähig sein: Wenn Sie Push auswählen, müssen Sie auch Pull festlegen. Es gibt keine pro-Repository-Zugriffskontrollliste jenseits dieser Token-Begrenzung; das Register bietet keine feineren ACLs auf ein einzelnes Repository als das Token-Modell ausdrückt.

Tokens gibt es in zwei Arten: ein permanentes Register-Zugriffstoken und ein temporäres Token, das ein Ablaufdatum trägt. Die Mindestlaufzeit, die Sie für ein temporäres Token festlegen können, beträgt eine Stunde. Das Geheimnis eines Tokens wird genau einmal bei der Erstellung angezeigt; wenn Sie es verlieren, können Sie es nicht wiederherstellen, sondern nur ersetzen. Ein Token hat drei Lebenszyklus-Zustände: enabled, disabled und deleted. Sie können ein Token deaktivieren, um es zu suspendieren, aber die sicherheitsrelevante Tatsache ist, was bei Ablauf passiert: Ein abgelaufenes Token wird gelöscht, nicht nur deaktiviert. Dies bedeutet, dass ein Ablauf ein harter Lebenszyklus-Endpunkt für das Credential ist und es keinen anonymen Zugriff und keine öffentliche Pull-Ebene gibt, auf die man zurückgreifen kann. Das Abrufen, wie das Pushen, erfordert immer ein gültiges Token.

Da das Register Ihnen nichts als Token gibt, ist die Governance die Token-Discipline, und die Disziplin ist konkret. Stellen Sie ein Token pro Pipeline-Stage bereit, anstatt ein gemeinsames Credential: Die Build-Stage, die Images pushen kann, erhält ein push- und pull-fähiges Token, das auf die Repositorys beschränkt ist, die es produziert, während die Deploy-Stage, die Images auf den Cluster pullt, ein pull-only-Token erhält. Begrenzen Sie jedes Token so eng wie die Stage es zulässt, und bevorzugen Sie ein Repository-Token auf einem benannten Pfad gegenüber einem Platzhalter. Legen Sie ein Ablaufdatum fest, das der beabsichtigten Lebensdauer des Credentials entspricht, und rotieren Sie es, indem Sie ein Ersatz-Token erstellen, bevor das alte abläuft, da das Ablaufdatum das Token löscht und eine nicht rotierte Pipeline einfach stoppt. Halten Sie diese Token vollständig aus persönlichen Credentials heraus; das Token-Modell existiert genau dazu, dass CI/CD nie als Person authentifiziert wird. Für FinCorp entspricht dies sauber den Erwartungen seiner Prüfer: Jede Pipeline-Stage hält ein distinctes, eng begrenztes, ablaufendes Credential, und das Fehlen langfristiger gemeinsamer Geheimnisse ist aus der Token-Liste ableitbar.

Das Register ist verschlüsselt bei REST und veröffentlicht eine 99,95%-pro-Service-Uptime-SLA. Es ist derzeit in der Frankfurt (DE/FRA)-Lokation verfügbar, und sowohl der Register-Name als auch dessen Lokation sind nach der Erstellung unveränderlich, sodass die Lokation eine Platzierungsentscheidung ist, die einmal getroffen wird. Der Register-Name muss zusätzlich global eindeutig sein über alle Kunden hinweg, darf nur alphanumerische Zeichen und Bindestriche enthalten, muss zwischen 3 und 63 Zeichen lang sein, muss mit einem Buchstaben a-z beginnen und mit einem alphanumerischen Zeichen enden.

2. Schwachstellen-Scanning als einwegiger Umschalter

Schwachstellen-Scanning ist eine Add-on-Funktion, die die Software in Ihren Container-Bildern gegen bekannte Common Vulnerabilities and Exposures (CVEs) analysiert. Ein Scan wird jedes Mal durchgeführt, wenn ein Artefakt hochgeladen wird, und erneut, wenn neue Schwachstellen-Definitionen veröffentlicht werden, sodass die Abdeckung sowohl Ihre Bild-Fluktuation als auch das sich entwickelnde CVE-Verzeichnis verfolgt, mit einem erneuten Scan-Fenster von 30 Tagen. Die Ergebnisse liefern pro-Artefakt-CVE-Details, die Sie in ein CI/CD-Tor einbinden können, was für einen regulierten Shop wie FinCorp von Wert ist, der seine Sorgfaltspflicht in der Lieferkette nachweisen muss.

Das architektonische Detail, das wichtig ist, ist die Irreversibilität. Sobald Schwachstellen-Scanning in einem Register aktiviert ist, kann es später nicht mehr deaktiviert werden. Die Aktivierung ist daher eine bewusste, einwegige Entscheidung und kein Setting, das für einen Test aktiviert und später wieder deaktiviert wird. Behandeln Sie es als eine Eigenschaft, die Sie für die Lebensdauer des Registers verpflichten, und entscheiden Sie sich bewusst bei oder nach der Erstellung, anstatt die Einschränkung zu entdecken, wenn Sie versuchen, es rückgängig zu machen. Für FinCorp ist die Entscheidung einfach, das Scanning bleibt aktiviert, aber der Architekt sollte es dennoch als unwiderrufliche Verpflichtung aufzeichnen.

3. Plattformauswahl: Wer trägt die Control-Plane-Lifecycle-Last

Die Container-Plattformentscheidung bei IONOS dreht sich im Grunde darum, wer die Kubernetes-Control-Ebene und ihre Compliance-Last besitzt, und nicht um die Funktionsparität zwischen Distributionen. Drei Optionen sitzen auf dem gleichen IONOS-Computing- und Speicher-Substrat, aber unterscheiden sich scharf in ihrem Betriebsmodell.

Die folgende Tabelle fasst die drei Optionen und die Lifecycle- und Compliance-Last zusammen.

Managed Kubernetes ist die Standardoption. IONOS betreibt die Control-Ebene und stellt sie kostenlos zur Verfügung, während Sie nur für die Node Pools bezahlen. Der Lifecycle der Control-Ebene, ihre Upgrades, ihre Verfügbarkeit, ist IONOS' Verantwortung unter einer 99,95% pro Service-SLA. Bei der Compliance fällt Managed Kubernetes unter den BSI-IT-Grundschutz (ISO 27001)-Zertifizierungsumfang in deutschen Rechenzentren, aber es liegt nicht im BSI-C5-Attestierungsumfang. Dies ist die pro-Service-Compliance-Präzision, die die Plattform erfordert: Sie können nicht sagen, "die Cluster ist C5", weil die C5-Typ-1-Attestierung (erteilt am 2023-11-07) Compute Engine, Cloud Cubes und S3 Object Storage abdeckt, nicht jedoch Managed Kubernetes.

Red Hat OpenShift ist kein verwaltetes IONOS-Service. IONOS bietet keine verwaltete OpenShift-Lösung an und verkauft oder berechnet keine OpenShift-Abonnements. Stattdessen haben IONOS und Red Hat gemeinsam OpenShift auf IONOS-Infrastruktur validiert und eine Referenzimplementierung für Red Hat-zertifizierte Cloud-Service-Provider-Partner (CCSP) erstellt. Der Kunde (der CCSP-Partner) deployt und verwaltet seine eigenen Cluster und besitzt daher den gesamten Control-Plane-Lifecycle. Die Lizenzierung erfolgt über Bring-Your-Own-Lizenz, wobei Abonnements von Red Hat oder einem Distributor bezogen werden; die zugrunde liegenden IONOS-Ressourcen werden zum regulären Preis berechnet, ohne OpenShift-spezifische Zuschläge. Bevor OpenShift in der Produktion ausgeführt wird, müssen Partner eine Red Hat-Validierung über einen IONOS-Cloud-Vertreter planen, der die Überprüfung koordiniert, um zu bestätigen, dass die Implementierung die Produktionsanforderungen von Red Hat erfüllt. Wählen Sie diesen Weg nur, wenn die OpenShift-Plattform selbst eine harte Anforderung ist und Sie bereit sind, ihren Betrieb zu übernehmen.

SUSE Rancher Prime folgt einem selbstverwalteten Bereitstellungsmodell auf IONOS. IONOS bietet Rancher Prime nicht als verwalteten Service an: Der Kunde ist für den gesamten Lifecycle der Rancher-Prime-Umgebung verantwortlich, einschließlich Installation, Skalierung und laufender Wartung des Management-Servers sowie der Konfiguration und Verwaltung der nachgelagerten Cluster-Landschaften. Das kommerzielle Modell ist Bring-Your-Own-Abonnement, wobei IONOS die Infrastruktur (Compute Engine, Block Storage, Netzwerk) zu Standardraten berechnet und SUSE (oder der SUSE-Distributor des Kunden) die Rancher-Prime- und SUSE-Linux-Enterprise-Server-Lizenzen berechnet, ohne versteckte Integrationgebühren von IONOS. Die Partnerschaft ist für souveräne, DACH-Region-Kubernetes-Verwaltung mit Ausrichtungen auf BSI-IT-Grundschutz, NIS2, EU-GDPR und EU-Lieferkettenanforderungen positioniert; die operative Einschränkung ist, dass Sie, nicht IONOS, die Management-Ebene betreiben. Die frühere Darstellung von Rancher Prime als SUSE-betriebener verwalteter Service gilt nicht: SUSE liefert das Abonnement und die Unterstützung, aber der Kunde betreibt die Plattform.

Die ehrliche Zusammenfassung für FinCorp: Die kundenbereitgestellten Optionen tauschen den Komfort einer verwalteten Control-Ebene gegen distributionspezifische Fähigkeiten ein und übertragen dabei den Control-Plane-Lifecycle und den Großteil der Compliance-Last auf die eigenen Teams von FinCorp. Sofern OpenShift oder Rancher nicht eine ausdrückliche Anforderung ist, ist Managed Kubernetes die wählbare Option mit geringerer Last, die bereits im IT-Grundschutz-Umfang liegt.

Eine Grenze, die für alle drei Optionen gilt: Wo Attestierungen und Zertifizierungen die IONOS-Infrastrukturschicht abdecken, decken sie nur diese Schicht ab, nicht die Kunden-Workloads, die auf der Cluster laufen. Eine Cluster, die auf attestierte Infrastruktur sitzt, macht die Anwendung darauf nicht kompatibel; Workload-Compliance bleibt die Verantwortung des Kunden, unabhängig davon, welche Distribution die Control-Ebene betreibt.

3.1 Multi-Cluster versus Namespace-Isolation

Innerhalb der Plattform, die Sie wählen, ist die Trennung von Workloads eine zweistufige Entscheidung. Namespace-Isolation teilt eine einzelne Cluster logisch: Mieter teilen die gleiche Control-Ebene und Node Pools, und Sie erzwingen Trennung mit in-Cluster-Netzwerkrichtlinien und Ressourcenquoten. Es ist die günstigere, dichtere Option und die richtige Standardoption für Umgebungen, die eine Vertrauens- und Compliance-Grenze teilen, zum Beispiel mehrere interne Entwicklungsteams von FinCorp.

Multi-Cluster-Isolation setzt Workloads in separate Cluster, gibt jedem seine eigene Control-Ebene und eine harte Blast-Radius-Grenze. Es ist die stärkere Trennung und die, die Sie wählen sollten, wenn Workloads in verschiedenen Compliance-Umfängen liegen, wenn ein lauter oder feindseliger Nachbar inakzeptabel ist oder wenn ein Upgrade oder ein Ausfall nicht zwischen Mieter übergehen darf. Auf Managed Kubernetes ist die Kosten für die Wahl von Multi-Cluster frei begrenzt durch eine pro-Vertrag-Cluster-Quota (eine Standardoption, die auf Anfrage durch IONOS-Cloud-Support erhöht werden kann), sodass ein Anwesen, das viele hart isolierte Mieter benötigt, um diese Decke planen muss, möglicherweise durch Aufteilung über Verträge (der Vertrag ist die Governance-Grenze, die in Modul 2 etabliert wurde). FinCorps Muster ist, seine regulierten Produktions-Workload in seinem eigenen Cluster zu halten, isoliert von der geteilten Entwicklung-Cluster, genau damit der Produktions-Compliance-Umfang nicht mit der Entwicklungsdynamik verquickt wird.

DCD Implementierung Schritt-für-Schritt

Sie werden ein Container-Register erstellen, Vulnerabilitätsscanning aktivieren, ein eng gefasstes Token erstellen und einen Docker-Client authentifizieren. Dies realisiert das Zugriffsmodell aus Abschnitt 1: Ein einzelnes Register, dessen einzige Zugriffsoberfläche ein Satz von begrenzten, ablaufenden Token ist, bereit, um FinCorps Pipeline zu unterstützen. Die einzige Voraussetzung ist ein Vertragsbenutzer mit der Berechtigung, das Register zu erstellen.

Ziel: Ein Register erstellen, ein Token ausstellen, einen Client authentifizieren.

Schritte (im Data Center Designer):

1. Gehen Sie zu Menü > Container > Container-Register, um den Container-Register-Manager zu öffnen.
2. Klicken Sie auf Ein Register hinzufügen. Geben Sie einen Namen ein. Beachten Sie, dass der Name permanent und global eindeutig ist, nur alphanumerische Zeichen und Bindestriche enthält, 3 bis 63 Zeichen lang ist und mit einem Buchstaben beginnt und alphanumerisch endet.
3. Wählen Sie den Standort aus der Dropdown-Liste. Dieser ist nach der Erstellung nicht mehr änderbar, und das Register ist im Standort Frankfurt (DE/FRA) verfügbar. Wählen Sie ihn bewusst aus.
4. Konfigurieren Sie optional den Zeitplan für die Müllsammlung, indem Sie die Tag(e) und Uhrzeit (UTC) für den wöchentlichen Lauf auswählen, der den Speicherplatz freigibt, der von nicht referenzierten Bildschichten belegt wird. Die Müllsammlung ist standardmäßig deaktiviert; beachten Sie, dass das Register während des Laufs schreibgeschützt ist, also legen Sie das Zeitfenster außerhalb der Hauptlast.
5. Entscheiden Sie sich für Vulnerabilitätsscanning. Sie können es hier aktivieren, aber sobald es aktiviert ist, kann es nicht mehr deaktiviert werden, also behandeln Sie die Aktivierung als einseitige Verpflichtung. (Sie können es auch später einem bestehenden Register über den Abschnitt Eigenschaften hinzufügen, wo dieselbe Irreversibilität gilt.)
6. Klicken Sie auf Register hinzufügen. Das Register und sein Speicher werden erstellt; es ist bereit zur Verwendung, wenn sein Status Wird ausgeführt erreicht. Der Register-Hostname wird nur einmal zugewiesen, wenn er den Status Wird ausgeführt erreicht.
7. Wählen Sie das ausgeführte Register und öffnen Sie den Token-Reiter, dann klicken Sie auf Token hinzufügen. Geben Sie dem Token einen Namen (der auch später nicht mehr geändert werden kann).
8. Definieren Sie den Token-Umfang: Legen Sie den Typ fest (Registry, um Repositorys aufzulisten, oder Repository, um Repository-Inhalte zu verwalten), geben Sie den Pfad der Repositorys ein, die es erreicht (vermeiden Sie das *-Wildcard, es sei denn, die Stufe benötigt tatsächlich jedes Repository), und wählen Sie die Aktion(en). Für ein Build-Stage-Push-Token wählen Sie Push und, da Push dies erfordert, auch Pull. Für ein optionales Ablaufdatum legen Sie ein Ablaufdatum fest, das nicht kürzer als eine Stunde ist. Speichern Sie den Token und kopieren Sie sein Geheimnis jetzt: Es wird nur einmal angezeigt.
9. Authentifizieren Sie einen Client. Verwenden Sie die Docker-CLI, um sich mit dem Token als Anmeldeinformationen beim Register-Hostname anzumelden:

docker login {registry-name}.cr.de-fra.ionos.com
## Username and Password: supply the token credentials (not a personal login)

Der Client kann nun innerhalb des Gültigkeitsbereichs des Tokens pushen und pullen. Der architektonische Punkt ist, dass dies der einzige Authentifizierungspfad ist: Es gibt keinen anonymen Pull, sodass sogar der Lesezugriff über ein gültigkeitsbereichsbezogenes Token erfolgt.

Häufige Fehler:

• Die Behandlung von Vulnerabilitätsscans als umkehrbar. Es handelt sich um einen einwegigen Umschalter; sobald er aktiviert ist, kann er nicht mehr deaktiviert werden. Entscheiden Sie sich, bevor Sie ihn aktivieren.
• Die Erwartung, ein abgelaufenes Token deaktivieren zu können. Das Ablaufdatum löscht das Token, es deaktiviert es nicht, sodass ein nicht rotierter Pipeline-Benutzernamen verschwindet und die Pipeline zusammenbricht. Rotieren Sie durch Erstellen eines Ersatzes vor dem Ablaufdatum.
• Der Versuch, ein verlorenes Token-Geheimnis wiederherzustellen. Das Geheimnis wird genau einmal bei der Erstellung angezeigt; wenn es verloren geht, müssen Sie ein neues Token erstellen.
• Die Gewährung von Push ohne Pull. Ein Token, das Push-Vorgänge ausführen kann, muss auch Pull-Vorgänge ausführen können, sonst schlägt der Push-Vorgang fehl.
• Die Verwendung eines *-Wildcards oder eines einzelnen gemeinsam genutzten Tokens für alle Stufen. Stellen Sie ein eng gefasstes Token pro Pipeline-Stufe aus; das Register hat kein RBAC, sodass der Gültigkeitsbereich des Tokens Ihre einzige Zugriffskontrolle ist.
• Die Annahme, dass Sie das Register später umbenennen oder umziehen können. Sowohl der Name als auch der Speicherort sind unveränderlich; die Wahl des falschen Speicherorts bedeutet, dass Sie das Register neu erstellen müssen.
• Die Abhängigkeit von einer öffentlichen Pull-Ebene für Basisimages. Es gibt keinen anonymen Zugriff und keine öffentliche Pull-Ebene; jeder Pull-Vorgang benötigt ein Token.

Zusammenfassung

Das IONOS Container-Register regelt den Zugriff durch begrenzte, ablaufende Token und nicht durch rollenbasierte Zugriffskontrolle, sodass die Sicherheit des Registers genau der Disziplin entspricht, die auf seine Token angewendet wird: eines pro Pipeline-Phase, eng umgrenzt, ablaufend, durch Ersetzung rotiert und aus persönlichen Anmeldeinformationen herausgehalten. Schwachstellen-Scanning ist ein wertvolles, aber irreversible Add-on, und der Name und der Standort des Registers sind permanent. Die Entscheidung über die Plattform-Auswahl hängt davon ab, wer den Lebenszyklus der Steuerungsebene und die Compliance-Last besitzt: Managed Kubernetes hält beides innerhalb des IT-Grundschutz-Bereichs bei IONOS, während OpenShift und Rancher Prime kundenseitig bereitgestellt werden und diese Eigentümerschaft auf den Kunden übertragen. Separate Workloads mit Namespaces, wenn sie eine Vertrauensgrenze teilen, und mit mehreren Clustern, wenn sie eine harte Grenze benötigen, innerhalb des vertraglichen Cluster-Limits.

Wichtige Punkte:

• Das Container-Register hat keine RBAC; der Zugriff erfolgt nur über Token, ohne anonymen Zugriff und ohne öffentliches Pull-Level. Die Governance erfolgt durch Token-Disziplin.
• Der Token-Umfang umfasst den Typ (Register oder Repository) plus Pfad plus Aktion (Pull/Push/Admin); Push erfordert Pull, und das Token-Geheimnis wird nur einmal angezeigt.
• Token werden bei Ablauf gelöscht, nicht deaktiviert; rotieren Sie durch Ausstellen eines Ersatzes vor Ablauf. Die Mindestlaufzeit beträgt eine Stunde.
• Schwachstellen-Scanning ist ein einwegiger Schalter: einmal aktiviert, kann es nicht deaktiviert werden. Der Name und der Standort des Registers sind unveränderlich.
• Managed Kubernetes hält den Lebenszyklus der Steuerungsebene und die Compliance mit IONOS (IT-Grundschutz, nicht C5); OpenShift (CCSP, BYOL) und Rancher Prime (selbstverwaltet, BYOS) werden kundenseitig bereitgestellt und übertragen diese Last auf den Kunden.
• Atteste umfassen nur die IONOS-Infrastruktur-Ebene, nie die Workloads des Kunden auf dem Cluster.
• Verwenden Sie Namespaces für weiche, geteilte Grenzen und mehrere Cluster für harte Trennung, innerhalb Ihres vertraglichen Cluster-Kontingents (erhöhen auf Anfrage).

Wichtige Begriffe:

• Register-Zugriffstoken: die alleinige Zugriffsberechtigung für das Container-Register, umgrenzt durch Typ, Pfad und Aktion; permanent oder temporär (mit einer Ablaufzeit, die es am Ende seines Lebenszyklus löscht).
• Schwachstellen-Scanning: ein irreversibles Add-on, das die gepushten Artefakte gegen bekannte CVEs überprüft und bei Veröffentlichung neuer Definitionen erneut überprüft.
• CCSP (Zertifizierter Cloud-Service-Provider): die Red Hat-Partnerrolle, unter der OpenShift auf validierter IONOS-Infrastruktur kundenseitig bereitgestellt wird, anstatt als gemanagter IONOS-Service angeboten zu werden.
• BYOS (Bring Your Own Subscription): das SUSE-Rancher-Prime-Modell, bei dem IONOS die Infrastruktur und SUSE die Lizenzen in Rechnung stellt, wobei der Kunde die Plattform selbst verwaltet.