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

Vertrauliche Container bieten eine Reihe von Features und Funktionen, um Ihre standardmäßigen Containerworkloads weiter zu sichern, um höhere Datensicherheit, Datenschutz und Laufzeitcodeintegritätsziele zu erreichen. Azure Kubernetes Service (AKS) enthält vertrauliche Container (CoCo) (Vorschau) auf AKS.

Vertrauliche Container basieren auf Kata Confidential Containers und hardwarebasierter Verschlüsselung, um den Containerspeicher zu verschlüsseln. Vertrauliche Container auf AKS verwenden AMD SEV-SNP und unterstützen derzeit nur Azure Linux. 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.

AKS unterstützt zwei Features, die auf Kata-Containern basieren: Vertrauliche Container und Pod-Sandboxing. Während pod Sandboxing die Ausführung des Pods auf einem freigegebenen Kernel sichert, wird der Pod nicht von Angriffen auf Administratorebene geschützt. Vertrauliche Container bieten eine zusätzliche Härtungsebene.

Screenshot eines Architekturdiagramms mit Confidential Containers und Pod-Sandboxing in AKS.

Folgendes macht einen Container vertraulich:

  • Transparenz: Sie können sehen und überprüfen, ob die vertrauliche Containerumgebung, in der Ihre vertrauliche Anwendung ausgeführt wird, sicher ist. Microsoft stellt alle Komponenten der Trusted Computing Base (TCB) als Open Source zur Verfügung.
  • Auditierbarkeit: Sie können überprüfen und sehen, welche Version des CoCo-Umgebungspakets, einschließlich Linux-Gastbetriebssystem und aller Komponenten, aktuell sind. Microsoft signiert die Gastbetriebssystem- und Containerlaufzeitumgebung, sodass Sie sie über den Nachweis überprüfen können. Microsoft veröffentlicht auch einen sicheren Hashwert (SHA) für Fast-BS-Builds, um eine hohe Nachvollziehbarkeit und Kontrolle zu gewährleisten.
  • Vollständiger Nachweis: Die CPU misst alles, was Teil des TEE ist, mit der Möglichkeit, remote zu überprüfen. Der Hardwarebericht des AMD-SEV-SNP-Prozessors gibt Container-Schichten und den Konfigurations-Hash der Container-Runtime durch die Attestierungsansprüche wieder. Die Anwendung kann den Hardwarebericht lokal abrufen, einschließlich des Berichts, der 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 gegenüber dem Betreiber: Sicherheitskonzepte, die vom Prinzip der geringsten Rechte und einem Höchstmaß an Isolation ausgehen und Schutz vor allen nicht vertrauenswürdigen Parteien bieten, einschließlich Kunden- und Mandantenadministratoren. Es umfasst das Härten vorhandener Kubernetes-Steuerungsebenenzugriff (Kubelet) auf vertrauliche Pods.

Durch die Verwendung dieser Funktionen mit anderen Sicherheitsmaßnahmen oder Datenschutzsteuerelementen als Teil Ihrer allgemeinen Architektur können Sie bei der Einhaltung gesetzlicher, branchenspezifischer oder Governance-Complianceanforderungen für die Sicherung vertraulicher Informationen helfen.

Dieser Artikel hilft Ihnen, das Feature "Vertrauliche Container" zu verstehen und die folgenden Aufgaben zu implementieren und zu konfigurieren:

  • Bereitstellen oder Aktualisieren eines AKS-Clusters mithilfe des Azure CLI.
  • Fügen Sie Ihrem Pod-YAML eine Annotation hinzu, um zu kennzeichnen, dass der Pod als Confidential Container ausgeführt wird.
  • Fügen Sie Ihrer Pod-YAML eine Sicherheitsrichtlinie hinzu.
  • Stellen Sie Ihre Anwendung in vertraulichen Computern bereit.

Unterstützte Szenarios

Vertrauliche Container (Vorschau) eignen sich für Bereitstellungsszenarien, die vertrauliche Daten umfassen. 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.

