Einheit 6.4: Container Registry und Plattformauswahl

Einführung

Jede Container-Plattform benötigt einen vertrauenswürdigen Ort zur Speicherung von Images sowie eine nachvollziehbare Begründung dafür, wer diese Images hochladen und abrufen darf. Auf IONOS CLOUD stellt die Container Registry diesen Speicher bereit, regelt den Zugriff jedoch auf eine Weise, die einen Architekten überraschen dürfte, der das bei Hyperscaler-Registries übliche rollenbasierte Modell erwartet: Der Zugriff erfolgt ausschließlich über Tokens, und die Disziplin, die Sie bei der Verwaltung dieser Tokens anwenden, bildet die gesamte Grundlage Ihrer Zugriffskontrolle. Diese Einheit legt zunächst dieses Governance-Modell sowie die Entscheidung zur Plattformauswahl zugrunde, die jeder Container-Landschaft zugrunde liegt. Anschließend wird eine Registry erstellt, ein Token mit einem bestimmten Geltungsbereich versehen und ein Client im Data Center Designer angemeldet.

FinCorp, unser reguliertes deutsches Fintech-Unternehmen, richtet eine CI/CD-Pipeline ein, um seine neuen, KI-nahen Dienste auf Managed Kubernetes bereitzustellen. Die Registry befindet sich zwischen der Build-Umgebung und dem Cluster, sodass das von ihr vorgegebene Zugriffsmodell eine Governance-Kontrolle darstellt, die die Prüfer von FinCorp untersuchen werden. Parallel dazu stellt sich die Frage der Plattformauswahl: FinCorp muss entscheiden, ob Managed Kubernetes seine Container-Workloads trägt oder ob eine kundenseitig eingesetzte Distribution gerechtfertigt ist. Diese Entscheidung hängt ausschließlich davon ab, wer bereit ist, den Lebenszyklus der Control Plane zu verantworten.

1. Token-basierter Zugriff und Governance durch Token-Disziplin

Die Container Registry bietet keine rollenbasierte Zugriffskontrolle. Es gibt keine Rollen, keine Benutzern, die Berechtigungen innerhalb der Registry zugeordnet sind, und keine Policy-Sprache. Der Zugriff wird ausschließlich über Registry-Zugriffstokens gewährt, sodass die Sicherheitslage der Registry genau der Disziplin entspricht, die Sie für diese Tokens festlegen. Ein Architekt, der aus einer Registry mit RBAC kommt, muss diese Umkehrung verinnerlichen: Sie weisen einem Principal keine Rolle zu, sondern Sie erstellen eine Berechtigung und legen deren Geltungsbereich fest.

Ein Token trägt einen Geltungsbereich, der aus drei Teilen besteht. Der Typ ist entweder Registry, der es dem Token ermöglicht, die Repositories in der Registry aufzulisten, oder Repository, der es dem Token ermöglicht, den Inhalt eines oder mehrerer benannter Repositories zu verwalten. Der Pfad benennt die Repositories, auf die das Token zugreifen kann, wobei * ein Platzhalter ist, der Zugriff auf alle Repositories gewährt. Die Aktion ist eine oder mehrere von Pull, Push und Admin, wobei Admin dem Token das Löschen von Artefakten erlaubt. Ein Token mit Push-Fähigkeit muss auch Pull enthalten: Wenn Sie Push auswählen, müssen Sie auch Pull festlegen. Es gibt keine Zugriffskontrollliste pro Repository, die über dieses Token-Scoping hinausgeht; die Registry bietet keine feineren ACLs für ein einzelnes Repository, als das Token-Modell ausdrückt.

Tokens gibt es in zwei Arten: ein permanentes Registry-Zugriffstoken und ein temporäres Token, das ein Ablaufdatum trägt. Das minimale Ablaufdatum, das 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 das Token ersetzen. Ein Token hat drei Lebenszyklus-Zustände: enabled, disabled und deleted. Sie können ein Token deaktivieren, um es auszusetzen, aber die sicherheitsrelevante Tatsache ist, was bei Ablauf geschieht: ein abgelaufenes Token wird gelöscht, nicht merely deaktiviert. Das bedeutet, dass ein Ablauf ein hartes Lebensende für die Berechtigung ist, und es gibt keinen anonymen Zugriff und keine öffentliche Pull-Ebene, auf die man zurückgreifen kann. Das Ziehen, wie das Schieben, erfordert immer ein gültiges Token.

