Vertrauliche Container (Vorschau) mit Azure Kubernetes Service (AKS)

  • Artikel

Vertrauliche Container bieten eine Reihe von Features und Funktionen, mit denen Sie Ihre Standardcontainerworkloads weiter absichern können, um höhere Ansprüche an Datensicherheit, Datenschutz und Laufzeitcodeintegrität zu erfüllen. Azure Kubernetes Service (AKS) schließt vertrauliche Container (Vorschau) mit AKS ein.

Vertrauliche Container basieren auf dem Kata-Projekt Confidential Containers und hardwarebasierter Verschlüsselung zum Verschlüsseln von Containerspeichern. Sie stellen eine neue Ebene der Datenvertraulichkeit her, indem verhindert wird, dass Daten während Berechnungen im Arbeitsspeicher in lesbarem Klartextformat vorliegen. Die Vertrauensstellung wird im Container über einen Hardwarenachweis erzielt, der Zugriff auf die verschlüsselten Daten durch vertrauenswürdige Entitäten ermöglicht.

Zusammen mit Podsandboxingkönnen Sie vertrauliche Workloads isoliert in Azure ausführen, um Ihre Daten und Workloads zu schützen. Folgendes macht einen Container vertraulich:

  • Transparenz: Die vertrauliche Containerumgebung, in der Ihre vertrauliche Anwendung freigegeben ist, können Sie sehen und überprüfen, ob sie sicher ist. Alle Komponenten der Trusted Computing Base (TCB) müssen quelloffen sein.
  • Prüffähigkeit: Sie müssen die Möglichkeit haben, zu überprüfen und zu sehen, welche Versionen des CoCo-Umgebungspakets einschließlich Linux-Gastbetriebssystem und alle Komponenten aktuell sind. Microsoft meldet sich bei der Gastbetriebssystem- und Containerlaufzeitumgebung für Überprüfungen durch Nachweis an. Außerdem wird ein sicherer Hashalgorithmus (SHA) von Gastbetriebssystembuilds veröffentlicht, um eine Zeichenfolgen-Prüfbarkeit und einen Kontrollverlauf zu erstellen.
  • Vollständiger Nachweis: Alles, was Teil der TEE ist, wird vollständig von der CPU gemessen, mit der Möglichkeit, remote überprüft zu werden. Der Hardwarebericht des AMD SEV-SNP-Prozessors muss Containerebenen und Containerlaufzeit-Konfigurationshash über die Nachweisansprüche widerspiegeln. Die Anwendung kann den Hardwarebericht lokal abrufen, einschließlich des Berichts, welcher das Gastbetriebssystemimage und die Containerlaufzeit widerspiegelt.
  • Codeintegrität: Die Laufzeiterzwingung ist immer über kundendefinierte Richtlinien für Container und Containerkonfiguration verfügbar, z. B. unveränderliche Richtlinien und Containersignatur.
  • Isolation vom Betreiber: Sicherheitsdesigns, welche die geringsten Berechtigungen und höchste Isolationsabschirmung von allen nicht vertrauenswürdigen Parteien einschließlich Kunden-/Mandantenadministratoren annehmen. Es umfasst das Härten vorhandener Kubernetes-Steuerungsebenenzugriff (Kubelet) auf vertrauliche Pods.

Gemeinsam mit anderen Sicherheitsmaßnahmen oder Datenschutzkontrollen im Rahmen Ihrer allgemeinen Architektur helfen Ihnen diese Funktionen bei der Erfüllung gesetzlicher, branchenspezifischer oder unternehmensinterner Konformitätsanforderungen zum Schutz vertraulicher Informationen.

In diesem Artikel erfahren Sie mehr über das Feature der vertraulichen Container und wie Sie Folgendes implementieren und konfigurieren:

  • Bereitstellen oder Aktualisieren eines AKS-Clusters mithilfe der Azure-Befehlszeilenschnittstelle
  • Hinzufügen einer Anmerkung zu Ihrem POD-YAML-Code, um den Pod für die Ausführung als vertraulicher Container zu kennzeichnen
  • Hinzufügen einer Sicherheitsrichtlinie zu Ihrem Pod-YAML-Code
  • Aktivieren der Durchsetzung der Sicherheitsrichtlinie
  • Bereitstellen Ihrer Anwendung für Confidential Computing

Unterstützte Szenarios

