Fortanix a annoncé le 18 octobre 2026 la prise en charge de Confidential Containers (CoCo) dans Fortanix Confidential AI pour les charges de travail Kubernetes. Le guide de Cisco décrit un test fonctionnel sur un seul worker Intel TDX et qualifie l’intégration d’aperçu public. Cisco rapporte que le conteneur chiffré avec GPU a démarré et servi du trafic dans cette configuration.
Ce que Fortanix annonce pour Kubernetes
CoCo place un pod Kubernetes dans une machine virtuelle légère, fondée sur Kata Containers, afin de l’exécuter dans un environnement d’exécution de confiance, ou TEE. Fortanix présente cette prise en charge comme un moyen de protéger les modèles et les données pendant leur traitement. Cisco a décrit l’intégration le 21 octobre 2026.
Les deux formulations de disponibilité restent distinctes : le communiqué de Fortanix du 18 octobre indique que la prise en charge est disponible, tandis que le guide Cisco, mis à jour le 14 octobre 2026, la décrit comme un aperçu public.
Comment l’attestation autorise l’accès à la clé
Dans le flux décrit par Cisco, le modèle est distribué sous forme de couches de conteneur chiffrées. Le propriétaire du modèle conserve les identifiants utilisés pour construire l’image ; l’équipe informatique exécute Kubernetes sur l’hôte. L’hôte et le registre d’images sont considérés comme extérieurs au périmètre de confiance pour la confidentialité.
À son lancement, le système invité recueille des mesures du processeur Intel TDX et des logiciels. L’attestation consiste à vérifier ces éléments pour établir l’identité du workload. Fortanix Confidential Computing Manager (CCM) contrôle les mesures et délivre, après validation, un certificat de courte durée. Si la politique l’exige, CCM vérifie aussi les éléments d’attestation du GPU.
Le workload utilise ensuite ce certificat pour s’authentifier auprès de Fortanix Data Security Manager (DSM). DSM applique les autorisations associées à son identité et libère la clé de déchiffrement des couches d’image si la politique l’autorise. Des mesures modifiées ou des permissions insuffisantes empêchent cette libération. Cisco précise que les identifiants de construction ne sont pas copiés sur l’hôte UCS et ne permettent pas de déchiffrer, de récupérer ou d’exporter la clé.
La configuration que Cisco dit avoir testée
La validation décrite par Cisco portait sur un serveur Cisco UCS C240 M8, équipé de deux processeurs Intel Xeon 6 6530P avec Intel TDX et d’un seul GPU NVIDIA H100-NVL en mode de calcul confidentiel. Le GPU était transmis à la machine invitée TDX ; le test ne portait pas sur le mode Protected PCIe multi-GPU.
Cisco indique que l’essai comprenait un worker TDX et un conteneur confidentiel. Le logiciel utilisé était Ubuntu 25.10, Linux 6.17.0-41-generic et QEMU 10.1.0, avec Kubernetes v1.36.4, containerd 2.2.1, le chart CoCo 0.21.0 et NVIDIA GPU Operator v26.3.1. Ces versions décrivent cette configuration testée.
Ce que le test ne qualifie pas
Cisco indique que le fonctionnement multinœud, la disponibilité et les performances d’IA nécessitent une qualification supplémentaire. Le résultat rapporté, le démarrage du conteneur chiffré et le service de trafic sur un worker, ne vaut donc pas validation de ces aspects. Cisco souligne également que la compatibilité et la sécurité de l’application doivent être examinées. Le guide indique que la prise en charge d’AMD SEV-SNP n’a pas été vérifiée dans ce déploiement.
Kubernetes et CoCo dans la CNCF
Kubernetes et Confidential Containers sont deux projets distincts de la Cloud Native Computing Foundation (CNCF). La CNCF classe Kubernetes comme un projet gradué ; il est devenu le premier projet gradué de la fondation le 6 mars 2018. CoCo fournit ici la couche d’exécution confidentielle des pods Kubernetes.