Da die Registry Ihnen nichts als Tokens bietet, ist Governance Token-Disziplin, und die Disziplin ist konkret. Erstellen Sie ein Token pro Pipeline-Stufe, statt eine geteilte Berechtigung zu verwenden: Die Build-Stufe, die Images pusht, erhält ein Push-und-Pull-Token, das auf die Repositories beschränkt ist, die sie erzeugt, während die Deploy-Stufe, die Images auf den Cluster zieht, ein nur-Pull-Token erhält. Beschränken Sie jedes Token so eng wie die Stufe es zulässt, wobei Sie einem Repository-Typ-Token auf einem benannten Pfad gegenüber einem Platzhalter den Vorzug geben. Legen Sie ein Ablaufdatum fest, das der beabsichtigten Lebensdauer der Berechtigung entspricht, und rotieren Sie, indem Sie vor Ablauf des alten Tokens ein Ersatztoken erstellen, da Ablauf das Token vollständig löscht und eine nicht rotierte Pipeline einfach stoppt. Halten Sie diese Tokens vollständig aus persönlichen Berechtigungen heraus; das Token-Modell existiert genau dafür, dass CI/CD sich nie als Person authentifiziert. Für FinCorp entspricht dies sauber den Erwartungen seiner Prüfer: Jede Pipeline-Stufe hält eine eindeutige, eng beschränkte, ablaufende Berechtigung, und das Fehlen langlebiger geteilter Geheimnisse ist aus der Token-Liste nachweisbar.

Die Registry ist bei der Ruhe verschlüsselt und veröffentlicht eine SLA für die Verfügbarkeit pro Dienst von 99,95 %. Sie ist derzeit an dem Standort Frankfurt (DE/FRA) verfügbar, und sowohl der Registry-Name als auch sein Standort sind nach der Erstellung unveränderlich, sodass der Standort eine einmal getroffene Platzierungsentscheidung ist. Der Registry-Name muss zusätzlich global eindeutig über alle Kunden hinweg sein, nur alphanumerische Zeichen und Gedankenstriche enthalten, zwischen 3 und 63 Zeichen lang sein, mit einem Buchstaben a-z beginnen und mit einem alphanumerischen Zeichen enden.

2. Schwachstellen-Scanning als Einweg-Schalter

Das Schwachstellen-Scanning ist eine Zusatzfunktion, die die Software in Ihren Container-Images mit bekannten Common Vulnerabilities and Exposures (CVEs) abgleicht. Ein Scan wird jedes Mal ausgeführt, wenn ein Artefakt hochgeladen wird, sowie erneut, wenn neue Schwachstellen-Definitionen veröffentlicht werden. Dadurch deckt die Funktion sowohl den Turnover Ihrer Images als auch den sich entwickelnden CVE-Katalog ab, mit einem erneuten Scan-Fenster von 30 Tagen. Die Ergebnisse liefern CVE-Details pro Artefakt, die Sie in ein CI/CD-Gate einbinden können. Dies ist der Mehrwert für ein reguliertes Unternehmen wie FinCorp, das Sorgfaltspflichten in seiner Lieferkette nachweisen muss.

Das architektonische Detail, das hier entscheidend ist, ist die Irreversibilität. Sobald das Schwachstellen-Scanning in einem Registry aktiviert wurde, kann es später nicht mehr deaktiviert werden. Die Aktivierung ist daher eine bewusste, einseitige Entscheidung und keine Einstellung, die man für einen Test einschaltet und danach wieder ausschaltet. Behandeln Sie sie als eine Eigenschaft, der Sie sich für die gesamte Lebensdauer des Registry verpflichten, und treffen Sie diese Entscheidung bewusst bei oder nach der Erstellung, anstatt die Einschränkung erst zu entdecken, wenn Sie versuchen, sie rückgängig zu machen. Für FinCorp ist die Entscheidung eindeutig: Das Scanning bleibt aktiviert. Der Architekt sollte sie jedoch dennoch als irreversible Verpflichtung dokumentieren.

3. Plattformauswahl: Wer trägt den Lebenszyklus der Steuerungsebene