Vertrauliche Container (Vorschau) eignen sich für Bereitstellungsszenarien mit vertraulichen Daten. Beispiele: personenbezogene Informationen oder Daten mit der Anforderung an starke Sicherheit zur Einhaltung gesetzlicher Vorschriften. Einige häufige Szenarien mit Containern sind:

  • Ausführen von Big Data-Analysen mit Apache Spark für die Erkennung von Betrugsmustern im Finanzsektor.
  • Ausführen von selbst gehosteten GitHub-Runnern zum sicheren Signieren von Code im Rahmen der DevOps-Praktiken Continuous Integration und Continuous Deployment (CI/CD).
  • Rückschlüsse mit maschinellem Lernen und Training von ML-Modellen mithilfe eines verschlüsselten Datasets aus einer vertrauenswürdigen Quelle. Entschlüsselungen finden nur innerhalb einer vertraulichen Containerumgebung statt, um den Datenschutz zu wahren.
  • Erstellen von Big Data-Reinräumen für den ID-Abgleich im Rahmen von Berechnungen mit mehreren Teilnehmenden in Branchen wie Einzelhandel mit digitaler Werbung.
  • Erstellen von Zero Trust-Zielzonen für Confidential Computing zum Erfüllen von Datenschutzbestimmungen für Anwendungsmigrationen zur Cloud.

Überlegungen

Im Folgenden finden Sie Überlegungen in dieser Vorschau vertraulicher Container:

  • Eine Erhöhung der Podstartzeit im Vergleich zu RunC-Pods und kernelisolierten Pods.
  • Containerimages der Version 1 werden nicht unterstützt.
  • Updates für Geheimnisse und ConfigMaps werden nicht im Gast widergespiegelt.
  • Kurzlebige Container und andere Problembehandlungsmethoden wie exec für einen Container, Protokollausgaben von Containern und stdio (ReadStreamRequest und WriteStreamRequest) erfordern eine Änderung und erneute Bereitstellung der Richtlinie.
  • Das Richtliniengeneratortool unterstützt keine Cronjob-Bereitstellungstypen.
  • Da Messungen auf Containerimageebene in der Sicherheitsrichtlinie codiert werden, wird die Verwendung des latest-Tags beim Angeben von Containern nicht empfohlen.
  • Dienste, Lastenausgleichsmodule und EndpointSlices unterstützen nur das TCP-Protokoll.
  • Alle Container in allen Pods in den Clustern müssen für imagePullPolicy: Always konfiguriert werden.
  • Der Richtliniengenerator unterstützt nur Pods, die IPv4-Adressen verwenden.
  • ConfigMaps und Geheimniswerte können bei Festlegung mit der Umgebungsvariablenmethode nach der Bereitstellung des Pods nicht mehr geändert werden. Die Sicherheitsrichtlinie verhindert dies.
  • Podbeendigungsprotokolle werden nicht unterstützt. Während Pods Beendigungsprotokolle in /dev/termination-log oder an einen benutzerdefinierten Speicherort schreiben, sofern dies im Pod-Manifest angegeben ist, kann der Host/das Kubelet diese Protokolle nicht lesen. Änderungen vom Gast zu dieser Datei werden nicht auf dem Host wiedergegeben.

Übersicht über die Ressourcenzuordnung

Es ist wichtig, das Verhalten der Speicher- und Prozessorressourcenzuordnung in diesem Release zu verstehen.

  • CPU: Der Shim weist dem Basisbetriebssystem innerhalb des Pods eine vCPU zu. Wenn keine Ressourcen-limits angegeben sind, werden den Workloads keine separaten CPU-Freigaben zugewiesen, und die vCPU wird für diese Workload freigegeben. Wenn CPU-Grenzwerte angegeben sind, werden CPU-Freigaben explizit für Workloads zugewiesen.
  • Arbeitsspeicher: Der Kata-CC-Handler verwendet 2 GB Arbeitsspeicher für das UVM-Betriebssystem und X MB zusätzlichen Arbeitsspeicher. Dabei steht X für die Ressourcengrenzwerte (limits), sofern im YAML-Manifest angegeben. (Dies führt zu einer 2-GB-VM, wenn kein Grenzwert angegeben wird, ohne impliziten Arbeitsspeicher für Container.) Der Kata--Handler verwendet 256 MB Basisspeicher für das UVM-Betriebssystem und X MB zusätzlichen Arbeitsspeicher, wenn Ressourcengrenzwerte (limits) im YAML-Manifest angegeben sind. Wenn keine Grenzwerte angegeben sind, wird ein impliziter Grenzwert von 1.792 MB hinzugefügt. Dies führt zu einer impliziten 2 GB-VM und einem impliziten Speicher von 1.792 MB für Container.

In diesem Release wird die Angabe von Ressourcenanforderungen in den Podmanifesten nicht unterstützt. Der Kata-Container ignoriert Ressourcenanforderungen aus dem Pod-YAML-Manifest, daher gibt containerd die Anforderungen nicht an den Shim weiter. Verwenden Sie Ressourcen-limit anstelle von Ressourcen-requests, um Arbeitsspeicher- oder CPU-Ressourcen für Workloads oder Container zuzuweisen.

Wenn das lokale Containerdateisystem durch VM-Speicher gestützt wird, kann das Schreiben in das Containerdateisystem (einschließlich Protokollierung) den bereitgestellte verfügbaren Arbeitsspeicher für den Pod füllen. Dieser Zustand kann zu möglichen Podabstürzen führen.

Nächste Schritte