Wer überprüft den Verifizierer? Aufbau von überprüfbarem Vertrauen in Confidential Containern

In unserer Architekturübersicht, Vertrauliches Rechnen für datenschutzfreundliche KI haben wir die übergeordnete Vertrauensarchitektur der Plattform beschrieben. Dieser Beitrag konzentriert sich auf einen engeren Teilbereich davon.

Wir haben die Technologien von Confidential Containers aufmerksam verfolgt. Da diese Technologien in den letzten Jahren deutlich ausgereifter geworden sind, haben wir untersucht, wie sich dieselben Prinzipien auf die Workloads in unserem OpenShift-Cluster anwenden lassen. Die Anwendung dieser Technologien auf unsere KI-Produkte wurde dabei zu einer besonderen Priorität. Unsere Tests führten wir durch eine Zusammenarbeit mit IBM Research. Das Projekt begann letztes Jahr und läuft noch. Im Zuge der Weiterentwicklung kristallisierte sich die zentrale Frage heraus: Kann eine Workload, die auf einem OpenShift-Cluster läuft, ihre Identität kryptografisch – mit hardwaresignierten Nachweisen und ohne Hintertür für Administratoren – beweisen, bevor sie Zugriff auf sensible Ressourcen erhält? Und lassen sich diese Entscheidungen durch Attestierung und Richtlinien statt durch administrative Berechtigungen durchsetzen, sodass Geheimnisse innerhalb der Workloads selbst geschützt bleiben?

In diesem Beitrag geht es um genau diese Frage – darum, wie wir Confidential Computing, ein sensibles Thema für uns seit den Anfängen des Unternehmens, über VMs hinaus in Container mit Kata übertragen haben.

Wir nutzen Trusted Execution Environment (TEE)-Technologien, um vertrauliche VMs auszuführen, deren Speicher hardwareseitig verschlüsselt und für den Hypervisor, das Host-Betriebssystem und alle Serveradministratoren unlesbar ist. Dies schützt …Daten in Verwendung: der Moment, in dem Daten im Speicher entschlüsselt werden, um verarbeitet zu werden.

Speicherverschlüsselung allein beantwortet die eigentliche Frage nicht; sie ist lediglich der erste Schritt, und die eingangs aufgeworfene Frage reicht darüber hinaus. Eine vertrauliche VM, die mit dem falschen Kernel, einem manipulierten Boot-Image oder einer unerwarteten Konfiguration läuft, verschlüsselt ihren Speicher genauso – und moderne TEEs schützen sogar die Integrität dieses Speichers, sodass er nicht unbemerkt verändert werden kann. Die Integrität des Speichers ist jedoch nicht dasselbe wie die Integrität der Arbeitslast: Verschlüsselung und Integritätsschutz gewährleisten, dass der Bediener die verwendeten Daten weder lesen noch manipulieren kann – nicht aber, ob die Arbeitslast der erwarteten entspricht. Diese letzte Frage betrifft die Attestierung.

Eine vertrauliche VM ist nicht automatisch eine vertrauenswürdige Arbeitslast. Erst wenn wir dies durch Remote-Attestierung korrekt nachweisen können, können wir überhaupt von Vertrauen sprechen. Die TEE erzeugt hardwaresignierte Nachweise ihres Zustands; ein Verifizierer validiert die Vertrauenskette und vergleicht die Nachweise mit bekannten, gültigen Referenzwerten; Geheimnisse werden nur freigegeben, wenn sie übereinstimmen.

Ohne Referenzwerte wären alle korrekt signierten Attestierungsberichte gleichermaßen gültig – auch solche von modifizierten Kerneln oder unerwarteten Arbeitslasten. Die Nachweise bestätigen eine Reihe von Messwerten, die den TEE-Zustand repräsentieren. Die Referenzwerte sind vertrauenswürdige Messwerte, und die Richtlinien gleichen diese ab, um zu prüfen, ob sich der TEE im erwarteten Zustand befindet, bevor das angeforderte Geheimnis freigegeben wird.

Dies macht Vertrauen explizit und überprüfbar, indem es auf messbare Komponenten reduziert wird: die Hardware-Vertrauensgrundlage, die Bestätigungsnachweise, die zum Vergleich verwendeten Referenzwerte und die Richtlinien zur Bestätigung des TEE-Zustands. Ohne gültigen Beweis keine Geheimnisse.