Einschränkungen

Überlegungen

  • Die Pod-Startzeit nimmt im Vergleich zu runc-Pods und kernelisolierten Pods zu.
  • Container-Images, die das Docker-Image-Manifest-Schema der Version 1 (v1) verwenden, werden nicht unterstützt.
  • Um kurzlebige Container und andere Methoden zur Problembehandlung zu verwenden, wie z. B. exec in einen Container, die Ausgabe von Containerprotokollen und stdio, müssen Sie die Richtlinie ändern und erneut bereitstellen, um ExecProcessRequest, ReadStreamRequest, WriteStreamRequest und CloseStdinRequest zu aktivieren.
  • Da die Sicherheitsrichtlinie Messwerte der Layer des Containerimages kodiert, verwenden Sie das Tag latest nicht beim Angeben von Containern.
  • Dienste, Lastenausgleichsgeräte und EndpointSlices unterstützen nur das TCP-Protokoll.
  • Der Richtliniengenerator unterstützt nur Pods, die IPv4-Adressen verwenden.
  • Sie können Pod-Umgebungsvariablen nicht basierend auf ConfigMaps und Geheimen Schlüsseln ändern, nachdem der Pod bereitgestellt wurde.
  • Ressourcen requests in Pod-Manifesten werden nicht unterstützt. Verwenden Sie stattdessen Ressourcen limits , da containerd keine Anforderungen an den Kata-Shim übergibt.
  • Podbeendigungsprotokolle werden nicht unterstützt. Obwohl Pods Beendigungsprotokolle in /dev/termination-log schreiben (oder an einen im Pod-Manifest festgelegten benutzerdefinierten Speicherort), können der Host und das Kubelet diese Protokolle nicht lesen, und Änderungen, die der Pod an dieser Datei vornimmt, werden nicht auf dem Host widergespiegelt.
  • Hostnetzwerkzugriff wird nicht unterstützt. Sie können nicht direkt über die Pod-VM auf die Hostnetzwerkkonfiguration zugreifen.
  • Microsoft Defender für Container bewertet Kata-Laufzeit-Pods nicht.
  • Kata-Container erreichen möglicherweise nicht die IOPS-Leistungsbeschränkungen, die herkömmliche Container auf Azure Files und leistungsstarken lokalen SSD erreichen.

Ü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 Sie keine Ressource limits angeben, sind den Workloads keine separaten CPU-Anteile zugewiesen, und die vCPU wird mit dem betreffenden Workload geteilt. Wenn Sie CPU-Grenzwerte angeben, weist das System explizit CPU-Freigaben für Workloads zu.
  • Arbeitsspeicher, Kata-CC-Handler: Der Handler weist dem Betriebssystem der Hilfs-VM (UVM) 2 GB Arbeitsspeicher plus Arbeitsspeicher in Höhe der im YAML-Manifest angegebenen Ressource limits zu. Wenn Sie keinen Grenzwert angeben, erstellt der Handler einen virtuellen Computer mit 2 GB ohne impliziten Arbeitsspeicher für Container.
  • Speicher, Kata-Handler: Der Handler weist dem UVM-Betriebssystem 256 MB Basisspeicher plus Arbeitsspeicher zu, der der im YAML-Manifest angegebenen Ressource limits entspricht. Wenn Sie keinen Grenzwert angeben, fügt der Handler einen impliziten Grenzwert von 1.792 MB hinzu, was zu einer 2-GB-VM mit 1.792 MB implizitem Speicher für Container führt.

In diesem Release wird das Angeben von Ressourcenanforderungen in den Podmanifesten nicht unterstützt. containerd übergibt die Anforderungen nicht an Kata Shim. Daher wird das Reservieren von Ressourcen basierend auf den Ressourcenanforderungen des Podmanifests nicht implementiert. Verwenden Sie Ressourcen-limits 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

  • Zuletzt aktualisiert um