Die Entscheidung für eine Container-Plattform auf IONOS CLOUD dreht sich im Kern darum, wer die Verantwortung für die Kubernetes-Steuerungsebene und deren Compliance-Last trägt, nicht um die Funktionsgleichheit zwischen verschiedenen Distributionen. Drei Optionen basieren auf demselben Compute- und Storage-Substrat von IONOS CLOUD, unterscheiden sich jedoch deutlich in ihrem Betriebsmodell.

Die folgende Tabelle fasst die drei Optionen zusammen und zeigt, wo die Verantwortung für den Lebenszyklus und die Compliance-Last liegt.

Managed Kubernetes ist die Standardoption. IONOS CLOUD betreibt die Steuerungsebene und stellt sie kostenlos bereit, während Sie nur für die Node-Pools zahlen. Der Lebenszyklus der Steuerungsebene, deren Upgrades und deren Verfügbarkeit liegen in der Verantwortung von IONOS CLOUD gemäß einem SLA von 99,95 % pro Dienst. In puncto Compliance fällt Managed Kubernetes unter den Zertifizierungsbereich des BSI IT-Grundschutzes (ISO 27001) in deutschen Rechenzentren, gehört jedoch nicht zum Geltungsbereich der BSI C5-Zertifizierung. Dies ist die präzise, dienstbezogene Compliance-Differenzierung, die die Plattform erfordert: Man kann nicht einfach sagen, „das Cluster ist C5“, da die C5 Type 1-Zertifizierung (verliehen am 2023-11-07) Compute Engine, Cloud Cubes und S3 Object Storage abdeckt, nicht jedoch Managed Kubernetes.

Red Hat OpenShift ist kein verwalteter Dienst von IONOS CLOUD. IONOS CLOUD bietet keine verwaltete OpenShift-Lösung an und verkauft oder berechnet keine OpenShift-Abonnements. Stattdessen haben IONOS CLOUD und Red Hat OpenShift, das auf der Infrastruktur von IONOS CLOUD läuft, gemeinsam validiert und eine Referenzimplementierung für Red Hat Certified Cloud Service Provider (CCSP)-Partner erstellt. Der Kunde (der CCSP-Partner) deployt und verwaltet seine eigenen Cluster und trägt daher die gesamte Verantwortung für den Lebenszyklus der Steuerungsebene. Die Lizenzierung erfolgt nach dem Bring-Your-Own-License-Prinzip, wobei die Abonnements von Red Hat oder einem einzelnen Distributor bezogen werden; die zugrunde liegenden Ressourcen von IONOS CLOUD werden zum regulären Preisverzeichnis abgerechnet, ohne einen OpenShift-spezifischen Aufschlag. Vor dem Betrieb von OpenShift in der Produktion müssen Partner eine Red Hat-Validierung über einen IONOS CLOUD-Vertreter vereinbaren, der die Überprüfung koordiniert, die bestätigt, dass die Deployment-Anforderungen den Produktionsanforderungen von Red Hat entsprechen. Wählen Sie diesen Weg nur dann, wenn die OpenShift-Plattform selbst eine zwingende Voraussetzung ist und Sie bereit sind, deren Betrieb zu übernehmen.

SUSE Rancher Prime folgt einem selbstverwalteten Deployment-Modell auf IONOS CLOUD. IONOS CLOUD bietet Rancher Prime nicht als verwalteten Dienst an: Der Kunde ist für den gesamten Lebenszyklus der Rancher Prime-Umgebung verantwortlich, einschließlich Installation, Skalierung und laufender Wartung des Management-Servers, sowie für die Konfiguration und Verwaltung der nachgelagerten Cluster-Landschaften. Das Geschäftsmodell basiert auf Bring-Your-Own-Subscription, wobei IONOS CLOUD die Infrastruktur (Compute Engine, Block Storage, Netzwerk) zu Standardtarifen abrechnet und SUSE (oder der SUSE-Distributor des Kunden) die Lizenzen für Rancher Prime und SUSE Linux Enterprise Server abrechnet, ohne versteckte Integrationskosten seitens IONOS CLOUD. Die Partnerschaft ist auf souveränes Kubernetes-Management in der DACH-Region ausgerichtet, mit Übereinstimmungen zu BSI IT-Grundschutz, NIS2, EU-DSGVO und EU-Anforderungen an die Lieferkette; der operative Vorbehalt besteht darin, dass Sie, nicht IONOS CLOUD, die Management-Ebene betreiben. Die frühere Darstellung von Rancher Prime als von SUSE betriebener verwalteter Dienst trifft nicht zu: SUSE liefert das Abonnement und den Support, aber der Kunde betreibt die Plattform.

