Vertrauliche Container verändern das Sicherheitsmodell von Kubernetes: Schutz von Daten in Verwendung (data in use) ohne Vertrauen in die Plattform und Administratoren.
Das Problem zeigt sich nicht auf der Ebene der Netzwerkisolierung oder RBAC. Es geht tiefer — um das Vertrauen in die Laufzeitumgebung selbst. In klassischem Kubernetes wird angenommen, dass Clusteradministratoren und Infrastruktur vertrauenswürdig sind. Doch beim Umgang mit sensiblen Daten, insbesondere in AI-Workloads, bricht diese Annahme zusammen. Daten können „auf der Festplatte“ und „im Transit“ geschützt werden, bleiben jedoch anfällig „in Verwendung“ (data in use), das heißt im Speicher der Anwendung. Dies wird zum Engpass für Szenarien mit Anforderungen an Datensouveränität und Zero Trust.
Die Lösung, die sich in der Industrie herausbildet, ist confidential computing. Im Kontext von Kubernetes wird dies durch vertrauliche Container umgesetzt. Der Ansatz basiert auf der Idee: weder der Plattform, noch den Kubernetes-Administratoren, noch sogar dem Host zu vertrauen. Stattdessen überprüft das System die Integrität der Umgebung durch Attestation, bevor es Zugriff auf Geheimnisse gewährt. Dies ist ein Kompromiss zwischen Sicherheit und betrieblicher Komplexität. Wir erhalten ein strengeres Vertrauensmodell, zahlen jedoch mit einer Komplexität des Stacks: Es entsteht eine Abhängigkeit von TEE (trusted execution environment), zusätzlichen Diensten und einer Verifizierungskette.
Die Implementierung in OpenShift zeigt, wie dieses Modell in der Praxis ankommt. Die Architektur trennt Rollen und Cluster: Es gibt eine „vertrauenswürdige“ Umgebung, in der der Dienst Trustee läuft, und einen „nicht vertrauenswürdigen“ Cluster, in dem die vertraulichen Workloads selbst ausgeführt werden. Diese Trennung ist nicht zufällig — sie verringert den Blast Radius und definiert die Grenzen des Vertrauens. Die Installation beginnt mit Operatoren und Konfiguration, wobei der Cluster absichtlich ohne vorinstallierte Komponenten bereitgestellt wird. Dieser Ansatz hilft, Abhängigkeiten und Kontrollpunkte des Systems klar zu erkennen.
Dann kommt das Interessanteste: das Verhalten der Anwendungen. Das grundlegende Szenario ist das „Blackbox-Deployment“. Ein Container mit AI-Workload (zum Beispiel Betrugserkennung) wird unverändert gestartet, erhält jedoch eine zusätzliche Schutzschicht — die Verschlüsselung des Speichers. Aus Sicht der Kubernetes-Ressourcen ändert sich nichts. Dies ist ein wichtiger Punkt: Vertrauliche Container erfordern keine Neuprogrammierung der Anwendung. Sie verändern die Ausführungsumgebung.
Die nächste Stufe — die Arbeit mit externen Daten. In der traditionellen Modell lädt der Pod einen verschlüsselten Datensatz und erhält den Entschlüsselungsschlüssel über einen Init-Container oder Clustergeheimnisse. Das bedeutet, dass Administratoren potenziell Zugriff auf den Schlüssel haben. Im Modell der vertraulichen Container wird der TEE-Stack und der Dienst Trustee hinzugefügt. Der Schlüssel wird nur nach erfolgreicher Attestation ausgegeben. Wenn die Umgebung kompromittiert ist oder nicht dem erwarteten Zustand entspricht — wird der Schlüssel nicht übergeben. Dies verlagert die Kontrolle von Kubernetes auf eine kryptografisch überprüfbare Vertrauenskette.
Ein weiteres Szenario sind sealed secrets. In gewöhnlichem Kubernetes sind Geheimnisse über die API zugänglich und können bei Vorliegen der Berechtigungen abgerufen werden. In vertraulichen Containern wird ein Mechanismus verwendet, bei dem das Geheimnis tatsächlich nicht im Cluster im Klartext gespeichert wird. Es wird während des Starts des Containers nach Überprüfung der Umgebung über Trustee eingefügt. Dieser Prozess wird von Komponenten innerhalb der Gast-Linux-Umgebung des Containers initiiert. Infolgedessen existiert das Geheimnis nur innerhalb der vertrauenswürdigen Ausführungsgrenze.
Was ändert sich letztendlich? Das Isolationsniveau wird näher an virtuelle Maschinen herangeführt, behält jedoch das Modell der Container bei. Dies ist eine Kompromisslösung zwischen Sicherheit und Benutzerfreundlichkeit der Orchestrierung. Leistungskennzahlen oder Latenzen im Ausgangsmaterial werden nicht angegeben, daher ist eine Bewertung der Overheadkosten unmöglich. Aber architektonisch ist offensichtlich: Die Hinzufügung von TEE und Attestation erhöht die Komplexität und kann potenziell die Startzeit und den Durchsatz beeinflussen.
Der praktische Wert des Ansatzes liegt in der Verringerung des Vertrauens in die Infrastruktur. Dies ist besonders relevant für Hybrid-Cloud- und Edge-Szenarien, in denen die Kontrolle über die Umgebung eingeschränkt ist. Gleichzeitig senkt Tooling wie die Red Hat Demo Platform die Eintrittsbarriere: Eine fertige Infrastruktur ermöglicht es, das Verhalten des Systems zu untersuchen, ohne einen Cluster von Grund auf neu aufzubauen. Dies macht die Technologie zugänglicher, beseitigt jedoch nicht ihre grundlegende Komplexität.
Vertrauliche Container sind nicht „einfach nur ein weiterer Runtime“. Dies ist ein Wandel im Vertrauensmodell von Kubernetes. Und wie jeder Wandel erfordert er eine Neubewertung der gewohnten Annahmen darüber, wo genau die Kontrolle endet und das Risiko beginnt.