Das Confidential Containers (CoCo)-Ökosystem, auf dem wir aufbauen, umfasst TreuhänderEs handelt sich um ein Open-Source-Projekt, das verschiedene Dienste für die Attestierung und Freigabe von Geheimnissen bündelt. Hier befindet sich das Herzstück des Prozesses. Der signierte Attestierungsbericht und seine Zertifikatskette belegen zwar, dass die Messungen von einer authentischen TEE-Plattform stammen, reichen aber allein nicht aus, um Vertrauen in die Workload herzustellen. Der Attestierungsagent im Gastsystem übermittelt seine Nachweise an den Key Broker Service (KBS) – den Einstiegspunkt –, der sie zur Verifizierung an den Attestierungsdienst (AS) weiterleitet. Der AS prüft die Authentizität der Nachweise, vergleicht die Messungen mit vertrauenswürdigen Referenzwerten des Reference Value Provider Service (RVPS) und wertet sie anhand der Attestierungsrichtlinie aus. Das Ergebnis wird an den KBS zurückgesendet, der daraufhin seine eigene Ressourcenrichtlinie anwendet, um zu entscheiden, welche Geheimnisse diese Workload gegebenenfalls erhalten darf. Das angeforderte Geheimnis wird nur freigegeben, wenn sowohl die Attestierung als auch die Auswertung der Ressourcenrichtlinie erfolgreich sind.

Die Komponenten:

• Attestierungsdienst (AS)— prüft die Echtheit der Nachweise und bestätigt sie gemäß der Attestierungsrichtlinie.
• Referenzwertanbieterdienst (RVPS)— enthält die vertrauenswürdigen Referenzwerte, mit denen die Ergebnisse der Arbeitslast verglichen werden, typischerweise die bekannten, guten Messwerte der TEE-Plattform und des Bootvorgangs.
• Key Broker Service (KBS)— Der Gatekeeper und Zugangspunkt. Empfängt die Nachweise vom Gast, führt die Verifizierung durch und entscheidet anhand seiner eigenen Ressourcenrichtlinie, auf welche Geheimnisse diese Arbeitslast zugreifen darf.
• Beglaubigungsbeauftragter(innerhalb der VM) — sammelt die Beweise und übermittelt sie an den KBS.
• Vertrauliches Datenportal(innerhalb der VM) — ruft die Geheimnisse ab und entpackt sie, sobald der KBS sie freigibt.

Ziel all dessen ist nicht nur die Verifizierung einer Arbeitslast, sondern die Verkürzung der Vertrauenskette: die Reduzierung der vertrauenswürdigen Akteure und der zu durchlaufenden Vertrauensebenen. Durch die Attestierung werden Host, Hypervisor und Clusterbetreiber aus der vertrauenswürdigen Computing-Basis entfernt, sodass das Vertrauen auf der Hardware-Vertrauensbasis und den von ihr signierten Nachweisen beruht – nicht mehr auf dem Plattformbetreiber.

Wir haben die konzeptionellen Elemente der Attestierung kennengelernt – Nachweise, Referenzwerte, den Verifizierer und die Komponenten, die den Nachweis erzeugen und überprüfen. Schauen wir uns nun an, wo diese Elemente in einem OpenShift-Cluster konkret implementiert sind.

Kata Containers verlagert die Isolationsgrenze vom gemeinsam genutzten Kernel auf eine ressourcenschonende VM pro Pod mit eigenem Kernel. Sie behalten die gewohnte Kubernetes-Pod-Funktionalität, profitieren aber zusätzlich von hardwarebasierter Isolation. kata-cc ist die vertrauliche Variante: Die VM pro Pod wird als vertrauliche VM auf TEE-Hardware (z. B. AMD SEV-SNP oder Intel TDX) gestartet, wodurch Sie hardwareverschlüsselten Speicher und einen verifizierbaren Bootvorgang erhalten.

Auf Clusterseite stellt der OpenShift-Sandboxed-Containers-Operator die kata-cc-RuntimeClass auf TEE-fähigen Worker-Knoten bereit. Das Hinzufügen einer Workload erfordert nur eine einzige Zeile Code.

Jeder Pod erhält eine eigene, vertrauliche VM, erscheint aber für den Rest des Clusters weiterhin als normaler Pod. Dadurch werden die administrative Kontrolle und die Transparenz der Workloads getrennt: Cluster-Administratoren betreiben die Plattform, das Vertrauen in die Workload-Ausführung wird jedoch durch Attestierung und Richtlinien und nicht durch Infrastrukturbesitz gewährleistet.