Die ehrliche Zusammenfassung für FinCorp: Die kundenseitig deployeden Optionen taugen die Bequemlichkeit einer verwalteten Steuerungsebene gegen distributionsspezifische Funktionen ein und übertragen dabei den Lebenszyklus der Steuerungsebene sowie den Großteil der Compliance-Last auf die eigenen Teams von FinCorp. Sofern OpenShift oder Rancher keine ausdrückliche Anforderung sind, ist Managed Kubernetes die belastungsgünstigere, von IONOS CLOUD unterstützte Wahl, die bereits im Geltungsbereich des IT-Grundschutzes liegt.

Eine Grenze, die für alle drei gilt: Wo Zertifizierungen und Zertifikate die Infrastrukturschicht von IONOS CLOUD abdecken, decken sie nur diese Schicht ab, nicht die Workloads des Kunden, die auf dem Cluster laufen. Ein Cluster auf zertifizierter Infrastruktur macht die darauf laufende Anwendung nicht automatisch compliant; die Compliance der Workloads bleibt unabhängig von der Distribution, die die Steuerungsebene betreibt, in der Verantwortung des Kunden.

3.1 Multi-Cluster versus Namespace-Isolation

Innerhalb der gewählten Plattform ist die Trennung von Workloads eine zweistufige Entscheidung. Namespace-Isolation unterteilt ein einzelnes Cluster logisch: Tenant teilen sich dieselbe Steuerungsebene und dieselben Node-Pools, und Sie erzwingen die Trennung durch In-Cluster-Netzwerkrichtlinien und Ressourcenquoten. Dies ist die kostengünstigere, dichtere Option und der richtige Standard für Umgebungen, die eine gemeinsame Vertrauens- und Compliance-Grenze teilen, beispielsweise mehrere interne Entwicklungsteams von FinCorp.

Multi-Cluster-Isolation platziert Workloads in separaten Clustern, wobei jedes Cluster seine eigene Steuerungsebene und eine harte Blast-Radius-Grenze erhält. Dies ist die stärkere Trennung und diejenige, die gewählt werden sollte, wenn Workloads in verschiedenen Compliance-Bereichen liegen, wenn ein lauter oder feindlicher Nachbar unakzeptabel ist, oder wenn ein Upgrade oder ein Ausfall nicht zwischen Tenants übergreifen darf. Bei Managed Kubernetes ist der Kostenrahmen für die freie Wahl von Multi-Cluster durch eine Cluster-Quote pro Vertrag begrenzt (ein Standardwert, der auf Anfrage über IONOS CLOUD Support erhöht werden kann), sodass ein Portfolio, das viele hart isolierte Tenant benötigt, diesen Rahmen einplanen muss, möglicherweise durch Aufteilung über Verträge (der Vertrag ist die in Modul 2 festgelegte Governance-Grenze). Das Muster von FinCorp besteht darin, den regulierten Produktions-Workload in einem eigenen Cluster zu halten, getrennt vom gemeinsamen Entwicklungscuster, genau damit der Produktions-Compliance-Bereich nicht mit dem Entwicklungsaufwand verflochten wird.

DCD-Implementierung: Schritt-für-Schritt-Anleitung

Sie erstellen eine Container Registry, aktivieren die Schwachstellenanalyse, erstellen ein Token mit engem Geltungsbereich und authentifizieren einen Docker-Client damit. Damit wird das Zugriffsmodell aus Abschnitt 1 umgesetzt: eine einzelne Registry, deren einzige Zugriffsoberfläche ein Satz von Tokens mit begrenztem Geltungsbereich und Ablaufdatum ist, bereit für die Pipeline von FinCorp. Die einzige Voraussetzung ist ein Vertragsbenutzer mit der Berechtigung, die Registry zu erstellen.

Ziel der Erstellung: Eine Registry erstellen, ein Token mit begrenztem Geltungsbereich ausgeben und einen Client authentifizieren.

Schritte (im Data Center Designer):

