Der Vortrag richtet sich an Plattform- und Softwareentwickler, die nutzerbezogene oder anderweitig sensible Daten in Cloud-Native-Umgebungen verarbeiten wollen. Es soll erörtert werden, inwiefern die Confidential Container-Technologie in solchen Szenarien ein brauchbares Werkzeug sein kann. Zuerst soll in die grundlegenden Konzepte von Confidential Computing eingeführt werden (Vertrauen, Integrität, “Remote Attestation”) um darauf aufbauend verstehen zu können, was “Vertraulichkeit” in Confidential Computing heißen kann und wie in Linux und Hardware umgesetzt wird (TPM, AMD SEV, Intel TDX). Das “Confidential Containers” Open-Source Project ist Teil der “Cloud-Native Computing Foundation”. Verschiedene Software-, Cloud- und Hardware-Anbieter kollaborieren in der Entwicklung einer hardware-unabhängigen Plattform, die den Einstieg oder die Migration in Confidential Computing für container-basierte Software so leicht wie möglich machen soll. Es wird gezeigt, wie nahe man diesem Ziel gekommen ist, und welche Fragen noch offen sind. Der Vortrag schließt ab mit einer praktischen Demonstration eines Confidential Containers in einer verwalteten Kubernetes-Umgebung.

1. Confidential Containers
Sensible Daten und Privatsphäre in Cloud Native Umgebungen
OS-Camp 2024-04-18

2. Hi!
magnuskulke@microsoft.com
github.com/mkulke
Magnus Kulke
SWE @Microsoft, AzCore Linux

3. Fahrplan
• Warum Confidential Containers?
• Konzepte (und Technologien)
• Demo
Am Rande: Komponenten, Architektur

4. Sales Pitch
Journey towards the Confidential Cloud
…

5. Erinnerung: VM State ist für Host transparent
VM State ~
• RAM
• CPU-Register
• Caches
- …

6. Anwendungsszenarien
• PII-Daten in Public Clouds verarbeiten
• Daten teilen
• Proprietäre ML-Modelle On-Premise betreiben
• Forschungs-Kollaboration Krankenhaus/Versicherung
• Sicherheit
• Angriffsvektoren reduzieren (Datenlecks)
• Schutz vor „lateralen“ Angriffen

7. Warum Confidential Container?
• Confidential Computing (CC) ist nicht trivial zu implementieren
• Cloud Native ist eine beliebte Plattform mit standardisierten
Interfaces und Abstraktionen
• Hoffnung: CC wird zugänglicher und gewinnt Verbreitung, wenn es
sich in Container-Umgebungen einfügt
• Anspruch: „Lift-and-Shift“ Anwendung in CC-Umgebung

8. Confidential Computing: Konzepte
• Integrity
• Trust
• Remote Attestation
=> Confidentiality

9. Integrity: Was wird ausgeführt?
• Läuft die intendierte Kombination von Code/Config/Daten?
• Ist meine Anwendung/OS/Umgebung ggf. kompromittiert?
• Measurements: „Vermessung“ von System-Komponenten mit
kryptografischen Hash-Funktionen
=> 1234abcd

10. Beispiel: Hash als Prüfsumme für Binaries
$ curl -sLO https://dl.k8s.io/release/v1.29.2/bin/linux/amd64/kubectl
$ curl -sLO https://dl.k8s.io/release/v1.29.2/bin/linux/amd64/kubectl.sha256
$ echo "$(cat kubectl.sha256) kubectl" | sha256sum –check
kubectl: OK

11. Hash-Erweiterung
>>> m = hashlib.sha256()
>>> m.update(b'value1')
>>> m.update(m.digest() + b'value2')
>>> m.hexdigest()
'5b848becb4a8d7b1515dbd43472cd3d66e7d027d83fa004d1bb158cf1a248802‘

12. Hash-Erweiterung
• Aufzeichnung einer Sequenz von Events, z.B. Linux Boot
• Eine Boot-Stage measured die darauf folgende Stage
• Deterministisch, vorhersagbar
• Ähnlich: Git, Blockchains
Firmware Bootloader Kernel Root FS
Initrd

13. Trust: Wem vertrauen?
• Vorannahme: ein System ist zunächst nicht vertrauenswürdig
• Vertrauen kann also nur in einer unabhängigen Komponente liegen
• Hardware Root of Trust (RoT) isoliert vom System: z.B. HSM oder TPM
System
RoT
Thales PCIe HSM GIGABYTE TPM 2.0 Module

14. Hardware Root-of-Trust
The general idea is to add a new chip (…) to your computer that you don’t
get to run code on.
Educated Guesswork Blog: Do you know what your computer is running?

15. Beispiel: Disk-Unlock mit TPM
• TPMs besitzen erweiterbare Hash-Register (PCRs) und können
Schlüssel versiegeln
• Boot-Prozess wird durch Measurements in PCRs festgehalten
• LUKS-Schlüssel wird entsiegelt wenn PCR-Werte Referenz-
Measurements entsprechen
• Kompromittierte Systeme (FW, Kernel, etc) booten nicht
HD
Initrd TPM
PCR0
PCR1
…
?

