Partage via

Les conteneurs confidentiels sur Azure Kubernetes Service (AKS)

  • Article

Les conteneurs confidentiels fournissent un ensemble de fonctionnalités et de capacités qui renforcent la sécurité des charges de travail de conteneur standard, et ce afin d’améliorer la sécurité et la confidentialité des données, ainsi que les objectifs d’intégrité du code de runtime. Azure Kubernetes Service (AKS) inclut les conteneurs confidentiels (préversion) sur AKS.

Les conteneurs confidentiels utilisent les conteneurs confidentiels Kata et le chiffrement basé sur le matériel pour chiffrer la mémoire des conteneurs. Ils instaurent un nouveau niveau de confidentialité des données en empêchant que les données en mémoire se trouvent dans un format texte clair et lisible pendant le calcul. L’approbation est obtenue dans le conteneur via une attestation matérielle, ce qui permet aux entités approuvées d’accéder aux données chiffrées.

Avec le sandboxing de pod, vous pouvez exécuter des charges de travail sensibles isolées dans Azure, afin de protéger vos données et vos charges de travail. Qu’est-ce qui rend un conteneur confidentiel :

  • 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 d’afficher la version de l’environnement CoCo qui est en cours d’utilisation, ainsi que le système d’exploitation invité Linux et tous les composants. 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.

Avec les autres mesures de sécurité et les contrôles de protection des données intégrés à votre architecture globale, ces fonctionnalités permettent de répondre aux exigences de conformité réglementaires, sectorielles ou de gouvernance pour la sécurisation des informations sensibles.

Cet article permet de comprendre la fonctionnalité des conteneurs confidentiels, mais aussi d’implémenter et de configurer les éléments suivants :

  • Déployer ou mettre à niveau un cluster AKS avec Azure CLI
  • Ajouter une annotation au YAML de votre pod pour marquer le pod comme exécuté en tant que conteneur confidentiel
  • Ajouter une stratégie de sécurité au YAML de votre pod
  • Activer l'application de la stratégie de sécurité
  • Déployer votre application dans un calcul confidentiel

Scénarios pris en charge

Les conteneurs confidentiels (préversion) sont adaptés aux scénarios de déploiement qui impliquent des données sensibles. Par exemple, des informations d’identification personnelle (PII) ou des données avec une sécurité renforcée à des fins de conformité réglementaire. Voici quelques scénarios courants utilisant les conteneurs :

  • Exécution de l’analytique Big Data avec Apache Spark pour la reconnaissance des modèles de fraude dans le secteur financier.
  • Exécution d’exécuteurs GitHub auto-hébergés pour signer en toute sécurité le code dans le cadre des pratiques DevOps pour le déploiement et l’intégration continus (CI/CD).
  • Inférence et entraînement de modèles d’apprentissage automatique avec un jeu de données chiffré à partir d’une source approuvée. Le déchiffrage intervient uniquement à l’intérieur d’un environnement de conteneur confidentiel pour préserver la confidentialité.
  • Création de salles blanches Big Data pour la correspondance d’ID dans le cadre de calculs multi-parties dans des secteurs comme la vente au détail avec publicité numérique.
  • Création de zones d’atterrissage Confiance Zéro pour l’informatique confidentielle, afin de répondre aux réglementations de confidentialité concernant la migration d’applications vers le cloud.

À propos de l’installation

Voici les considérations à prendre en compte avec ces conteneurs confidentiels en préversion :

  • Augmentation du temps de démarrage des pods comparé aux pods runc et aux pods isolés du noyau.
  • Les images conteneur de version 1 ne sont pas prises en charge.
  • Les mises à jour des secrets et des ConfigMaps ne sont pas reflétées dans l’invité.
  • Les conteneurs éphémères et d’autres méthodes de résolution des problèmes comme exec dans un conteneur, les sorties de journal provenant de conteneurs et stdio (ReadStreamRequest et WriteStreamRequest) nécessitent une modification et un redéploiement de stratégie.
  • L’outil générateur de stratégies ne prend pas en charge les types de déploiement cronjob.
  • En raison des mesures de couche d’images conteneur encodées dans la stratégie de sécurité, nous déconseillons d’utiliser la balise latest pour spécifier un conteneur.
  • Les services, les équilibreurs de charge et EndpointSlices prennent uniquement en charge le protocole TCP.
  • Tous les conteneurs de tous les pods des clusters doivent être configurés pour imagePullPolicy: Always.
  • Le générateur de stratégies prend uniquement en charge les pods qui utilisent des adresses IPv4.
  • Les valeurs des ConfigMaps et des secrets ne peuvent pas être modifiées lorsque la définition utilise la méthode de variable d’environnement après le déploiement du pod. La stratégie de sécurité empêche cela.
  • Les journaux d’arrêt des pods ne sont pas pris en charge. Bien que les pods écrivent leurs journaux d’arrêt dans /dev/termination-log ou sur un emplacement personnalisé (lorsque cela est spécifié dans le manifeste du pod), l’hôte/kubelet ne peut pas lire ces journaux. Les modifications de l’invité dans ce fichier ne sont pas reflétées sur l’hôte.

Présentation de l’allocation de ressources

Vous devez bien comprendre le comportement d’allocation de ressources de mémoire et de processeur dans cette version.

  • PROCESSEUR : le shim attribue un processeur virtuel au système d’exploitation de base à l’intérieur du pod. Si aucune ressource limits n’est spécifiée, les charges de travail n’ont aucun partage de processeur distinct attribué. Le processeur virtuel est ensuite partagé avec cette charge de travail. Si les limites du processeur sont spécifiées, les partages correspondants sont explicitement alloués aux charges de travail.
  • Mémoire : le gestionnaire de CC Kata utilise 2 Go de mémoire pour le système d’exploitation UVM et X Mo de mémoire supplémentaire où X est la ressource limits si elle est spécifiée dans le manifeste YAML (ce qui entraîne une machine virtuelle de 2 Go quand aucune limite n’est donnée, sans mémoire implicite pour les conteneurs). Le gestionnaire Kata utilise une mémoire de base de 256 Mo pour le système d’exploitation UVM et X Mo de mémoire supplémentaire lorsque la ressource limits est spécifiée dans le manifeste YAML. Si les limites ne sont pas spécifiées, une limite implicite de 1 792 Mo est ajoutée, ce qui se traduit par une machine virtuelle de 2 Go et une mémoire implicite de 1 792 Mo pour les conteneurs.

Cette version ne prend pas en charge la spécification des requêtes de ressource dans les manifestes de pod. Le conteneur Kata ignore les requêtes de ressource à partir du manifeste YAML du pod. Par conséquent, le conteneur ne transmet pas les requêtes au shim. Utilisez les ressources limit plutôt que les ressources requests pour allouer des ressources de mémoire ou de processeur aux charges de travail ou aux conteneurs.

Lorsque le système de fichiers d’un conteneur local est sauvegardé par la mémoire de la machine virtuelle, l’écriture dans le système de fichiers du conteneur (y compris la journalisation) peut remplir la mémoire disponible fournie au pod. Cette condition peut faire planter le pod.

Étapes suivantes