Kubernetes Secure Enclaves: Confidential Computing mit Intel SGX und AMD SEV

TL;DR

• Secure Enclaves schaffen hardwareisolierte Bereiche in der CPU, die selbst vor Root-Zugriff und kompromittierten Hypervisoren schuetzen
• Intel SGX isoliert einzelne Prozess-Enklaven (granular), AMD SEV verschluesselt den gesamten VM-Speicher (breit)
• Kubernetes Device Plugins machen TEE-Ressourcen ueber Standard-Pod-Specs anforderbar
• Confidential Containers vereinfachen die Adoption erheblich -- bestehende Container laufen oft ohne Code-Aenderungen
• Der Performance-Overhead liegt bei SGX typischerweise bei 5-15%, bei SEV im niedrigen einstelligen Prozentbereich

Was Secure Enclaves leisten und was nicht

Kubernetes bietet mit RBAC, Network Policies und Pod Security Standards solide Isolation auf Software-Ebene. Aber alle diese Mechanismen haben eine gemeinsame Schwaeche: Sie vertrauen dem Host-Betriebssystem und dem Hypervisor. Wer Root auf dem Node hat, kann prinzipiell auf den Speicher jedes Pods zugreifen.

Secure Enclaves loesen genau dieses Problem. Sie nutzen spezielle CPU-Instruktionen, um einen geschuetzten Speicherbereich zu schaffen, den weder das OS noch der Hypervisor lesen koennen. Die Daten werden erst innerhalb der CPU entschluesselt und verlassen die Enklave nie im Klartext.

Das ist relevant fuer drei konkrete Szenarien: Verarbeitung von Finanzdaten oder Gesundheitsdaten unter strengen Compliance-Anforderungen, Schutz von ML-Modellgewichten vor Extraktion, und sichere Multi-Tenant-Workloads auf geteilter Infrastruktur.

Was Enclaves nicht leisten: Sie schuetzen nicht vor Bugs in der eigenen Anwendung, nicht vor Side-Channel-Attacken auf aelterer Hardware, und sie ersetzen kein ordentliches RBAC oder Network-Policy-Setup.

Intel SGX vs. AMD SEV: Wann welche Technologie

Die beiden Haupttechnologien verfolgen fundamental unterschiedliche Ansaetze. Die richtige Wahl haengt vom konkreten Anwendungsfall ab.

SGX ist die richtige Wahl, wenn einzelne kritische Operationen -- etwa Schluesselgenerierung oder Modell-Inferenz -- isoliert werden sollen. SEV passt besser, wenn ganze Container-Workloads geschuetzt werden muessen, ohne den Anwendungscode anzufassen.

Kubernetes-Integration: So funktioniert es technisch

Die Integration laeuft ueber drei Schichten: Hardware-Erkennung auf dem Node, Device Plugins im Cluster, und Resource Requests in der Pod-Spec.

Schritt 1: Node-Setup und Device Plugin

Auf SGX-faehigen Nodes muss der SGX-Treiber geladen und das Intel SGX Device Plugin deployed werden. Fuer AMD SEV konfiguriert man den Hypervisor entsprechend und nutzt ein SEV-faehiges Device Plugin oder Kata Containers.

# Intel SGX Device Plugin auf dem Cluster installieren
kubectl apply -f https://raw.githubusercontent.com/intel/intel-device-plugins-for-kubernetes/main/deployments/sgx_plugin/overlays/epc-nfd/kustomization.yaml

# Pruefen ob SGX-Ressourcen auf den Nodes verfuegbar sind
kubectl get nodes -o json | jq '.items[].status.allocatable | select(."sgx.intel.com/epc")'

# Node-Labels fuer SGX-faehige Nodes verifizieren
kubectl get nodes -l feature.node.kubernetes.io/cpu-sgx.enabled=true

Schritt 2: Pod-Spec mit SGX-Ressourcen

Ein Pod, der SGX-Enklaven nutzt, fordert EPC-Speicher als Kubernetes-Ressource an. Das Device Plugin kuemmert sich um das Scheduling auf passende Nodes.

apiVersion: v1
kind: Pod
metadata:
  name: sgx-key-service
  labels:
    app: key-service
    security-level: confidential
spec:
  runtimeClassName: kata-cc  # Optional: Confidential Containers Runtime
  containers:
  - name: key-service
    image: registry.internal/key-service:2.1.0
    resources:
      requests:
        sgx.intel.com/epc: 64Mi
      limits:
        sgx.intel.com/epc: 128Mi
        sgx.intel.com/enclave: 1
        sgx.intel.com/provision: 1
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
    volumeMounts:
    - name: aesm-socket
      mountPath: /var/run/aesmd
  nodeSelector:
    feature.node.kubernetes.io/cpu-sgx.enabled: "true"
  volumes:
  - name: aesm-socket
    hostPath:
      path: /var/run/aesmd
      type: DirectoryOrCreate