Die Sicherheitsabsicht ist in den Initialisierungsdaten (initdata.toml) verankert: einer gzip-komprimierten und Base64-kodierten Datei, die als Pod-Annotation angehängt wird. Sie kann eine benutzerdefinierte Kata-Agent-Richtlinie enthalten, die die standardmäßige Richtlinie des Gastsystems (die festlegt, welche Aktionen das Gastsystem dem Hostsystem erlaubt) überschreibt, die Trustee-Adresse und deren TLS-Zertifikat sowie die Image-Verifizierungsrichtlinie. Der Hash der Initialisierungsdaten wird an den Attestierungsbericht gebunden und ist Teil des bestätigten Zustands. Ein Cluster-Administrator kann die Richtlinien nicht unbemerkt ändern oder Trustee umleiten, ohne die Attestierung zu beeinträchtigen. Die Richtlinien, die das Verhalten des Gastsystems steuern, werden Teil des bestätigten Zustands und nicht nur der Laufzeitkonfiguration. Die drei enthaltenen Elemente – die Agent-Richtlinie, die Image-Richtlinie und der Trust-Anker für Trustee – markieren den Punkt, an dem die Grenze nicht mehr nur ein Diagramm, sondern auch eine tatsächliche Durchsetzung ist. Daher lohnt es sich, jedes Element einzeln zu betrachten.

Betrachten wir zunächst die Kata-Agent-Richtlinie. Der Kata-Agent fungiert als Schnittstelle zwischen Host und Workload und verwaltet den Container-Lebenszyklus, setzt Sicherheitsrichtlinien durch und überwacht Prozesse – genau wie eine herkömmliche Container-Laufzeitumgebung, jedoch isoliert in einer Mikro-VM. Genau diese API würde ein böswilliger Host ausnutzen. Daher dient die Agent-Richtlinie als Zulassungsliste: Sie legt fest, welche Agent-Anfragen der Gast akzeptiert und alle anderen ablehnt. Der wichtigste Aufruf ist `ExecProcessRequest`, der hinter `kubectl exec` und `oc exec` steckt. Ohne Einschränkungen könnte jeder mit Host-Zugriff beliebige Befehle innerhalb der vertraulichen Workload ausführen und alles lesen, was die TEE schützen soll. Daher verhindert eine vertrauliche Bereitstellung dies und blockiert ebenso das Lesen von Streams und das Mounten von Volumes, die dem Host sonst einen Zugang verschaffen würden. Die Einschränkung dieser Host-Gast-Schnittstelle ist keine optionale Sicherheitsmaßnahme; sie verhindert, dass der Host angegriffen wird.

Die Richtlinie zur Image-Verifizierung ist der zweite Baustein und der Punkt, an dem das Vertrauen in die Lieferkette ins Spiel kommt. Ein signiertes Image ist eine kryptografische Garantie dafür, dass es seit seiner Erstellung und Signierung durch eine vertrauenswürdige Partei nicht verändert wurde – die Signatur stellt die Verbindung des laufenden Codes zu seinem Ursprung her. Die Richtlinie selbst – welche Signaturen und Signaturschlüssel als gültig gelten – ist in den Initialisierungsdaten (initdata) enthalten; die darin beschriebene Prüfung wird innerhalb des Gastsystems beim Abrufen des Images ausgeführt. Bevor eine Arbeitslast in der TEE (Third-Event Environment) gestartet wird, ruft die Laufzeitumgebung des Gastsystems das Image ab und verifiziert dessen Signatur anhand dieser Richtlinie. Fehlt die Signatur oder ist sie ungültig, wird der Start abgebrochen. Da die Richtlinie in den Initialisierungsdaten enthalten ist, ist ihr Hash bereits Teil des bestätigten Zustands. Ein Betreiber kann die Regeln daher nicht stillschweigend lockern, um ein unsigniertes Image zuzulassen, ohne die Bestätigung zu verletzen. Die Tatsache, dass die Durchsetzung innerhalb des Gastsystems erfolgt, macht die Technologie robust: Selbst eine kompromittierte Registry nützt einem Angreifer nichts, da ein Ersatzimage nicht die von der Richtlinie geforderte Signatur besitzt und daher vor der Ausführung abgelehnt wird. Die TEE isoliert die Arbeitslast; die Signaturprüfung ist der Softwaremechanismus, der von vornherein sicherstellt, dass es sich um die richtige Arbeitslast handelt.