1. Gehen Sie zu Menü > Container > Container Registry, um den Container Registry Manager zu öffnen.
2. Klicken Sie auf Registry hinzufügen. Geben Sie einen Namen an. Beachten Sie, dass der Name dauerhaft ist, global eindeutig über alle Kunden hinweg, nur alphanumerische Zeichen und Bindestriche enthält, 3 bis 63 Zeichen lang ist, mit einem Buchstaben beginnt und alphanumerisch endet.
3. Wählen Sie den Standort aus dem Dropdown-Menü. Auch dieser ist nach der Erstellung nicht mehr änderbar, und die Registry ist im Standort Frankfurt (DE/FRA) verfügbar. Treffen Sie diese Entscheidung bewusst.
4. Konfigurieren Sie optional den Garbage Collection Schedule und wählen Sie den Tag bzw. die Tage und die Uhrzeit (UTC) für den wöchentlichen Lauf, der Speicher freigibt, der von nicht referenzierten Image-Ebenen belegt wird. Die Aufräumfunktion ist standardmäßig deaktiviert; beachten Sie, dass die Registry während des Laufs schreibgeschützt ist, und legen Sie das Zeitfenster außerhalb der Spitzenlast.
5. Entscheiden Sie sich für Vulnerability Scanning. Sie können es hier aktivieren, aber einmal aktiviert, kann es später nicht mehr deaktiviert werden. Behandeln Sie die Aktivierung daher als einseitiges Commitment. (Sie können es auch später zu einer bestehenden Registry über den Bereich Eigenschaften der Registry hinzufügen, wobei dieselbe Irreversibilität gilt.)
6. Klicken Sie auf Registry hinzufügen. Die Registry und ihr Speicher werden erstellt; sie ist bereit zur Verwendung, wenn ihr Status Running erreicht. Der Hostname der Registry wird erst zugewiesen, wenn der Status Running erreicht ist.
7. Wählen Sie die laufende Registry aus und öffnen Sie den Tab Tokens, dann klicken Sie auf Token hinzufügen. Geben Sie dem Token einen Namen (ebenfalls später nicht änderbar).
8. Definieren Sie den Geltungsbereich des Tokens: Setzen Sie den Typ (Registry zum Auflisten von Repositories oder Repository zum Verwalten des Repository-Inhalts), geben Sie den Pfad der erreichbaren Repositories ein (vermeiden Sie das *-Platzhalterzeichen, es sei denn, die Stufe benötigt tatsächlich jedes Repository), und wählen Sie die Aktion(en). Für ein Push-Token in der Build-Stufe wählen Sie Push und, da Push es erfordert, auch Pull. Für ein optionales Ablaufdatum setzen Sie ein Ablaufdatum, das mindestens eine Stunde beträgt. Speichern Sie das Token und kopieren Sie sein Geheimnis jetzt: Es wird nur einmal angezeigt.
9. Authentifizieren Sie einen Client. Melden Sie sich mit der Docker CLI unter dem Hostnamen der Registry an und verwenden Sie das Token als Anmeldedaten:

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 Geltungsbereichs des Tokens Daten hoch- und herunterladen. Der architektonische Aspekt besteht darin, dass dies der einzige Authentifizierungspfad ist: Es gibt keinen anonymen Download, sodass selbst der Lesezugriff über ein Token mit festgelegtem Geltungsbereich erfolgt.

**Häufige Fehler:**

- Vulnerability Scanning als rückholbar zu betrachten. Es handelt sich um einen Einwegschalter; einmal aktiviert, kann er nicht mehr deaktiviert werden. Treffen Sie Ihre Entscheidung, bevor Sie die Funktion aktivieren.
- Zu erwarten, dass ein abgelaufenes Token deaktiviert werden kann. Die Ablaufzeit löscht das Token, es deaktiviert es nicht. Dadurch verschwinden nicht rotierte Pipeline-Zugangsdaten und die Pipeline bricht ab. Rotieren Sie, indem Sie vor Ablauf ein Ersatztoken ausstellen.
- Zu versuchen, 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.
- `Push` ohne `Pull` zu erteilen. Ein Token mit Upload-Berechtigung muss auch Download-Berechtigung besitzen, andernfalls schlägt der Upload fehl.
- Ein Wildcard-`*` oder ein einzelnes, über alle Stufen gemeinsam genutztes Token zu verwenden. Erstellen Sie ein eng umrissenes Token pro Pipeline-Stufe; die Registry verfügt über kein RBAC, daher ist der Token-Geltungsbereich Ihre einzige Zugriffskontrolle.
- Annahme, dass die Registry später umbenannt oder verschoben werden kann. Sowohl der Name als auch der Speicherort sind unveränderlich; die Wahl des falschen Speicherorts bedeutet, dass die Registry neu erstellt werden muss.
- Verlass auf eine öffentliche Download-Ebene für Basis-Images. Es gibt keinen anonymen Zugriff und keine öffentliche Download-Ebene; jeder Download benötigt ein Token.