16. Remote Attestation
• Verifizierung und Key-Freigabe wird “ausgelagert”
• RoT Hardware liefert lediglich Messungen zum System-Zustand
(z.B. “PCR Quote”)
• RoT hat einzigartigen, geheimen, asymmetrischen Schüssel
• Messungen werden durch RoT HW kryptografisch signiert =>
Evidence
Attester
Root of Trust
Evidence
PCR0
PCR1
…
Messungen
PCR0
PCR1
…

17. Ablauf Remote Attestation (Passport Model)
• Evidence kann von entferntem, vertrautem System (Verifier)
validiert werden
• Validierung stellt fest:
• Evidence wurde von einem authentischen HW RoT generiert
• Measurements entsprechen erwarteten Referenzwerten
• Verifier stellt Token für Zugriff auf geschützte Resourcen aus
Verifier
Evidence
PCR0
PCR1
…
🪙
Token
Key Broker
Secret
Token
Attester
RoT

18. Data Center
Confidentiality: Integrity + Privatsphäre
Confidential Computing ist eine CPU Technologie, die mittels eines
HW RoT in einem Trusted Execution Environment (TEE)
Privatsphäre für deren Nutzer garantiert.
TEE

19. Confidential VMs (CVM)
• CVM wird vom Host mittels
Verschlüsselung isoliert
• Sicherheitsprozessor: Hardware RoT
• Verschlüsselung ist Eigenschaft der
Umgebung in einem TEE
Host
RAM
Cache
CPU
Secure
Processor
• Beispiele: AMD SEV-SNP, Intel TDX, ARM CCA, IBM SE

20. Launch Measurements + Remote Attestation
• VM wird mit fixem CPU + RAM State initialisiert (~ Save state )
• Measurement des initialen Zustands ist Teil des Evidence
• Sicherheitsprozessor signiert Evidence mit geheimem Schlüssel
• Verifier prüft Evidence gegen CPU Vendor Zertifikat-Ketten
• Validierung stellt zusätzlich fest:
• Evidence wurde in einem verschlüsselten TEE erzeugt
• Zusätzliche Eigenschaften: Microcode, Firmware Version, …

21. Confidential Containers?
• Integrity
• Trust
• Remote Attestation
• Confidentiality
• Containers
=> Confidential Containers
?

22. Hierarchiemodell k8s (vereinfacht)
Cloud Anbieter, Infra Op
Cluster OP
EntwicklerInnen
NutzerInnen
Privilegien
Idee: Cluster und Infra werden vor bösartigen NutzerInnen geschützt

23. CoCo Trust-Modell
Cloud Anbieter, Infra Op
Cluster OP
EntwicklerInnen
NutzerInnen
Vertrauen
Idee: Schutz der Trusted Domain, De-privilegierung der Ops

24. CVMs & Confidential Container
• Attraktivste Option: Confidential Pods mit Kata Micro VM Runtime
• Virtualisierung: bewährte, multi tenant-fähige
Isolationstechnologie (hard/hostile multi-tenancy)
• OCI Runtime Spec: Große API-Oberfläche, schwächere Isolation
(soft multi-tenancy)
Control Plane
Node
Pod
CVM Pod
Confidential
Container
Node

25. Herausforderungen für Confidential Container
Wird dem Host nicht vertraut, sind alle an den Guest weiter
gegebenen Ressourcen ggf. problematisch
Host
Pod VM
Storage
Env
Beispiele:
• Environment Vars (REDIS_HOST)
• Storage (Empty Dir)
• Config Maps (/etc/nginx)
• Image Store auf dem Host
• Laufzeit APIs (exec, cp)

26. Beispiel: Dynamik in k8s-Deployments
• Theoretisch: für jede OCI Config eigene Referenz-Measurements
• Unpraktikabel: viele Aspekte (zb. Service ENVs) sind nicht statisch
OCI config.json
{
"ociVersion": "1.0.1",
"process": {
"terminal": true,
"user": { "uid": 1000 },
"args": [ "/bin/sh" ],
"env": { "FOO": "bar" },
},
…
}
abcd1234….
hash
my-policy.rego
process.env[_].FOO == "bar"
user.uid == 1000
…
cdab3412….
hash
OCI config.json
…
verify
Lösung: Dynamik in measured Policies abbilden und
evaluieren
Nachteil: zusätzliches Tooling/Arbeit erforderlich

27. Confidential Container: Stand heute
Demo

28. Zusammenfassung
• Cloud Native ist eine attraktive Plattform für CC
• Integrity + Trust + Remote Attestation sind Schlüsseltechnologien
für CC
• Es gibt noch UX-Baustellen für Confidential Containers
Vielen Dank!

29. Links
• Confidential Containers (github.com)
• confidentialcontainers.org
• Kata Containers (github.com)
• TPM-backed Full Disk Encryption is coming to Ubuntu
• RFC 9334: Remote ATtestation procedureS (RATS) Architecture
• AMD SEV-SNP: Strengthening VM Isolation with Integrity
Protection and More
• Intel® Trust Domain Extensions (Intel® TDX)
• IBM Secure Execution for Linux