Confidential Containers kapselt Pods in vertraulichen virtuellen Maschinen, sodass Cloud-native Workloads mit nur minimalen Änderungen vertrauliche Computing-Hardware nutzen können. Mehr dazu in diesem Fachbeitrag von Kubermatic…
Hintergrund
Das Projekt Confidential Containers (CoCo) der CNCF erweitert die Garantien des vertraulichen Computings auf komplexe Workloads. Sensible Workloads sollen auf nicht vertrauenswürdigen Hosts ausgeführt und vor kompromittierten oder böswilligen Benutzern, Software und Administratoren geschützt werden können. Stichwort: Confidential Computing mit Cloud-nativen Architekturen kombinieren.
Projekt Confidential Containers (CoCo) begegnet dieser Herausforderung mit einer hardwaregestützten Sicherheitsschicht, die Plattformingenieure automatisieren können, wodurch die Einhaltung von Sicherheitsvorschriften für Entwickler vereinfacht und der Betriebsaufwand für SRE-Teams reduziert wird. Sebastian Scheele, CEO von Kubermatic, einem deutschen Experten für Kubernetes Management (1), erläutert hier das Projekt „Confidential Containers“ für Sie und liefert einen Leitfaden für Plattformingenieure (Stand Nov. 2025):
„Da Unternehmen zunehmend auf Cloud-Infrastrukturen und geteilte Umgebungen setzen, ist die Sicherung von Daten während ihrer Verarbeitung zu einem wichtigen Sicherheitsanliegen geworden. Warum es Daten während der Nutzung zu schützen gilt. Bei der Datensicherheit konzentriert man sich traditionell auf zwei Zustände:
Ruhende Daten (Langzeitspeicherung) und Daten während der Übertragung (Netzwerkverkehr). Für diese Zustände gibt es ausgereifte, oft sofort einsatzbereite Lösungen, wie TLS für die Übertragung und Speicherverschlüsselung für ruhende Daten.
Der dritte Zustand – Daten während der Nutzung – wird jedoch oft übersehen. Zur Laufzeit werden die Anwendung sowie die von ihr verarbeiteten Daten in den Speicher einer Infrastruktur geladen, die möglicherweise nicht dem Benutzer gehört (z. B. gemietete Cloud-Server).
Die zentrale Bedrohung, die Confidential Computing zu neutralisieren versucht, ist der Speicherauszug. Ein böswilliger oder kompromittierter Cloud-Administrator, der Zugriff auf das Gerät hat, kann einen Speicherauszug der verarbeitenden Anwendung erstellen und so möglicherweise sensible Daten im Klartext einsehen, was zu einer Datenverletzung führen kann. Das primäre Ziel von Confidential Computing ist es, die Vertraulichkeit und Integrität von Daten zu gewährleisten, insbesondere während ihrer Verarbeitung.
Isolierung auf Hardwareebene mit TEEs
Confidential Computing stützt sich auf spezielle Prozessortechnologie, um dieses Problem zu lösen. Die Kerntechnologie ist die Trusted Execution Environment (TEE). Eine TEE kann als „sicherer Raum” oder „verschlüsselter Tresor” innerhalb des Hauptprozessors betrachtet werden, der dafür ausgelegt ist, Code auszuführen und Daten isoliert vom Rest des Systems zu verarbeiten.
Das Hauptmerkmal der TEE ist der verschlüsselte Speicher. Selbst wenn ein kompromittierter Administrator erfolgreich einen Speicherauszug der Anwendung ausführt, sieht er nur verschlüsselte Zeichen, nicht die tatsächlichen Klartextdaten. Die innerhalb der TEE ausgeführte Anwendung kann jedoch die unverschlüsselten Daten verarbeiten und anzeigen.
Während frühe TEE-Angebote prozessbasiert waren, sind moderne TEEs oft auf VM-Ebene verfügbar. VM-basierte TEEs sind beliebter, da sie den Transfer von Anwendungen zwischen verschiedenen Infrastrukturanbietern erleichtern.
Attestierung: Aufbau kryptografischer Vertrauenswürdigkeit
TEEs werden nicht blind vertraut, sondern sind attestierbar. Bei der Erstellung eines TEE stellt der Hardware-Anbieter einen Attestation Report bereit, der eine erste Messung der Hardware enthält. Anwendungsbesitzer müssen diesen Bericht nehmen und ihn bei einem Attestierungsservice beglaubigen lassen. Dies bietet eine kryptografische Garantie dafür, dass das TEE nicht manipuliert wurde. Sensible Codes oder Daten werden erst nach bestandener Überprüfung an das TEE weitergegeben.
Vorstellung des Confidential Containers (CoCo)-Projekts
Confidential Containers (CoCo) ist ein CNCF-Projekt, das den erforderlichen Software-Stack bereitstellt, um vertrauliche Workloads effektiv auf Kubernetes auszuführen. Der zentrale Ansatz von CoCo besteht darin, jeden Kubernetes-Pod in seiner eigenen vertrauenswürdigen Ausführungsumgebung zu kapseln. Dadurch wird der für die Workload erforderliche Vertrauensbereich drastisch eingeschränkt. Für Entwickler erfordert die Ausführung einer vertraulichen Workload nur minimale Änderungen am bestehenden Kubernetes-Workflow. Die einzige erforderliche Änderung besteht darin, den entsprechenden runtimeClassName in der Deployment- oder Pod-Definition anzugeben.
Funktionsweise im Hintergrund
Die CoCo-Komponenten übernehmen die Schwerarbeit:
Der CoCo-Operator: Der Confidential Container Operator (CC Operator) liest eine benutzerdefinierte Ressource (CC Runtime) und ist dafür verantwortlich, bestimmte Laufzeitklassen basierend auf der zugrundeliegenden Hardware verfügbar zu machen. Er verwaltet die Konfiguration auf der Ebene der Container-Laufzeit (z. B. ContainerD), lädt Binärdateien wie den Kata Shim herunter und aktualisiert die Konfigurationen der Container-Laufzeit.
Kata und MicroVMs: CoCo nutzt Kata, ein Open-Source-Projekt, das Pods innerhalb von MicroVMs ausführt – abgespeckte, auf Container optimierte Barebone-VMs. Im Fall von CoCo wird die MicroVM von Hardware virtualisiert, die Confidential Computing unterstützt, wodurch der gesamte Pod effektiv in einem TEE platziert wird.
Innerhalb des TEE werden wichtige Gastkomponenten bereitgestellt, darunter der Kata Agent (Workload-Management), der Attestation Agent (zur Verifizierung) und der Confidential Data Hub (CDH, zur Schlüssel- und Geheimnisverwaltung).
Verwendung der Public Cloud mit dem Peer-Pod-Ansatz
Eine häufige Herausforderung für Plattformingenieure ist die Bereitstellung von TEEs in Public-Cloud-Umgebungen, in denen die Kubernetes Worker Nodes selbst Standard-VMs ohne direkte Unterstützung für Confidential Computing sind. CoCo löst dieses Problem mit dem Peer Pod- oder Cloud-API-Adapter-Ansatz.
In diesem Modell wird die Virtualisierungsschicht des Nodes durch den Cloud-Anbieter ersetzt. Anstatt dass die Kata-Laufzeitumgebung mit einem lokalen Hypervisor auf dem Worker Node kommuniziert, kommuniziert sie mit einem Cloud API Adaptor (bereitgestellt von CoCo).
Der Adaptor stellt dann die vertrauliche MicroVM unter Verwendung der TEE-fähigen Hardware des Cloud-Anbieters bereit (z.B. AWS EC2 M6A-Instanzen mit AMD SEV-SNP). Der Rest des Workflows – einschließlich der Beglaubigung und der Interaktionen mit KBS – bleibt unverändert.
Siehe auch externe links > https://aws.amazon.com/de/ec2/instance-types/m6a/. // https://www.amd.com/en/developer/sev.html
Lazy Attestation und Schlüsselverwaltung
Für SREs und Sicherheitsspezialisten ist es wichtig, den Workflow für die Abfrage geheimer Daten zu verstehen, da er bestätigt, dass keine Daten ohne Überprüfung verarbeitet werden.
CoCo nutzt Lazy Attestation, was bedeutet, dass der Attestierungsprozess nur dann ausgelöst wird, wenn ein Geheimnis (z. B. ein verschlüsselter Container-Image-Schlüssel, Anmeldedaten einer Datenbank, aus der sensible Daten zur Verarbeitung gelesen werden, etc.) tatsächlich benötigt wird. Der wesentliche Workflow sieht wie folgt aus:
- Anforderung: Der Kata-Agent oder die Anwendung fordert ein Geheimnis über den Confidential Data Hub (CDH) an, der innerhalb des Gast-TEE ausgeführt wird.
- Attestierungs-Trigger: Der CDH benachrichtigt den Beglaubigungsagenten, die Beglaubigungsanforderung auszulösen.
- Einreichung des Berichts: Der Beglaubigungsagent sendet den Beglaubigungsbericht des TEE an den Key Broker Service (KBS). Der Standort des KBS wird über Initialisierungsdaten in der Pod-Anmerkung bereitgestellt.
- Verifizierung: Der KBS sendet den Bericht an einen Attestation Service, um zu bestätigen, dass das TEE echt und unverfälscht ist („Verifizierungsprüfung bestanden“).
- Freigabe des Schlüssels: Erst nach erfolgreicher Verifizierung gibt der KBS den Verschlüsselungsschlüssel an die Anwendung oder den Agenten innerhalb des TEE zurück.
Dieser Prozess stellt sicher, dass sensible Daten nur an verifizierte sichere Umgebungen weitergegeben werden.
Reduced Trusted Compute Base (TCB)
Für Enterprise Architects und SREs besteht der wichtigste Sicherheitsvorteil von Confidential Containers in der drastischen Reduzierung der Trusted Compute Base (TCB). Die TCB ist definiert als die Gesamtheit aller Hardware-, Software- und Firmware-Komponenten, denen eine Anwendung implizit vertrauen muss.
In einer herkömmlichen Kubernetes-Bereitstellung ist die TCB hoch: Die Anwendung vertraut dem Host-Betriebssystem, dem Kernel, Containerd, Kubelet und verschiedenen Host-Komponenten verschiedener Anbieter des Worker Nodes. Wenn eine dieser Komponenten kompromittiert wird, kann auch die Anwendung kompromittiert werden.
Mit CoCo vertraut die Anwendung nicht mehr dem Worker Node, auf dem sie ausgeführt wird. Die TCB wird auf die spezielle Hardware reduziert, die die TEE bereitstellt, und auf die minimalen Softwarekomponenten, die innerhalb dieser TEE ausgeführt werden (wie CDH und Kata Agent).
Selbst das Container-Image wird direkt in die vertrauenswürdige Ausführungsumgebung gezogen und nicht auf den nicht vertrauenswürdigen Node. Durch diese Verlagerung liegt die Vertrauensbasis in erster Linie auf der Hardware selbst, die wesentlich schwerer zu kompromittieren ist als Software.
Betriebliche Überlegungen
Obwohl dies enorme Sicherheitsvorteile bietet, sollten Plattformingenieure zwei wichtige Auswirkungen auf die Leistung beachten:
- Die Startzeit verlängert sich, da die microVM bereitgestellt und gestartet werden muss, bevor der Pod ausgeführt werden kann.
-
Die Auswirkungen auf die Netzwerkleistung variieren je nach Umgebung, aber in den meisten Fällen beträgt der Overhead weniger als zehn Prozent.
Fazit: Die Sicherheit skalieren, nicht das Team
Confidential Containers sind für Unternehmen unerlässlich, die mit hochsensiblen Daten oder strengen regulatorischen Anforderungen zu tun haben, wie z. B. der Einhaltung des DORA (Digital Operational Resiliency Act) für Finanzunternehmen, die den Schutz der verwendeten Daten benötigen, oder dem Schutz proprietärer Daten, die in modernen KI/ML-Workloads verwendet werden.
Durch die Implementierung und Automatisierung des CoCo-Stacks bietet das Plattformteam eine unglaublich leistungsstarke, hardwaregestützte Sicherheitsgarantie als einfache Self-Service-Option (lediglich runtimeClassName) für Entwickler.
Hochgradig automatisierte Sicherheit und Compliance ermöglichen es Entwicklern, schnell Innovationen zu entwickeln, ohne jemals die Integrität und Vertraulichkeit der verarbeiteten Daten zu beeinträchtigen. Mit der Kubermatic Kubernetes Platform (KKP) lassen sich vertrauliche Workloads auf dem Cloud-Anbieter der Wahl bereitstellen.“
(1) Im Bild: Sebastian Scheele, CEO von Kubermatic (Bildquelle: Kubermatic).
Querverweis:
Unser Beitrag > Was ist Infrastructure Platform Engineering (IPE) und welche Rolle spielt Kubernetes?
Unser Beitrag > Red Hat Update Nov. 2025: Neuerungen bei Enterprise Linux, KI, Virtualisierung und souveräner Cloud
Unser Beitrag > Neue Docker-Funktionen zur Entwicklung KI-gestützter Agentenanwendungen