Pod Sandboxing (préversion) avec Azure Kubernetes Service (AKS)

Pour aider à sécuriser et protéger les charges de travail de votre conteneur contre le code non approuvé ou potentiellement malveillant, AKS dispose désormais d’un mécanisme appelé Pod Sandboxing (préversion). Pod Sandboxing fournit une limite d’isolation entre l’application conteneur et les ressources de noyau et de calcul partagées par l’hôte du conteneur. Le processeur, la mémoire et la mise en réseau entre autres. Pod Sandboxing complète d’autres mesures de sécurité ou de contrôle de protection des données avec votre architecture globale pour vous aider à répondre aux exigences de conformité réglementaires, sectorielles ou de gouvernance pour la sécurisation des informations sensibles.

Cet article vous permet de comprendre cette nouvelle fonctionnalité et de l’implémenter.

Prérequis

• Azure CLI version 2.44.1 ou ultérieure. Exécutez az --version pour rechercher la version, puis exécutez az upgrade pour mettre à niveau la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

• L’extension Azure CLI aks-preview version 0.5.123 ou ultérieure.

• Enregistrer la fonctionnalité KataVMIsolationPreview dans votre abonnement Azure.

• AKS prend en charge Pod Sandboxing (préversion) à partir de la version 1.24.0 et ultérieure avec tous les plug-ins réseau AKS.

• Pour gérer un cluster Kubernetes, utilisez le client de ligne de commande de Kubernetes kubectl. Azure Cloud Shell comprend kubectl. Vous pouvez installer kubectl en local à l’aide de la commande az aks install-cli.

Installer l’extension Azure CLI aks-preview

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

• Stratégies de support AKS
• FAQ du support Azure

Exécutez la commande suivante pour installer l’extension aks-preview :

az extension add --name aks-preview

Exécutez la commande suivante pour effectuer la mise à jour vers la dernière version de l’extension publiée :

az extension update --name aks-preview

Enregistrer l’indicateur de la fonctionnalité KataVMIsolationPreview

Inscrivez l’indicateur de fonctionnalité KataVMIsolationPreview à l’aide de la commande az feature register, comme indiqué dans l’exemple suivant :

az feature register --namespace "Microsoft.ContainerService" --name "KataVMIsolationPreview"

Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit). Vérifiez l’état de l’inscription à l’aide de la commande az feature show :

az feature show --namespace "Microsoft.ContainerService" --name "KataVMIsolationPreview"

Quand l’état reflète Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register :

az provider register --namespace "Microsoft.ContainerService"

Limites

Voici les contraintes associées à cette préversion de Pod Sandboxing :

• Les conteneurs Kata peuvent ne pas atteindre les limites de performances IOPS par seconde que les conteneurs traditionnels peuvent atteindre sur Azure Files et sur disque SSD local hautes performances.

• Microsoft Defender pour les conteneurs ne prend pas en charge l’évaluation des pods d’exécution Kata.

• Le réseau hôte Kata n’est pas pris en charge.

• AKS ne prend pas en charge les pilotes de Container Storage Interface et le pilote du Secrets store CSI dans cette préversion.

Fonctionnement

Pour obtenir cette fonctionnalité sur AKS, Kata Containers s’exécutant sur la pile d’hôte de conteneur Azure Linux fournit une isolation matérielle renforcée. Pod Sandboxing étend les avantages de l’isolation matérielle, comme un noyau distinct pour chaque pod Kata. L’isolation matérielle alloue des ressources à chaque pod et ne les partage pas avec d’autres conteneurs Kata ou des conteneurs d’espaces de noms s’exécutant sur le même hôte.

L’architecture de la solution repose sur les composants suivants :

• L’hôte de conteneur Azure Linux pour AKS
• Microsoft Hyper-V Hypervisor
• Noyau Linux Dom0 optimisé pour Azure
• Cloud-Hypervisor Virtual Machine Monitor (VMM) open source
• Intégration à l’infrastructure Kata Container

Le déploiement du Pod Sandboxing à l’aide de conteneurs Kata est similaire au flux de travail d’un conteneur standard pour déployer des conteneurs. Le déploiement comprend des options kata-runtime que vous pouvez définir dans le modèle de pod.

Pour utiliser cette fonctionnalité avec un pod, l’unique différence consiste à ajouter runtimeClassNamekata-mshv-vm-isolation à la spécification pod.