Dieselbe Grenze muss auch auf der Netzwerkschicht gelten, und hier kann sie leicht überschritten werden. Der Datenverkehr zu allen als vertrauliche Arbeitslast ausgeführten Prozessen muss entschlüsselt werden.innenDie TEE (Trustee Execution Environment) muss direkt durchgeleitet werden, nicht davor. Auf OpenShift bedeutet dies, dass die Route oder der Ingress vor dem Pod die verschlüsselte Verbindung direkt weiterleiten muss – SSL-Passthrough –, sodass TLS innerhalb des Gastsystems terminiert wird. Wenn die Route/der Ingress TLS stattdessen am Edge beendet (oder auf dieser Ebene erneut verschlüsselt), wird der Datenverkehr auf dem nicht vertrauenswürdigen Worker-Knoten – außerhalb der bestätigten Grenze – in Klartext entschlüsselt. Dadurch erhält jeder mit Zugriff auf diesen Knoten Einblick in genau die Daten, die die TEE eigentlich schützen sollte. Beim Passthrough existiert der Klartext niemals außerhalb der vertraulichen VM. Diese Regel gilt nicht nur für bestimmte Workloads, sondern für jeden vertraulichen Endpunkt, einschließlich Trustee.

Wir haben die Richtlinien bereits in ihrer konkreten Form kennengelernt – die Agentenrichtlinie und die in den Initialisierungsdaten enthaltene Bildrichtlinie. Betrachtet man diese Beispiele aus einer übergeordneten Perspektive, so zeigt sich ein allgemeines Muster: Alles bisher Erreichte führt zu einem Ergebnis und einer Reihe von Ansprüchen, wobei ein Anspruch allein keine Wirkung hat. Erst die Richtlinie macht aus einem Anspruch eine Entscheidung. Systemweit ist sie an drei Stellen implementiert – zweimal im Trustee und einmal im Gastsystem.

AttestierungsrichtlinieDie Richtlinie ist im Attestierungsdienst implementiert und definiert, wie Attestierungsansprüche bewertet werden und welche Bedingungen erfüllt sein müssen, damit eine Arbeitslast als vertrauenswürdig gilt. Messwerte und Referenzwerte sind in der Regel die wichtigsten Eingabeparameter, aber nicht die einzigen Ansprüche, die eine Richtlinie auswerten kann. Bei den meisten Implementierungen wird mehr Aufwand in die Verwaltung von Referenzwerten als in die Entwicklung des Richtliniencodes investiert. Die Richtlinie beschreibt die Logik; Referenzwerte definieren den Zustand, den diese Logik auswertet.

RessourcenpolitikDer Key Broker Service (KBS) ist Teil des KBS und beantwortet eine andere Frage: Auf welche Geheimnisse darf eine als vertrauenswürdig eingestufte Workload zugreifen? Der KBS fungiert als Durchsetzungsstelle für Richtlinien. Nach erfolgreicher Attestierung entscheidet seine Ressourcenrichtlinie, welche geschützten Ressourcen für diese Workload freigegeben werden. In der Praxis legt der KBS auch die Vorgehensweise einer Bereitstellung fest – von einer permissiven Richtlinie, die in der Entwicklungsumgebung uneingeschränkten Zugriff ermöglicht, bis hin zu einer strengen, feingranularen Richtlinie, die in der Produktionsumgebung jede Ressource schützt.

Die dritte Schicht haben wir bereits aus der Nähe betrachtet:die von dem Kata-Agenten durchgesetzte GästerichtlinieInnerhalb der vertraulichen VM – die Richtlinie, die die vom Agenten bereitgestellte Host-Gast-RPC-Schnittstelle steuert. ExecProcessRequest (hinter oc exec) ist der offensichtliche Aufruf, der blockiert werden sollte, aber nicht der einzige relevante: ReadStreamRequest würde dem Host ermöglichen, die Standardausgabe/Standardfehlerausgabe eines Containers zu lesen, Volume-Mount-Aufrufe könnten vom Host kontrollierten Speicher in den Gast einbinden, und SetPolicyRequest ist der subtilere Fall – wenn Richtlinienaktualisierungen zulässig sind, könnte ein Host die Richtlinie schwächen, bevor er ansonsten eingeschränkte Operationen ausführt. Die Richtlinie muss all diese Fälle berücksichtigen. Durch die Benennung hier wird sie neben die beiden anderen gestellt: Die Attestierungsrichtlinie entscheidet, ob die Arbeitslast vertrauenswürdig ist, die Ressourcenrichtlinie legt fest, welche Ressourcen eine vertrauenswürdige Arbeitslast freigeben darf, und die Gastrichtlinie regelt, welche Anfragen der Host an die Arbeitslast während der Ausführung stellen darf. Die Einschränkung dieser Host-Gast-Schnittstelle ist keine optionale Sicherheitsmaßnahme; sie ist Teil des gesamten Sicherheitsmodells.

