Fortanix kündigte am 18. Oktober 2026 Unterstützung für CNCF Confidential Containers (CoCo) in Fortanix Confidential AI an. Cisco berichtet von einem funktionierenden Test mit einem Intel-TDX-Worker und einem vertraulichen Container auf einem Cisco UCS C240 M8. Cisco bezeichnete die Integration in seinem Designleitfaden als öffentliche Vorschau; der Test deckt weder den Mehrknotenbetrieb noch Verfügbarkeit oder KI-Leistung ab.

Was Fortanix für Kubernetes ankündigte

CoCo soll Kubernetes-Pods in einer hardwaregeschützten Ausführungsumgebung starten. Dabei läuft ein Pod in einer schlanken virtuellen Maschine auf Basis von Kata Containers. Fortanix verknüpft diesen Ansatz mit zwei Diensten: Der Confidential Computing Manager (CCM) prüft die Umgebung, während der Data Security Manager (DSM) die Freigabe der Entschlüsselungsschlüssel steuert.

Kubernetes und CoCo sind getrennte Projekte der Cloud Native Computing Foundation (CNCF). CNCF führt Kubernetes als graduated project, also als Projekt, das die höchste Reifestufe des CNCF-Projektmodells erreicht hat. Kubernetes erhielt diesen Status am 6. März 2018 als erstes CNCF-Projekt.

Wie die Prüfung die Schlüssel-Freigabe steuert

Im von Cisco beschriebenen Ablauf verschlüsselt der Modelleigner die Container-Abbilder und behält die Zugangsdaten des Build-Prozesses. Die IT-Abteilung betreibt Kubernetes auf dem Host. Host, Registry und weitere Infrastruktur liegen dabei außerhalb der Vertraulichkeitsgrenze, die das Design schützen soll.

Beim Start sammelt die Gastumgebung Messwerte zu Intel TDX und zur Software. Attestierung bedeutet hier, dass CCM diese Nachweise prüft. Eine GPU-Prüfung erfolgt, wenn die CCM-Richtlinie sie verlangt. Nach erfolgreicher Prüfung stellt CCM ein kurzlebiges Zertifikat für die Workload aus. Damit meldet sich die Workload beim DSM an, das anhand ihrer Identität und der geltenden Berechtigungen über die Freigabe des Schlüssels entscheidet. Veränderte Messwerte oder fehlende Berechtigungen verhindern die Freigabe.

Die Zugangsdaten des Build-Prozesses können Schlüssel verschlüsseln, aber laut Cisco weder entschlüsseln noch exportieren oder die Schlüssel auspacken. Sie werden außerdem nicht auf den Cisco-UCS-Host kopiert.

Welche Konfiguration Cisco getestet hat

Cisco berichtet, dass der verschlüsselte GPU-Container in der geprüften Konfiguration startete und Datenverkehr bediente. Zum Aufbau gehörten ein Cisco UCS C240 M8, zwei Intel Xeon 6 6530P mit Intel TDX und eine NVIDIA H100-NVL im Confidential-Computing-Modus. Die GPU wurde an den TDX-Gast durchgereicht. Cisco prüfte einen Worker und einen vertraulichen Container.

Der Softwarestand dieses Tests umfasste Ubuntu 25.10, Linux 6.17.0-41-generic und QEMU 10.1.0 auf dem Host sowie Kubernetes v1.36.4, containerd 2.2.1, das CoCo-Chart 0.21.0 und den NVIDIA GPU Operator v26.3.1. Diese Versionsnummern beschreiben den getesteten Aufbau.

Für die Cluster-Voraussetzungen nennt Cisco Kubernetes neuer als 1.24, containerd ab Version 1.7 und Helm ab Version 3.8. Außerdem muss ein Worker-Knoten mit node.kubernetes.io/worker gekennzeichnet sein. Cisco gibt an, AMD SEV-SNP in dieser Bereitstellung nicht geprüft zu haben.

Was der Test für den Betrieb aussagt

Cisco bezeichnete die CoCo-Unterstützung in seinem am 14. Oktober 2026 aktualisierten Designleitfaden als öffentliche Vorschau. Fortanix erklärte am 18. Oktober, die Unterstützung sei verfügbar. Für Infrastrukturteams ist die konkrete Konfiguration daher ein Bezugspunkt für die technische Prüfung, nicht die Zusage, dass andere Hardware oder Softwarestände ebenso funktionieren.

Cisco zufolge müssen Mehrknotenbetrieb, Verfügbarkeit und KI-Leistung zusätzlich qualifiziert werden. Auch die Kompatibilität der Anwendung und ihre Sicherheit auf Anwendungsebene bleiben zu prüfen. Der beschriebene Test zeigt damit, was Cisco auf einem einzelnen TDX-Worker mit einer NVIDIA H100-NVL validierte; Aussagen über einen größeren Cluster folgen daraus nicht.