Lorsqu’un pod utilise le runtimeClass kata-mshv-vm-isolation, il crée une machine virtuelle servant de bac à sable de pod pour héberger les conteneurs. La machine virtuelle dispose par défaut d'une mémoire de 2 Go et d'un processeur à un cœur si le manifeste de ressources du conteneur (containers[].resources.limits) n'indique pas de limite pour le processeur et la mémoire. Lorsque vous spécifiez une limite pour le processeur ou la mémoire dans le manifeste de ressources du conteneur, la machine virtuelle dispose containers[].resources.limits.cpu de l’argument 1 pour utiliser un + xCPU et containers[].resources.limits.memory de l’argument 2 pour utiliser 2 Go + yMemory. Les conteneurs ne peuvent utiliser le processeur et la mémoire dans les limites des conteneurs. Les containers[].resources.requests sont ignorés dans cette préversion pendant que nous travaillons à la réduction de la surcharge processeur et mémoire.

Déployer un nouveau cluster

Effectuez les étapes suivantes pour déployer un cluster AKS Azure Linux en utilisant l’interface de ligne de commande Azure.

1. Créez un cluster AKS avec la commande az aks create, tout en spécifiant les paramètres suivants :

   • --workload-runtime : spécifie KataMshvVmIsolation pour activer la fonctionnalité Pod Sandboxing sur le pool de nœuds. Avec ce paramètre, les autres paramètres doivent satisfaire aux exigences suivantes. Autrement, la commande échoue et rapporte un problème avec le(s) paramètre(s) correspondant(s).
   • --os-sku : AzureLinux. Seule la référence os-sku Azure Linux prend en charge cette fonctionnalité dans cette préversion.
   • --node-vm-size : toute taille de machine virtuelle Azure de génération 2 prenant en charge la virtualisation imbriquée fonctionne. Par exemple, les machines virtuelles Dsv3.

   L’exemple suivant crée un cluster à un nœud nommé myAKSCluster avec un nœud dans myResourceGroup :

   az aks create --name myAKSCluster --resource-group myResourceGroup --os-sku AzureLinux --workload-runtime KataMshvVmIsolation --node-vm-size Standard_D4s_v3 --node-count 1
   

2. Exécutez la commande suivante pour obtenir les informations d'identification d'accès au cluster Kubernetes. Utilisez la commande az aks get-credentials et remplacez les valeurs pour le nom du cluster et le nom du groupe de ressources.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
   

3. Répertoriez tous les pods de tous les espaces de noms au moyen de la commande kubectl get pods.

   kubectl get pods --all-namespaces
   

Déployer sur un cluster existant

Pour utiliser cette fonctionnalité avec un cluster AKS existant, les conditions suivantes doivent être satisfaites :

• Suivez les étapes pour enregistrer l’indicateur de fonctionnalité KataVMIsolationPreview.
• Vérifiez que le cluster exécute la version 1.24.0 Kubernetes ou ultérieure.

Utilisez la commande suivante pour activer Pod Sandboxing (préversion) en créant le pool de nœuds pour l’héberger.

1. Ajoutez un pool de nœuds à votre cluster AKS avec la commande az aks nodepool add. Spécifiez les paramètres suivants :

   • --resource-group : saisissez le nom d’un groupe de ressources existant dans lequel le cluster AKS sera créé.
   • --cluster-name : saisissez un nom unique pour le cluster AKS, comme myAKSCluster.
   • --name : saisissez un nom unique pour votre pool de nœuds de clusters, par exemple nodepool2.
   • --workload-runtime : spécifie KataMshvVmIsolation pour activer la fonctionnalité Pod Sandboxing sur le pool de nœuds. Avec ce paramètre --workload-runtime, les autres paramètres doivent satisfaire aux exigences suivantes. Autrement, la commande échoue et rapporte un problème avec le(s) paramètre(s) correspondant(s).
     • --os-sku : AzureLinux. Seule la référence os-sku Azure Linux prend en charge cette fonctionnalité dans la préversion.
     • --node-vm-size : toute taille de machine virtuelle Azure de génération 2 prenant en charge la virtualisation imbriquée fonctionne. Par exemple, les machines virtuelles Dsv3.

   L’exemple suivant ajoute un pool de nœuds à myAKSCluster, avec un nœud dans nodepool2 du myResourceGroup :

   az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataMshvVmIsolation --node-vm-size Standard_D4s_v3
   