Ein Detail verknüpft die Richtlinie mit der Hardware: Konfigurationen lassen sich in den beim Start gemessenen Zustand einbinden, und die daraus resultierenden Attestierungsansprüche können anschließend innerhalb der Richtlinie ausgewertet werden. So kann eine Richtlinie nicht nur darauf bestehen, dass es sich um einen gültigen SEV-SNP-Gast handelt, sondern dass es sich um einen gültigen SEV-SNP-Gast handelt, der mit genau dieser Konfiguration gestartet wurde.

Bisher ging es vor allem darum, Vertrauen zu stärken: Die Attestierung schließt Host und Hypervisor aus, Initdata bindet Agenten- und Image-Richtlinien in den gemessenen Startvorgang ein, und jedes Geheimnis wird durch ein von Trustee erzeugtes Ergebnis geschützt. Wir haben sogar festgestellt, dass die Regel, TLS innerhalb der Grenzen zu halten, für Trustee genauso gilt wie für die Workloads. All das läuft auf eine einzige Komponente hinaus. Trustee entscheidet, ob alles andere vertrauenswürdig ist – daher die berechtigte Frage: Wo läuft Trustee, und wer schützt es?

Ein Verifizierer erbt die Sicherheitslücken der Umgebung, in der er ausgeführt wird. Wird er in einer Umgebung eingesetzt, die beliebig gelesen, verändert oder neu gestartet werden kann, erbt die gesamte Vertrauenskette diese Schwachstelle – unabhängig davon, wie solide die darüber liegende Attestierungslogik ist. Die Frage ist daher nicht nur, wie Trustee Workloads verifiziert, sondern auch, was Trustee selbst ein unerschütterliches Fundament verleiht.

Unsere Grundlage bildet IBM Hyper Protect, basierend auf IBM LinuxONE Secure Execution auf s390x – einer seit Jahren bewährten Technologie für vertrauliches Computing, die bereits den Kern unseres Schlüsselmanagements bildet. Sie ist eines unserer stärksten Fundamente: eine hardwarebasierte, vertragsgesteuerte Umgebung, in die selbst der Betreiber keinen Zugriff hat. Indem wir die Vertrauensbasis von Trustee dort verankern, übertragen wir diese Stärke auf die Komponente, die sie am dringendsten benötigt. Die Verankerung einer so kritischen Komponente wie Trustee in Hyper Protect macht eine nahezu unzerbrechliche Vertrauenskette aus.

Das Prinzip ist einfach: Die Komponente, der man am meisten vertrauen muss, erhält den besten Schutz – und für uns ist dieser Schutz IBM LinuxONE Secure Execution, die gleiche Grundlage, auf der unser Schlüsselmanagement bereits basiert.

Um das zu verdeutlichen, stellen Sie sich einen Cluster-Administrator vor, der den Inhalt einer vertraulichen Workload auslesen möchte – nicht etwa ein externer Angreifer, sondern jemand mit voller Kontrolle über die Plattform. Die Speicherverschlüsselung verhindert den Zugriff auf den RAM der VM, daher versucht er es stattdessen auf dem Host: Er führt `oc exec` im Pod aus. Die Kata-Agent-Richtlinie listet `ExecProcessRequest` nicht auf, daher wird die Anfrage an der Gastgrenze abgelehnt. Gut – er bearbeitet die Initialisierungsdaten, um die Anfrage zuzulassen. Da der Hash der Initialisierungsdaten jedoch in die Startmessung einfließt, bestätigt die VM nun einen anderen Zustand, die Referenzwerte stimmen nicht mehr überein, und Trustee gibt keine Geheimnisse preis: Die Workload startet, bleibt aber gesperrt. Er versucht, das Container-Image durch ein gepatchtes zu ersetzen, das Daten an den Host sendet; die Signaturprüfung im Gastsystem lehnt dies jedoch ab, bevor die Workload ausgeführt werden kann. Er leitet die TLS-Terminierung der Route an den Worker-Knoten weiter, um Klartext abzufangen; der Datenverkehr wurde durchgeleitet, sodass außerhalb der TEE nichts lesbar ist. Jeder Schritt wird nicht durch eine nachträglich hinzugefügte Kontrollmaßnahme vereitelt, sondern durch dasselbe Prinzip: Die Grenze wird durch Bestätigung und gemessenen Zustand gewährleistet, nicht durch die Person, die die Verwaltung innehat. Die einzige Komponente, die all dies zunichtemachen könnte – der Treuhänder – ist diejenige, die wir ihm vollständig entzogen haben.