Schritt 3: Remote Attestation einrichten

Attestierung stellt sicher, dass die Enklave unveraendert und auf echter TEE-Hardware laeuft. Ohne Attestierung koennte ein Angreifer eine gefaelschte Enklave bereitstellen.

apiVersion: v1
kind: ConfigMap
metadata:
  name: attestation-config
data:
  attestation-policy.json: |
    {
      "type": "sgx",
      "min_isvsvn": 2,
      "allowed_mrsigners": [
        "c5d72f2ae66520d1f78f0a84e0ff456c4774b2264ab48a47df4b8559e67c9660"
      ],
      "require_debug_disabled": true,
      "max_age_seconds": 86400
    }

Der Attestation-Service verifiziert bei jedem Start der Enklave, dass der MRENCLAVE-Hash (Code-Identitaet) und der MRSIGNER-Hash (Signer-Identitaet) mit den erwarteten Werten uebereinstimmen. Erst nach erfolgreicher Attestierung werden Secrets an die Enklave uebermittelt.

Confidential Containers: Der einfachere Weg

Das CNCF Confidential Containers Projekt (CoCo) macht TEEs fuer bestehende Container nutzbar, ohne dass Anwendungscode geaendert werden muss. CoCo verwendet Kata Containers als Runtime und startet jeden Pod in einer eigenen, SEV- oder TDX-geschuetzten MicroVM.

Der Workflow sieht so aus:

1. CoCo-Operator im Cluster installieren
2. RuntimeClass kata-cc konfigurieren
3. Pods mit runtimeClassName: kata-cc deployen
4. Container-Image wird innerhalb der geschuetzten VM entpackt und gestartet

Die RuntimeClass-Definition fuer Confidential Containers:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-cc
handler: kata-cc
overhead:
  podFixed:
    memory: "160Mi"
    cpu: "250m"
scheduling:
  nodeSelector:
    katacontainers.io/kata-runtime: "true"

Das overhead-Feld ist wichtig: Es teilt dem Scheduler mit, wie viel Ressourcen die MicroVM selbst verbraucht, damit Nodes nicht ueberbucht werden. Ohne diese Angabe plant der Scheduler zu viele Confidential-Pods auf einen Node.

Das ist der pragmatischste Einstieg, wenn man bestehende Workloads schuetzen will, ohne sie umzuschreiben. Der Nachteil: Der Overhead einer MicroVM pro Pod ist hoeher als bei nativen SGX-Enklaven.

Performance-Auswirkungen realistisch einschaetzen

Die haeufigste Sorge bei Secure Enclaves ist Performance. Hier die Realitaet:

Intel SGX: Der Overhead entsteht primaer durch EPC Paging. Solange die Arbeitsdaten in den EPC passen (typisch 128-512 MB), liegt der Overhead bei 5-10%. Uebersteigt der Speicherbedarf den EPC, steigt der Overhead durch Paging auf 20-50%. Die Loesung: Nur die wirklich sensitiven Daten in die Enklave legen, nicht die gesamte Anwendung.

AMD SEV: Die Speicherverschluesselung laeuft inline im Memory Controller. Der Overhead ist minimal (1-5%) und weitgehend unabhaengig von der Workload-Groesse. Einzig bei sehr I/O-intensiven Workloads mit vielen Context Switches kann der Overhead auf 5-8% steigen.

Confidential Containers (Kata + SEV): Hier addiert sich der SEV-Overhead zum MicroVM-Overhead. Die Startup-Zeit eines Pods steigt um 2-5 Sekunden. Fuer langlebige Services ist das irrelevant, fuer kurzlebige Batch-Jobs kann es relevant werden.

Monitoring von TEE-Workloads

Confidential-Computing-Workloads brauchen spezielles Monitoring. Standard-Metriken wie CPU und Memory reichen nicht aus -- man muss auch den TEE-Status ueberwachen.

Relevante Metriken fuer SGX-basierte Workloads:

• EPC Usage: Wie viel Enclave Page Cache wird tatsaechlich genutzt? Bei Ueberschreitung beginnt teures Paging.
• Attestation Success Rate: Wie oft schlaegt die Remote Attestation fehl? Fehler deuten auf Hardware-Probleme oder manipulierte Enklaven hin.
• Enclave Creation Time: Wie lange dauert der Aufbau einer Enklave? Steigende Zeiten deuten auf Ressourcenknappheit hin.

Fuer SEV-basierte Workloads:

• VM Boot Time: Die Startup-Zeit der MicroVM. Relevant fuer die Scheduling-Latenz.
• Attestation Freshness: Wie alt ist der letzte Attestation-Report? Veraltete Reports sind ein Sicherheitsrisiko.
• Memory Encryption Status: Verifizierung, dass die SEV-Verschluesselung tatsaechlich aktiv ist.