2. Exécutez la commande az aks update pour activer pod sandboxing (préversion) sur le cluster.

   az aks update --name myAKSCluster --resource-group myResourceGroup
   

Déployer une application approuvée

Pour illustrer le déploiement d’une application approuvée dans le noyau partagé du cluster AKS, procédez comme suit.

1. Créez un fichier nommé trusted-app.yaml pour décrire un pod approuvé, ajoutez ensuite le manifeste suivant.

   kind: Pod
   apiVersion: v1
   metadata:
     name: trusted
   spec:
     containers:
     - name: trusted
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
   

2. Déployez le pod Kubernetes au moyen de la commande kubectl apply, tout en spécifiant votre fichier trusted-app.yaml :

   kubectl apply -f trusted-app.yaml
   

   La sortie de la commande ressemble à l’exemple suivant :

   pod/trusted created
   

Déployer une application non approuvée

Pour illustrer le déploiement d’une application non approuvée dans le bac à sable pod du cluster AKS, procédez comme suit.

1. Créez un fichier nommé untrusted-app.yaml pour décrire un pod non approuvé, ajoutez ensuite le manifeste suivant.

   kind: Pod
   apiVersion: v1
   metadata:
     name: untrusted
   spec:
     runtimeClassName: kata-mshv-vm-isolation
     containers:
     - name: untrusted
       image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
       command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
   

   La valeur pour runtimeClassNameSpec est kata-mhsv-vm-isolation.

2. Déployez le pod Kubernetes au moyen de la commande kubectl apply, tout en spécifiant votre fichier untrusted-app.yaml :

   kubectl apply -f untrusted-app.yaml
   

   La sortie de la commande ressemble à l’exemple suivant :

   pod/untrusted created
   

Vérification de la configuration de l’isolation du noyau

1. Pour accéder à un conteneur dans le cluster AKS, démarrez une session de l’interpréteur de commandes avec la commande kubectl exec. Dans cet exemple, vous accédez au conteneur dans le pod non approuvé.

   kubectl exec -it untrusted -- /bin/bash
   

   Kubectl se connecte à votre cluster, s’exécute /bin/shdans le premier conteneur au sein du pod non approuvé et transfère les flux d’entrée et de sortie de votre terminal au processus du conteneur. Vous pouvez aussi démarrer une session de l’interpréteur de commandes sur le conteneur hébergeant le pod approuvé.

2. Après le démarrage d’une session de l’interpréteur de commandes dans le conteneur du pod non approuvé, vous pouvez exécuter des commandes pour vérifier que le conteneur non approuvé s’exécute dans un bac à sable de pod. Vous remarquerez qu’il a une version de noyau différente de celle du conteneur approuvé à l’extérieur du bac à sable.

   Pour consulter la version du noyau, exécutez la commande suivante :

   uname -r
   

   L'exemple suivant est similaire à la sortie du noyau pour le bac à sable de pod :

   root@untrusted:/# uname -r
   5.15.48.1-8.cm2
   

3. Démarrez une session de l’interpréteur de commandes sur le conteneur du pod approuvé pour vérifier la sortie du noyau :

   kubectl exec -it trusted -- /bin/bash
   

   Pour consulter la version du noyau, exécutez la commande suivante :

   uname -r
   

   L’exemple suivant est semblable à la sortie de la machine virtuelle exécutant le pod approuvé, dont le noyau est différent du pod non approuvé s’exécutant dans le bac à sable de pod :

   5.15.80.mshv2-hvl1.m2
   

Nettoyage

Une fois l’évaluation de cette fonctionnalité terminée, pour éviter les frais Azure, nettoyez vos ressources inutiles. Si, dans le cadre de votre évaluation ou test, vous avez déployé un nouveau cluster, vous pouvez le supprimer à l’aide de la commande az aks delete .

az aks delete --resource-group myResourceGroup --name myAKSCluster

Si vous avez activé Pod Sandboxing (préversion) sur un cluster existant, vous pouvez supprimer le(s) pod(s) avec la commande kubectl delete pod.

kubectl delete pod pod-name

Étapes suivantes

En savoir plus sur les hôtes dédiés Azure pour les nœuds avec votre cluster AKS afin d’utiliser l’isolation matérielle et le contrôle des événements de maintenance de la plateforme Azure.