Confidential Containers in Kubernetes: Was ein echter Betreiberausschluss voraussetzt

Wann sind Daten in der Cloud verschlüsselt?

Mit herkömmlicher Verschlüsselung lassen sich Daten während der Speicherung und während der Übertragung schützen. Während der Verarbeitung sind Daten allerdings für gewöhnlich nicht geschützt und liegen zu einem bestimmten Zeitpunkt im Klartext im Arbeitsspeicher. Dadurch sind Daten, die verarbeitet werden, grundsätzlich zugänglich für Infrastrukturbetreiber, Administratoren und andere Parteien.

Confidential Computing schließt diese Lücke. Hardwarebasierte "Trusted Execution Environments" halten den Arbeitsspeicher und die darin enthaltenen Daten auch während der Verarbeitung verschlüsselt und schirmen die Datenverarbeitung logisch ab. Die dazugehörige "Remote Attestation" macht diese Sicherheitsmechanismen aus der Ferne überprüfbar. Das Ergebnis ist ein technischer Betreiberausschluss.

Wie sieht eine solche Umsetzung konkret aus?

Betrachtet wird hierbei Kubernetes, die Standard-Orchestrierungsplattform für Cloud-native Anwendungen. Kubernetes verteilt Workloads auf Nodes. Ein Node ist eine einzelne Maschine im Cluster. Auf jedem Node laufen normalerweise mehrere Container, die zu sogenannten Pods zusammengefasst sind.

Mittels Confidential Computing können ganze Nodes isoliert werden ("Confidential Cluster") oder einzelne Pods ("Confidential Containers"):

• Confidential Cluster: Der gesamte Node läuft als eine verschlüsselte VM. Alle Pods auf diesem Node teilen sich mit den Kubernetes-Verwaltungsprozessen dieselbe Isolationsgrenze. Sie sind damit weder voneinander noch von diesen Prozessen getrennt. Remote Attestation kann nur bestätigen, dass der Node als Ganzes vertrauenswürdig ist, nicht was einzelne Pods darin tun.
• Confidential Containers: Jeder Pod läuft in seiner eigenen, unabhängigen verschlüsselten Micro-VM, getrennt von den Kubernetes-Prozessen des Nodes und von anderen Pods. Remote Attestation lässt sich für jeden Pod einzeln durchführen.

Das Fazit des Beitrags ist eindeutig: Nur die Isolation auf Pod-Ebene entfernt Kubernetes vollständig aus der Vertrauensbasis ("Trusted Computing Base"), funktioniert mit Managed Kubernetes und macht Remote Attestation auf Workload-Ebene möglich. Bei Node-Ebene-Isolation bleiben die Kubernetes-Verwaltungsprozesse im selben Schutzbereich wie die Pods und damit faktisch mit Zugriff auf sie. Der Infrastrukturbetreiber bleibt so weiterhin Teil der Vertrauensbasis.

Workload-basierte Isolation mittels Confidential Containers ist somit die einzige Option, die einen echten Betreiberausschluss liefert.

Bare Metal, vorerst

Confidential Containers lassen sich auf drei Arten betreiben:

• direkt auf Bare-Metal-Nodes
• über "Nested Virtualization" innerhalb einer virtualisierten Umgebung
• über die Hypervisor-API eines Infrastrukturbetreibers

Nur Bare Metal ist heute produktionsreif und bereits bei einigen Managed-Kubernetes-Angeboten verfügbar. Nested Virtualization gilt langfristig als der wahrscheinliche Gewinner, steckt aber noch in einem frühen Stadium. Der Weg über die Hypervisor-API bietet derzeit keine vollständige Remote Attestation, weshalb ein vollständiger Betreiberausschluss dort bislang nicht möglich ist.

Einsatz in der Praxis: Frontier-KI Modelle via Privatemode AI

Der zweite Teil des Beitrags überträgt das Vorangegangene auf Privatemode AI. Bei Privatemode verifiziert ein lokaler Proxy initial jede serverseitige Komponente. Danach handelt der Proxy einen kryptographischen Schlüssel mit der Serverseite aus. Auf der Serverseite erhalten nur solche Confidential Containers Zugang zu dem Schlüssel, die zuvor ihre eigene Integrität gegenüber einem zentralen Verwaltungsdienst mittels Remote Attestation nachgewiesen haben. Die Inferenz selbst läuft vollständig innerhalb von Confidential Containers unter Einbindung von NVIDIA GPUs mit aktiviertem Confidential-Computing-Modus.

Das Ergebnis ist so ausgelegt, dass weder der Infrastrukturbetreiber noch Edgeless Systems auf Prompts oder Antworten zugreifen können.

Der vollständige Beitrag

Der vollständige Beitrag erklärt die Architektur, die Abwägungen zwischen den drei Umsetzungsvarianten und das komplette Privatemode-AI-Design im Detail. Zu finden ab Seite 82 im Tagungsband des 21. Deutschen IT-Sicherheitskongresses.