Diese Metriken lassen sich ueber Custom Prometheus Exporters oder das Intel SGX PCCS (Provisioning Certificate Caching Service) sammeln. Der SGX Device Plugin exponiert Basis-Metriken bereits ueber den kubelet Metrics Endpoint.

Troubleshooting: Haeufige Probleme

Pod bleibt in Pending: Meistens fehlt ein Node mit dem richtigen Label oder der EPC-Speicher ist auf allen SGX-Nodes aufgebraucht. Pruefen mit kubectl describe pod -- im Events-Bereich steht, welche Ressource nicht schedulbar ist.

Attestation schlaegt fehl: Haeufigste Ursache ist ein veralteter BIOS- oder Microcode-Stand. Intel aktualisiert regelmaessig die TCB (Trusted Computing Base) -- nach einem Update muessen die Attestation-Policies angepasst werden.

Performance-Einbruch bei SGX: Wahrscheinlich ueberschreitet der Workload den EPC. Loesung: EPC-Nutzung monitoren und entweder den Workload aufteilen oder auf Nodes mit groesserem EPC migrieren.

CoCo-Pods starten nicht: Haeufig fehlt der Kata-Runtime-Handler auf dem Node. Verifizieren mit kubectl get runtimeclass kata-cc und pruefen, ob die Nodes das Label katacontainers.io/kata-runtime: "true" haben.

Secure Enclaves im Vergleich zu anderen Isolation-Mechanismen

Enclaves sind nicht die einzige Moeglichkeit, Workloads staerker zu isolieren. Hier der Vergleich:

Die Entscheidung ist nicht Entweder-Oder. In der Praxis kombiniert man mehrere Schichten: Network Policies fuer alle Workloads, Pod Security Standards als Baseline, und Secure Enclaves fuer die wirklich sensitiven Services.

Compliance-Aspekte: DSGVO und Datenverarbeitung

Secure Enclaves unterstuetzen die DSGVO-Anforderungen an zwei konkreten Stellen. Erstens bei Artikel 25 (Privacy by Design): Die hardwarebasierte Verschluesselung waehrend der Verarbeitung ist eine technische Massnahme, die den Schutz personenbezogener Daten direkt in die Architektur einbettet. Zweitens bei Artikel 32 (Sicherheit der Verarbeitung): TEEs bieten ein Schutzniveau, das ueber reine Software-Verschluesselung hinausgeht.

Fuer den Nachweis gegenueber Auditoren ist die Attestierung besonders wertvoll. Sie liefert kryptografischen Beweis, dass Daten in einer verifizierten, geschuetzten Umgebung verarbeitet wurden. Das vereinfacht Audits erheblich.

Der Attestation-Report enthaelt Informationen ueber die Hardware-Plattform, den geladenen Code und die Sicherheitskonfiguration. Er kann automatisiert in Audit-Logs geschrieben und bei Compliance-Pruefungen vorgelegt werden. Im Gegensatz zu reinen Software-Zertifizierungen ist ein TEE-Attestation-Report kryptografisch verifizierbar -- Auditoren muessen sich nicht auf die Aussagen des Betreibers verlassen.

Empfohlene Einstiegsstrategie

Nicht jeder Workload braucht eine Enklave. Ein pauschaler Einsatz fuer alle Services ist weder noetig noch sinnvoll. Der pragmatische Ansatz:

1. Wochen 1-2: Identifiziere Workloads, die tatsaechlich von TEE profitieren. Kandidaten: Key-Management-Services, Daten mit hoher Schutzklasse, ML-Inferenz mit proprietaeren Modellen.

2. Wochen 3-4: Proof of Concept mit Confidential Containers (Kata + SEV) fuer einen nicht-kritischen Workload. Das erfordert keine Code-Aenderungen und liefert schnell Ergebnisse.

3. Wochen 5-8: Performance-Baseline messen, Attestation-Workflow etablieren, Monitoring fuer TEE-Metriken einrichten.

4. Wochen 9-12: Rollout auf produktive Workloads. Erst SEV-basierte Confidential Containers, dann bei Bedarf SGX fuer spezifische Services mit hohen Anforderungen an granulare Isolation.

Wichtig bei der Planung: Die Hardware-Beschaffung kann der laengste Lead-Time-Faktor sein. SGX-faehige Server muessen explizit bestellt werden, und nicht jede Cloud-Region bietet Confidential-Computing-Instanzen an. Prueft die Verfuegbarkeit fruehzeitig.

Weitergehende Themen

• Kubernetes Network Policies fuer zusaetzliche Netzwerkisolation
• Runtime Security: Falco und eBPF-basierte Erkennung
• Encryption Strategies fuer Kubernetes
• Supply Chain Security in der CI/CD-Pipeline

Wenn ihr Secure Enclaves in eurer Kubernetes-Umgebung evaluieren wollt und Unterstuetzung bei der Architektur oder dem Proof of Concept braucht, meldet euch unter /kontakt.