Zusammenfassung

Die IONOS CLOUD Container Registry steuert den Zugriff über bereichseingeschränkte, ablaufende Tokens, anstatt rollenbasierte Zugriffskontrolle zu verwenden. Daher ist die Sicherheit der Registry genau das Maß an Disziplin, das Sie bei der Verwaltung ihrer Tokens anwenden: ein Token pro Pipeline-Stufe, eng begrenzt, mit Ablaufdatum, durch Ersetzen rotiert und von persönlichen Zugangsdaten getrennt. Die Schwachstellenanalyse ist ein wertvoller, aber irreversibler Zusatz, und der Name sowie der Standort der Registry sind dauerhaft. Die Entscheidung zur Plattformauswahl hängt davon ab, wer den Lebenszyklus der Control-Plane und die Compliance-Verantwortung trägt: Managed Kubernetes belässt beides bei IONOS CLOUD innerhalb des IT-Grundschutz-Umfangs, während OpenShift und Rancher Prime vom Kunden bereitgestellt werden und diese Verantwortung auf Sie übertragen. Trennen Sie Workloads mit Namespaces, wenn sie eine gemeinsame Vertrauensgrenze teilen, und mit mehreren Clustern, wenn sie eine harte Trennung benötigen, innerhalb der vertraglich festgelegten Cluster-Obergrenze.

Wichtige Punkte:

• Die Container Registry verfügt über kein RBAC; der Zugriff erfolgt ausschließlich über Tokens, ohne anonymen Zugriff und ohne öffentliche Pull-Ebene. Die Governance besteht in der Token-Disziplin.
• Der Token-Bereich umfasst Typ (Registry oder Repository) plus Pfad plus Aktion (Pull/Push/Admin); Push erfordert Pull, und das Token-Geheimnis wird nur einmal angezeigt.
• Tokens werden bei Ablauf gelöscht, nicht deaktiviert; rotieren Sie sie, indem Sie vor Ablauf ein Ersatztoken ausstellen. Die Mindestlaufzeit beträgt eine Stunde.
• Die Schwachstellenanalyse ist ein einseitiger Schalter: Nach der Aktivierung kann sie nicht mehr deaktiviert werden. Der Name und der Standort der Registry sind unveränderlich.
• Managed Kubernetes belässt den Lebenszyklus der Control-Plane und die Compliance bei IONOS CLOUD (IT-Grundschutz, nicht C5); OpenShift (CCSP, BYOL) und Rancher Prime (selbstverwaltet, BYOS) werden vom Kunden bereitgestellt, wodurch diese Last auf Sie übergeht.
• Attestationen decken ausschließlich die IONOS CLOUD-Infrastrukturschicht ab, niemals die Workloads des Kunden auf dem Cluster.
• Verwenden Sie Namespaces für eine weiche Trennung mit gemeinsamer Grenze und mehrere Cluster für eine harte Trennung, innerhalb Ihrer vertraglichen Cluster-Quota (auf Anfrage erweiterbar).

Wichtige Begriffe:

• Registry-Zugriffstoken: das einzige Zugangsmerkmal für die Container Registry, begrenzt nach Typ, Pfad und Aktion; dauerhaft oder temporär (mit Ablaufdatum, das es am Lebensende löscht).
• Schwachstellenanalyse: ein irreversibler Zusatz, der hochgeladene Artefakte auf bekannte CVEs prüft und bei Veröffentlichung neuer Definitionen erneut scannt.
• CCSP (Certified Cloud Service Provider): die Red Hat-Partnerrolle, unter der OpenShift auf validierter IONOS CLOUD-Infrastruktur vom Kunden bereitgestellt wird, anstatt als verwalteter IONOS CLOUD-Dienst angeboten zu werden.
• BYOS (Bring Your Own Subscription): das SUSE Rancher Prime-Modell, bei dem IONOS CLOUD die Infrastruktur und SUSE die Lizenzen in Rechnung stellt, während der Kunde die Plattform selbst verwaltet.