Conteneurs confidentiels (préversion) sur Azure Kubernetes Service

Avec la croissance du développement d’applications natives Cloud, il devient de plus en plus nécessaire de protéger les charges de travail exécutées dans des environnements cloud. La conteneurisation de la charge de travail constitue un composant clé pour ce modèle de programmation. La protection du conteneur est ensuite primordiale pour une exécution confidentielle dans le cloud.

Les conteneurs confidentiels sur Azure Kubernetes Service (AKS) permettent l’isolation au niveau du conteneur dans vos charges de travail Kubernetes. Ils viennent s’ajouter à la suite Azure de produits d’informatique confidentielle et utilisent le chiffrement de mémoire AMD SEV-SNP pour protéger vos conteneurs au moment de l’exécution.

Les conteneurs confidentiels sont attrayants pour les scénarios de déploiement qui impliquent des données sensibles (par exemple, des données personnelles ou des données avec une sécurité forte nécessaire pour la conformité réglementaire).

Qu’est-ce qui rend un conteneur confidentiel ?

En conformité avec les directives définies par le Consortium d’informatique confidentielle, microsoft est un membre fondateur des conteneurs confidentiels qui doivent remplir les conditions suivantes :

• Transparence : environnement de conteneur confidentiel dans lequel votre application sensible est partagée et dans lequel vous pouvez voir et vérifier qu’elle est sûre. Tous les composants de la base de calcul approuvée (TCB, Trusted Computing Base) doivent être open source.
• Auditabilité : vous avez la possibilité de vérifier et de voir quelle version du package d’environnement CoCo, y compris le système d’exploitation invité Linux et tous les composants sont en cours. Microsoft se connecte au système d’exploitation invité et à l’environnement de runtime de conteneur pour les vérifications par le biais de l’attestation. Il publie également un algorithme de hachage sécurisé (SHA, Secure Hash Algorithm) des builds du système d’exploitation invité pour générer une audibilité de chaîne et une histoire de contrôle.
• Attestation complète : tout ce qui fait partie de l’environnement d’exécution de confiance (TEE, Trusted Execution Environment) doit être entièrement mesuré par le processeur avec la possibilité de vérifier à distance. Le rapport matériel du processeur AMD SEV-SNP doit refléter les couches de conteneurs et le hachage de configuration du runtime de conteneur via les revendications d’attestation. L’application peut récupérer le rapport matériel localement, y compris le rapport qui reflète l’image du système d’exploitation invité et le runtime de conteneur.
• Intégrité du code : l’application du runtime est toujours disponible via des stratégies définies par le client pour les conteneurs et la configuration de conteneur, comme les stratégies immuables et la signature de conteneur.
• Isolation de l’opérateur : conceptions de sécurité qui supposent des privilèges minimum et des protections d’isolation maximales contre toutes les parties non approuvées, y compris les administrateurs clients/locataires. Cela inclut le renforcement de l’accès existant du plan de contrôle Kubernetes (kubelet) aux pods confidentiels.

Mais avec ces fonctionnalités de confidentialité, le produit doit ajouteritioanally sa facilité d’utilisation : il prend en charge tous les conteneurs Linux non modifiés avec une haute conformité des fonctionnalités Kubernetes. En outre, il prend en charge les pools de nœuds hétérogènes (GPU, nœuds à usage général) dans un seul cluster afin d’optimiser les coûts.

Quels formulaires sont des conteneurs confidentiels sur AKS ?

S’alignant sur l’engagement de Microsoft pour la communauté open source, la pile sous-jacente pour les conteneurs confidentiels utilise l’agent Kata CoCo en tant qu’agent s’exécutant dans le nœud qui héberge le pod exécutant la charge de travail confidentielle. Avec de nombreuses technologies TEE nécessitant une limite entre l’hôte et l’invité, les conteneurs Kata sont la base du travail initial de Kata CoCo. Microsoft a également contribué à la communauté Kata Coco pour alimenter les conteneurs s’exécutant à l’intérieur d’une machine virtuelle utilitaire confidentielle.

Le conteneur confidentiel Kata réside dans l’hôte de conteneur Azure Linux AKS. Azure Linux et le Cloud Hypervisor VMM (Virtual Machine Monitor, moniteur de machines virtuelles) est le logiciel d’espace utilisateur / destiné à l’utilisateur final qui est utilisé pour créer et gérer la durée de vie des machines virtuelles.

Isolation au niveau du conteneur dans AKS

Par défaut, akS toutes les charges de travail partagent le même noyau et le même administrateur de cluster. Avec la préversion du bac à sable pod sur AKS, l’isolation a augmenté d’un niveau supérieur avec la possibilité de fournir l’isolation du noyau pour les charges de travail sur le même nœud AKS. Vous pouvez en savoir plus sur la fonctionnalité ici. Les conteneurs confidentiels sont l’étape suivante de cette isolation et utilisent les fonctionnalités de chiffrement de mémoire des tailles de machine virtuelle AMD SEV-SNP sous-jacentes. Ces machines virtuelles sont les tailles DCa_cc et ECa_cc avec la possibilité de faire apparaître la racine de confiance du matériel aux pods déployés sur celui-ci.

Bien démarrer

Pour commencer et en savoir plus sur les scénarios pris en charge, consultez notre documentation AKS ici.

Étape suivante

Déployez un conteneur confidentiel sur AKS.