Sichern Sie Ihre Container-Image-Lieferkette
Wie sichern Sie Ihre Software-Lieferkette?
Die Sicherung Ihrer Software-Lieferkette bedeutet, jedes Artefakt zwischen einem Code-Commit und der Produktion zu kontrollieren. In containerisierten Pipelines läuft es auf vier Kontrollen hinaus: eine private Registry mit RBAC, CVE-Scanning, kryptografische Signierung und eine Richtlinie, die unsignierte oder anfällige Images beim Deployment blockiert.
Warum Lieferkettenangriffe jetzt auf Ihre Container-Images abzielen
SolarWinds, Log4Shell, xz-utils: Die Build-Pipeline ist der neue Perimeter
Die folgenschwersten Software-Sicherheitsvorfälle der letzten Jahre begannen nicht mit einem Firewall-Durchbruch oder einem gestohlenen Passwort. Sie begannen innerhalb der Software-Lieferkette selbst.
- SolarWinds: Das Build-System wurde kompromittiert, um bösartigen Code in signierte Software-Updates einzuschleusen, die US-Regierungsbehörden und Tausende von Unternehmenskunden nachgelagert erreichten.
- Log4Shell: Eine anfällige Open-Source-Komponente, die in einem von unzähligen Projekten gemeinsam genutzten Abhängigkeitsbaum vergraben war, wurde zu einer schwerwiegenden Schwachstelle, die Angreifer gleichzeitig bei Tausenden von unabhängigen Organisationen ausnutzten.
- xz-utils: Die Build-Umgebung eines vertrauenswürdigen Paketbetreuers wurde zum Angriffsvektor, da ein Angreifer geduldig genug war, jahrelang aufgebautes Vertrauen auszunutzen.
Das Muster ist in allen drei Fällen dasselbe. Der Build-Prozess, nicht die laufende Anwendung, war der Punkt der Kompromittierung.
Ein Container-Image ist das letzte Artefakt, bevor das Build-Ergebnis die Produktion erreicht. Es ist zudem der letzte praktische Ort, um eine kompromittierte Komponente und ihre Abhängigkeiten abzufangen, bevor ein Exploit Schaden anrichtet.
Warum Docker Hub und öffentliche Registries nicht ausreichen
Eine öffentliche Registry ist standardmäßig öffentlich, es sei denn, Sie bezahlen für private Repositories. Sie verfügt über kein teamweites RBAC, keine Durchsetzung von CVE-Richtlinien und keine Signaturprüfung beim Pull.
Das ist keine Funktionslücke, die man einfach patchen kann. Es ist ein anderer Produkttyp.
Öffentliche Registries existieren, um Open-Source-Software an jeden Verbraucher zu verteilen, der sie haben möchte. Der Paketautor und der Paketverbraucher begegnen sich nie, und keiner von beiden kann viel über den anderen verifizieren.
Die genaue Kontrolle darüber, welche Software-Images die Kubernetes-Cluster Ihres Unternehmens pullen dürfen, ist ein völlig anderes Problem.
Eine generische private Registry ohne dokumentierte Sicherheitslage reduziert das Risiko der Software-Lieferkette ebenfalls nicht. Das Risiko ist konkret: Ein Angriff, der eine schädliche Komponente in ein Image einschleust, infiziert jeden Cluster, der es pullt.
Dieses Risiko vervielfacht sich mit jedem Team, das die Registry nutzt. Ohne systematische Scans, ohne Richtlinienebene und ohne Audit-Trail darüber, wer was wann gepusht hat und ob es signiert war, haben Sie Images zwar von einer öffentlichen Registry verschoben, aber das Risiko nicht verringert.
Der Compliance-Aspekt: ISO 27001, SOC 2 und regulierte Branchen
Sicherheitsteams erhalten selten ein Budget für diese Arbeit, bis ein Audit sie dazu zwingt. Compliance-Audits behandeln nicht gescannte Container-Images als kritische Feststellung, nicht als Empfehlung.
Sicherheit ist eine Haltung, die man pflegt, kein Produkt, das man kauft, und ein Auditor prüft die Haltung und nicht die Liste der Tools. Die Sicherheit der Software-Lieferkette wird als eine Reihe von Praktiken bewertet, und jede Praxis benötigt Nachweise.
ISO 27001, SOC 2 und die meisten Sicherheitsstandards für regulierte Branchen, von denen viele in Zusammenarbeit mit Regierungsbehörden und Branchenberatungsgremien entwickelt wurden, erwarten dokumentierte, systematische Schwachstellenscans und Zugriffskontrollen für jede Software, die in die Produktion gelangt. Container-Images sind Produktionsartefakte wie jedes andere auch.
Container-Images speichern zudem Anwendungscode, Konfigurationen und manchmal Umgebungsvariablen. Registry-Berechtigungen sind daher eine Zugriffskontrolle für sensibles geistiges Eigentum an Software.
Dies sind genau die Art von Sicherheits-Best-Practices, die ein Auditor dokumentiert und nicht nur vorausgesetzt sehen möchte.
Die empfohlene Vorgehensweise in jedem veröffentlichten Leitfaden, von CISA bis zur CNCF, ist dieselbe, und es lohnt sich, sie zu erlernen, bevor ein Audit Sie dazu zwingt:
• Machen Sie jede Kontrolle zu einer dokumentierten Praxis mit einem benannten Verantwortlichen.
• Sichern Sie die Build-Umgebung genauso sorgfältig wie die Laufzeitumgebung.
• Halten Sie Abhängigkeiten aktuell, damit sich keine bekannten Schwachstellen ansammeln.
Auditoren verlangen Nachweise für jeden dieser Punkte, und der OVHcloud Identity, Security & Operations-Hub deckt die Dienste ab, die diese generieren.
Die vier Kontrollen, die jede containerisierte Pipeline benötigt
Ein Framework wie SLSA (Supply-chain Levels for Software Artifacts) bietet Teams eine strukturierte Möglichkeit, den Reifegrad dieser Kontrollen zu messen. Sie müssen kein vollständiges Framework übernehmen, um den praktischen Nutzen zu erzielen.
SLSA-Level sind hauptsächlich als gemeinsame Sprache mit Auditoren und Partnern nützlich, und allein deshalb lohnt es sich, SLSA zu erlernen. Ein externer Partner gibt sein Level an, Sie vergleichen es mit Ihrem eigenen, und niemand verschickt einen langen Fragebogen.
Lieferanten veröffentlichen zunehmend eines, daher ist es eine normale Beschaffungsfrage, einen Partner nach seinem zu fragen.
Statische Analyse, oder SAST, wird auf dem Quellcode ausgeführt, bevor etwas erstellt wird. Sie erkennt eine andere Klasse von Schwachstellen als das Image-Scannen und gehört früher in die Kette, zusammen mit der Software-Kompositionsanalyse Ihrer Abhängigkeiten.
SAST und Image-Scannen sind Ergänzungen, keine Ersatzlösungen. Keines erkennt das, was das andere finden soll. Drei Ebenen decken die gesamte Kette ab:
1. Führen Sie SAST auf Ihrem eigenen Quellcode aus.
2. Führen Sie eine Software-Kompositionsanalyse auf externe Abhängigkeiten aus.
3. Führen Sie ein Image-Scannen auf dem erstellten Artefakt aus.
Lassen Sie einen der drei Schritte aus, und Sie lassen eine ganze Klasse von Schwachstellen unbewertet, unabhängig davon, was die anderen Tools berichten.
Die vier unten aufgeführten Kontrollen setzen an dem Punkt an, an dem ein Build ein Container-Image erzeugt, das zentrale Artefakt in der Kette.
Speichern Sie Images in einer privaten, RBAC-gesteuerten Registry
Die grundlegende Kontrolle einer sicheren Software-Lieferkette ist eine Registry, die standardmäßig geschlossen ist und über eine projekt- oder teambezogene RBAC verfügt. Kein gemeinsam genutzter Bucket, in den jeder pushen kann, und keine öffentliche Registry mit standardmäßig sichtbaren Images.
Robot-Accounts erledigen den Rest der Arbeit:
• Beschränken Sie jeden Robot-Account auf ein einzelnes Projekt.
• Geben Sie Build-Schritten reine Schreib-Push-Berechtigungen und Deployment-Schritten reine Lese-Pull-Berechtigungen.
• Führen Sie ein Projekt pro Team aus, damit ein kompromittiertes Projekt isoliert bleibt.
• Wenden Sie eine zentrale Richtlinie auf jedes Projekt an, die zentral auditiert wird.
• Halten Sie persönliche und Administrator-Anmeldedaten vollständig aus automatisierten Builds heraus.
Scannen Sie jedes Image beim Push und beim Pull auf CVEs.
Schwachstellen-Scans müssen an zwei Punkten erfolgen:
• Beim Push, damit ein neues Image in dem Moment gescannt wird, in dem es erstellt wird.
• Beim Pull, damit eine Richtlinienprüfung erneut ausgeführt wird, bevor ein älteres Image gegen eine neuere Schwachstellendatenbank bereitgestellt wird.
Ein Image, das im März sauber war, kann bis Juni drei bekannte Schwachstellen aufweisen, und nur eine Prüfung zum Zeitpunkt des Pulls erkennt diese.
Das asynchrone Scannen beim Push verlangsamt den Build nicht. Der Scan läuft parallel, während die Pipeline fortgesetzt wird, und die Ergebnisse sind verfügbar, bevor das Image in Richtung Produktion befördert wird.
Signieren Sie Artefakte mit Cosign oder Notary v2
Das kryptografische Signieren eines Images zeichnet auf, wer es erstellt hat, und bestätigt, dass es während des Transports nicht manipuliert wurde. Es etabliert eine Vertrauenskette vom Build-System bis zum Cluster.
Vertrauen ist das, worauf ein Angreifer es wirklich abgesehen hat. Die xz-utils-Backdoor funktionierte, weil sich das Vertrauen in einen Betreuer über Jahre hinweg aufgebaut hatte, und Angreifer sind geduldig genug, um einen Betreuer auszunutzen, anstatt eine Firewall.
Cosign, Teil des Sigstore-Projekts, und Notary v2 sind heute die beiden dominierenden Open-Source-Ansätze für die Signierung von Container-Images.
Ohne eine Signatur und eine Richtlinie, die diese überprüft, gibt es nach einem Vorfall keine Möglichkeit nachzuweisen, dass das in der Produktion laufende Image genau das Artefakt ist, das Ihre Pipeline erstellt hat. Ein unsigniertes Image und ein manipuliertes Image sind zum Zeitpunkt der Bereitstellung nicht voneinander zu unterscheiden.
Setzen Sie eine Bereitstellungsrichtlinie durch, bevor Images Kubernetes erreichen
Scannen und Signieren sind nur dann von Bedeutung, wenn sie auch durchgesetzt werden. Ein Kubernetes Admission Controller, wobei Kyverno oder OPA Gatekeeper die zwei gängigen Optionen sind, überprüft jedes Image zum Zeitpunkt der Bereitstellung und lehnt alles ab, was die Richtlinie nicht erfüllt:
• Nicht behobene kritische CVEs.
• Eine fehlende oder ungültige Cosign-Signatur.
• Ein Image aus einer nicht genehmigten Registry.
Das ist die Kontrolle, die die anderen durchsetzbar macht und die ein Angriff überwinden muss. Sie macht das Image-Scannen von einer gemeldeten Metrik zu einer harten Schranke, sodass kein ungescanntes Image die Produktion erreicht, was die eigentliche Compliance-Anforderung ist.
Die zwei Durchsetzungspunkte ergänzen sich. Die Registry blockiert den Push, der Cluster blockiert die Bereitstellung, und ein Angriff, der an einem vorbeikommt, trifft immer noch auf das andere. Beide befinden sich auf einem Cluster, den Sie nicht selbst betreiben müssen, wenn Sie den Managed Kubernetes Service von OVHcloud nutzen.
Diese vier technischen Kontrollen stehen neben, nicht anstelle von organisatorischen Praktiken, die das Risiko umfassender reduzieren. Praktiken dieser Art sind im Vergleich zu einem Vorfall kostengünstig, und jede ist eine Praxis, die ein Prüfer verifizieren kann.
Dies sind die Praktiken, die ein sicheres Design in ein sicheres System verwandeln, und jede einzelne ist eine zentrale Praxis, kein optionales Extra:
• Aktualisieren Sie regelmäßig Abhängigkeiten und Komponenten von Drittanbietern, um sich vor bekannten Exploits zu schützen.
• Begrenzen Sie den Zugriff auf sensible Build-Systeme und Signierschlüssel.
• Schulen Sie Mitarbeiter und führen Sie Sicherheitsschulungen durch, damit Entwickler ein kompromittiertes Paket oder einen Phishing-Versuch gegen ein Betreuerkonto erkennen.
• Führen Sie Übungen zu einem Vorfallreaktionsplan durch, damit ein Team weiß, wie es schnell reagieren kann, wenn eine Kontrolle versagt.
• Überprüfen Sie die Integrität von Software kontinuierlich, anstatt sie vorauszusetzen, damit jedes Artefakt durch eine Prüfung und nicht durch Gewohnheit gesichert bleibt.
Jede potenzielle Sicherheitslücke in dieser Liste ist in der Regel eine Prozesslücke, keine Werkzeuglücke.
Jede Softwarekomponente, die Sie einbinden, und jede transitive Komponente darunter ist eine Entscheidung, die jemand einmal getroffen hat und selten überdenkt. Eine moderne Anwendung umfasst Hunderte solcher Komponenten, die meisten von einer externen Partei, die niemand kennt.
Die Komponenteninventur ist daher die Praxis, von der alles andere abhängt. Abhängigkeitsmanagement, also zu wissen, welche Software und welche Komponenten von einem Drittanbieter stammen, macht eine SBOM (Software Bill of Materials) nützlich, sobald Sie eine haben.
Eine SBOM listet jede Komponente und jede Version auf, was eine neue CVE-Meldung in eine fünfminütige Abfrage verwandelt, anstatt in eine Woche Archäologie. Ohne eine solche ist die ehrliche Antwort auf die Frage, ob Sie gefährdet sind, dass es niemand weiß.
Wie OVHcloud Managed Private Registry die Lücke schließt
Harbor unter der Haube: CNCF-graduiert, OCI-Standard, Open Source
Managed Private Registry ist eine vollständig verwaltete Instanz von Harbor, einer CNCF-graduierten Open-Source-Technologie, die für die Speicherung von Containern und Helm-Charts entwickelt wurde, wobei Sicherheit ein erstklassiges Feature und kein Add-on ist.
Das Self-Hosting von Harbor bedeutet, PostgreSQL, Redis, die Kerndienste von Harbor und den Scanner sowie TLS und Upgrades für jede dieser Komponenten auszuführen und zu patchen.
OVHcloud entfernt diese operative Ebene. Sie erstellen eine Registry, pushen Images und konfigurieren Richtlinien, während die Harbor-Infrastruktur darunter in der Verantwortung von OVHcloud liegt. Das entlastet Ihr Cybersecurity-Team für Bedrohungsmodellierung und Lieferkettenresilienz, anstatt eine Datenbank zu patchen.
Da Harbor Open Source und standardbasiert ist, gibt es keine proprietäre Anbieterbindung. Images liegen im Standard-OCI-Format vor, sodass für die Migration zu einem selbst gehosteten Harbor oder einer anderen OCI-konformen Registry kein Konvertierungsschritt und kein proprietäres Pull-Format erforderlich ist.
Diese Transparenz ist an sich schon ein Sicherheitsmerkmal. Eine globale Community von Prüfern, nicht ein einzelner Anbieter, überprüft den Code, der Ihre Registry ausführt.
Ein zentrales Projekt mit vielen Prüfern erkennt einen bösartigen Commit schneller als ein geschlossenes, und Bedrohungsinformationen über Harbor- oder Trivy-Schwachstellen erreichen Sie über dieselben öffentlichen Kanäle, auf die sich jeder andere Benutzer verlässt.
Schwachstellenscan mit Trivy: CVE-Erkennung bei Push und Pull
Die OVHcloud Managed Private Registry enthält Trivy, den integrierten Scanner von Harbor, der auf Projektebene aktiviert wird.
Konfigurieren Sie „Scan-on-Push“, damit jedes Image beim Eintreffen überprüft wird, und legen Sie dann einen Schwellenwert für die CVE-Schweregradstufe fest. „Warnen bei HIGH, blockieren bei CRITICAL“ ist eine empfohlene Einstiegsrichtlinie.
Ein Scan zum Zeitpunkt des Pulls überprüft dann ein älteres Image erneut anhand einer neueren Schwachstellendatenbank.
Eine Harbor-Bereitstellungsrichtlinie verhindert das Pullen von Images mit ungelösten CRITICAL-CVEs in Produktions-Namespaces, was das Scan-Ergebnis handlungsorientiert statt nur informativ macht.
Image-Signierung mit Cosign und Notary v2
Der Dienst basiert auf Harbor und unterstützt daher die für das Produkt dokumentierte Schwachstellenanalyse und Helm-Chart-Speicherung.
Das Image-Signieren selbst erfolgt über standardmäßige Cosign-Open-Source-Tools in Ihrer CI/CD-Pipeline, die auf die OVHcloud-Registry verweisen und nicht auf einen proprietären Signierungsdienst.
Richtliniendurchsetzung: Blockieren von Images mit kritischen CVEs vor der Bereitstellung
Die richtlinienbasierte Blockierung auf der Registry-Seite bei KRITISCHEN CVEs und die Anforderung einer gültigen Signatur sind nur die halbe Geschichte der Durchsetzung.
Die andere Hälfte läuft in Kubernetes selbst. Eine Zulassungsrichtlinie von Kyverno oder OPA Gatekeeper lehnt jedes Image ohne gültige Cosign-Signatur oder mit einer ungelösten schwerwiegenden Sicherheitslücke ab, unabhängig davon, wie es bereitgestellt wurde oder durch welchen Akteur.
Zusammen ermöglichen sie eine durch Richtlinien erzwungene CVE-Blockierung von Ende zu Ende. Es handelt sich um eine Konfiguration, die Sie bewusst einrichten, nicht um eine automatische Garantie.
Helm-Chart-Speicher (OCI-konform)
Helm-Charts werden im selben OCI-konformen Format wie Container-Images gespeichert, in derselben Projektstruktur, mit denselben RBAC- und Robot-Konten.
Teams, die Bereitstellungen als Helm-Charts verpacken, erhalten eine Registry für beide Artefakt-Typen, anstatt ein separates Chart-Repository sichern und warten zu müssen.
Verbindung Ihrer CI/CD-Pipeline (GitHub Actions, GitLab CI, Tekton)
Robot-Accounts: Nur-Schreib-Push für Builds, Nur-Lese-Pull für Deployments
Erstellen Sie ein Harbor-Projekt pro Team oder Anwendung und stellen Sie dann Robot-Konten aus, die genau auf die Anforderungen der jeweiligen Phase zugeschnitten sind: Nur-Schreib-Push für die Build-Phase, Nur-Lese-Pull für die Deployment-Phase.
Betten Sie niemals Administrator- oder persönliche Anmeldedaten oder die Schlüsseldatei eines Robot-
Kontos in eine Build-Definition ein. Ein geleaktes Pull-Only-Robot-Konto ist ein isolierter Vorfall. Ein durchgesickertes Admin-Zugangsdatenpaar in den Händen eines externen Akteurs ist dies nicht.
Speziell für Cosign-Signierschlüssel unterstützt OVHcloud OVHcloud Key Management Service Bring-Your-Own-Key mit FIPS 140-2 HSM-gestütztem Speicher, wodurch Ihre Schlüssel nicht auf Entwickler-Laptops und CI-Runnern liegen.
GitHub Actions-Beispiel: Erstellen, Scannen, Signieren und Übertragen
Eine einzige Stufe deckt das gesamte Gate ab:
1. Erstellen Sie das Image.
2. Übertragen Sie es mit einem Nur-Schreib-Roboter-Konto.
3. Warten Sie auf das Ergebnis des Trivy-Scans.
4. Signieren Sie mit Cosign nur dann, wenn der Scan den konfigurierten CVE-Schwellenwert erfüllt.
Diese Sequenz hält eine harte Grenze zwischen der Existenz eines Images und dem Vertrauen in ein Image aufrecht, das für eine Signierung ausreicht, anstatt bedingungslos zum Zeitpunkt der Erstellung zu signieren.
Dasselbe Muster gilt, unabhängig davon, ob der Build auf GitHub Actions, GitLab CI oder Tekton ausgeführt wird. Nur die Syntax für den Aufruf der Registry und des Scanners ändert sich, unabhängig davon, in welcher Programmiersprache Ihre Anwendung geschrieben ist.
Kyverno-Zulassungsrichtlinien für Managed Kubernetes Service
Auf dem OVHcloud Managed Kubernetes Service prüft eine Kyverno-Richtlinie, die als Standard-Kubernetes-Richtliniendatei definiert ist, jede eingehende Pod-Spezifikation auf eine gültige Cosign-Signatur und lehnt die Bereitstellung ab, wenn die Signatur fehlt oder ungültig ist.
In Kombination mit der CVE-Richtlinie auf Registry-Ebene schließt dies die Lücke zwischen dem, was Sie erstellen, und dem, was der Cluster möglicherweise ausführt. Ein unsigniertes oder nicht gescanntes Image startet nie, egal wer die Bereitstellung angefordert hat.
Souveräne Lieferkette: Warum die Gerichtsbarkeit Ihrer Registry wichtig ist
Container-Images enthalten geistiges Eigentum und damit auch die Offenlegung durch den CLOUD Act.
Ein Container-Image bündelt Anwendungscode, Konfigurationsschichten und manchmal Umgebungsvariablen: ein bedeutender Teil des geistigen Eigentums Ihres Unternehmens. Eine zentrale Registry ist der Ort, an dem sich dieses geistige Eigentum konzentriert, weshalb ihre Zuständigkeit von Bedeutung ist. Die Speicherung dieses Images bei einem Anbieter mit Hauptsitz in den USA, selbst bei einem mit EU-Rechenzentren, unterstellt es der Zuständigkeit des US CLOUD Act, da die Offenlegung dem Mutterunternehmen folgt, nicht dem Speicherort. Die gleiche Logik gilt für jede AWS ECR-, Google Artifact Registry- oder Docker Hub-Bereitstellung: Die Zuständigkeit des US CLOUD Act gilt unabhängig von der Region.
Europäischer Hauptsitz, kein US-Mutterkonzern, DSGVO durch Zuständigkeit
Ein Container-Image bündelt Anwendungscode, Konfigurationsschichten und manchmal Umgebungsvariablen: ein bedeutender Teil des geistigen Eigentums Ihres Unternehmens.
Eine zentrale Registry ist der Ort, an dem sich dieses geistige Eigentum konzentriert, weshalb ihre Zuständigkeit von Bedeutung ist.
Die Speicherung dieses Images bei einem Anbieter mit Hauptsitz in den USA, selbst bei einem mit Rechenzentren in der EU, unterstellt es der Gerichtsbarkeit des US CLOUD Act, da die Offenlegung dem Mutterkonzern und nicht dem Speicherort folgt.
Dasselbe gilt für jede Registry, die von einem Anbieter mit Hauptsitz in den USA betrieben wird: Die Zuständigkeit des US CLOUD Act gilt unabhängig von der Region.
Europäischer Hauptsitz, kein US-Mutterkonzern, DSGVO durch Zuständigkeit
OVHcloud ist ein europäischer Betreiber ohne US-Muttergesellschaft, daher gibt es keine strukturelle Gefährdung durch den CLOUD Act für alles, was in der Registry gespeichert ist.
Die Registry-Infrastruktur unterliegt der DSGVO aufgrund der Zuständigkeit und nicht aufgrund einer Richtlinienverpflichtung.
Der rechtliche Schutz ergibt sich aus dem Standort des Unternehmens und der Infrastruktur, nicht aus einem vertraglichen Versprechen, das auf einer Infrastruktur aufbaut, zu der eine ausländische Behörde dennoch zwingen könnte.
End-to-End-Pfad: Managed Private Registry zu Managed Kubernetes Service
Erstellen Sie ein Managed Private Registry-Projekt, übertragen Sie ein Image und aktivieren Sie das Scannen und Signieren. MKS Free deckt Entwicklung und Staging kostenlos ab, sodass Sie die gesamte Richtlinienkette validieren können, bevor Produktionsdatenverkehr davon abhängt. Für mehrere Produktionscluster, regulierte Sektoren oder GPU-Node-Pools hilft Ihnen ein OVHcloud Solutions Architect bei der Dimensionierung. Der Container-Orchestrierungs-Hub ist der Ort, an dem Sie den Rest erfahren.
3-AZ-Verfügbarkeit in Paris und Mailand, 99,99% Verfügbarkeits-SLA für MKS Standard
Die Registry läuft 3-AZ in Paris mit integrierter Hochverfügbarkeit. Ein Ausfall einer einzelnen Zone stoppt weder Ihre Builds noch Ihre Deployments, was wichtig ist, da ein Registry-Ausfall beides blockiert.
Managed Kubernetes Service Standard läuft 3-AZ in Paris und Mailand mit einer 99,99% Verfügbarkeits-SLA, sodass die Registry und der Cluster, der von ihr abruft, eine gemeinsame Verfügbarkeitsstrategie teilen, anstatt dass einer das schwache Glied ist.
MKS Free für den Start, MKS Standard für die Produktion
Managed Kubernetes Service bietet eine kostenlose Stufe für Entwicklung und Staging, die ausreicht, um die gesamte Software-Lieferkette zu validieren: Registry, Scannen, Signieren und Zulassungsrichtlinien, bevor Sie sich für einen Produktionscluster entscheiden.
Das Festlegen von Versionen für Ihre Richtliniendateien hält diese Validierung reproduzierbar.
Wenn Sie bereit für den Produktionsverkehr sind, fügt MKS Standard die 3-AZ-Stufe mit einer Verfügbarkeits-SLA von 99,99 % hinzu, und dieselben Kyverno- oder OPA-Gatekeeper-Richtlinien werden unverändert auf beide Stufen übertragen.
Teams, die mehrere Cluster betreiben, fügen Managed Rancher Service hinzu, um eine gemeinsame Steuerungsebene für alle zu erhalten.
Erste Schritte: Aktivieren Sie Ihre Registry und liefern Sie noch heute sichere Images aus.
Erstellen Sie ein Managed Private Registry-Projekt, übertragen Sie ein Image und aktivieren Sie das Scannen und Signieren. MKS Free deckt Entwicklung und Staging kostenlos ab, sodass Sie die gesamte Richtlinienkette validieren können, bevor Produktionsdatenverkehr davon abhängt. Für mehrere Produktionscluster, regulierte Sektoren oder GPU-Node-Pools hilft Ihnen ein OVHcloud Solutions Architect bei der Dimensionierung. Der Container-Orchestrierungs-Hub ist der Ort, an dem Sie den Rest lernen können.