Accès du conteneur de sécurité aux ressources à l’aide des fonctionnalités de sécurité Linux intégrées

Dans cet article, vous allez apprendre à sécuriser l’accès des conteneurs aux ressources pour vos charges de travail Azure Kubernetes Service (AKS).

Vue d’ensemble

De la même façon que vous devez accorder aux utilisateurs ou aux groupes le minimum de privilèges requis, vous devez limiter les conteneurs uniquement aux actions et processus nécessaires. Pour réduire le risque d’attaque, évitez de configurer les applications et les conteneurs qui nécessitent une escalade des privilèges ou un accès racine.

Vous pouvez utiliser des contextes de sécurité de pod Kubernetes intégrés pour définir davantage d’autorisations, telles que l’utilisateur ou le groupe à exécuter, les fonctionnalités Linux à exposer ou définir des allowPrivilegeEscalation: false dans le manifeste de pod. Pour plus de meilleures pratiques, consultez Sécuriser l’accès du pod aux ressources.

Pour améliorer l’isolation de l’hôte et diminuer le mouvement latéral sur Linux, vous pouvez utiliser des espaces de noms utilisateur.

Pour un contrôle encore plus précis des actions de conteneur, vous pouvez utiliser des fonctionnalités de sécurité Linux intégrées telles que AppArmor et seccomp.

1. Définissez les fonctionnalités de sécurité de Linux au niveau du nœud.
2. Implémentez les fonctionnalités par le biais d’un manifeste de pod.

Les fonctionnalités de sécurité Linux intégrées sont disponibles sur les nœuds et les pods Linux uniquement.

Espaces de noms utilisateur

Les pods Linux s’exécutent à l’aide de plusieurs espaces de noms par défaut : espaces de noms réseau pour isoler l’identité réseau et un espace de noms PID pour isoler les processus. Un espace de noms utilisateur isole les utilisateurs à l’intérieur du conteneur des utilisateurs sur l’hôte. Elle limite également l’étendue des fonctionnalités et les interactions du pod avec le reste du système.

Les UID et les GID à l’intérieur du conteneur sont mappés aux utilisateurs non privilégiés sur l’hôte, de sorte que toutes les interactions avec le reste de l’hôte se produisent comme ces UID et GID non privilégiés. Par exemple, l'utilisateur root à l’intérieur du conteneur (UID 0) peut être mappé à l’utilisateur 65536 sur l’hôte. Kubernetes crée le mappage pour veiller à ce qu’il ne chevauche pas d’autres pods en utilisant des espaces de noms utilisateur sur le système.

L’implémentation de Kubernetes présente quelques avantages clés :

• Isolation renforcée de l’hôte : si un conteneur échappe aux limites du pod, même s’il s’exécute en tant que superutilisateur dans le conteneur, il n’a pas de privilèges sur l’hôte. La raison est que les UID et les GID du conteneur sont mappés aux utilisateurs non privilégiés sur l’hôte. S’il y a un échappement de conteneur, les espaces de noms utilisateur protègent grandement les fichiers sur l’hôte qu'un conteneur peut lire ou écrire, et déterminent les processus auxquels il peut envoyer des signaux. Les fonctionnalités accordées ne sont valides qu’à l’intérieur de l’espace de noms utilisateur et non sur l’hôte.

• Prévention du mouvement latéral : comme les UID et GID pour différents conteneurs sont mappés à des UID et GID différents et non chevauchants sur l’hôte, il devient plus difficile pour les conteneurs de s'attaquer mutuellement. Par exemple, supposons que le conteneur A s’exécute avec différents UID et GID sur l’hôte que le conteneur B. En cas de rupture de conteneur, les opérations qu’elle peut effectuer sur les fichiers et processus du conteneur B sont limitées : seule la lecture/écriture qu’un fichier permet à d’autres personnes. Mais cela n’est même pas possible, car il existe une protection supplémentaire sur le répertoire parent du volume racine du pod pour veiller à ce que seul le GID du pod puisse y accéder.

• Respectez le principe des privilèges minimum : à mesure que les UID et les GID sont mappés à des utilisateurs non privilégiés sur l’hôte, seuls les utilisateurs qui ont besoin du privilège sur l’hôte (et désactivent les espaces de noms d’utilisateurs) l’obtiennent. Sans espaces de noms d’utilisateur, il n’existe aucune séparation entre les utilisateurs du conteneur et les utilisateurs de l’hôte. Nous ne pouvons pas éviter d’accorder des privilèges sur l’hôte aux processus qui n’en ont pas besoin, quand ils ont besoin de privilèges juste à l’intérieur du conteneur.

• Activation de nouveaux cas d’usage : les espaces de noms utilisateur permettent aux conteneurs d’obtenir certaines fonctionnalités à l’intérieur de leur propre espace de noms d’utilisateur sans affecter l’hôte. Les capacités accordées exclusivement au pod déverrouillent de nouvelles possibilités, telles que l’exécution d’applications nécessitant des opérations privilégiées sans accorder l’accès racine complet sur l’hôte. Les nouveaux cas d’usage courants qui peuvent être implémentés en toute sécurité sont : l’exécution de conteneurs imbriqués et les constructions de conteneurs non privilégiés.

• Configuration de conteneur non privilégiée : la plupart de la création et de l’installation du conteneur ne s’exécutent pas en tant que racine sur l’hôte, ce qui limite considérablement l’impact de nombreux CVE.

Aucune de ces choses n’est vraie lorsque les espaces de noms utilisateur ne sont pas utilisés. Si le conteneur s’exécute en tant que racine, lorsque les espaces de noms utilisateur ne sont pas utilisés, le processus s’exécute en tant que racine sur l’hôte, les fonctionnalités sont valides sur l’hôte et la configuration du conteneur est effectuée en tant que racine sur l’hôte.

Avant de commencer

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Cluster AKS existant. Si vous n'avez pas de cluster, créez-en un à l'aide d'Azure CLI, d'Azure PowerShell ou du portail Azure.
• Kubernetes version 1.33 minimale pour le plan de contrôle et les nœuds Worker. Si vous n’utilisez pas kubernetes version 1.33 ou ultérieure, vous devez mettre à niveau votre version kubernetes.
• Nœuds Worker exécutant Azure Linux 3.0 ou Ubuntu 24.04. Si vous n’utilisez pas ces versions du système d’exploitation, vous n’aurez pas la configuration minimale requise pour activer les espaces de noms utilisateur. Vous devez mettre à niveau votre version du système d’exploitation.

Limites

• Les espaces de noms utilisateur sont une fonctionnalité de noyau Linux et ne sont pas pris en charge pour les pools de nœuds Windows.
• N’hésitez pas à consulter la documentation Kubernetes pour les espaces de noms d’utilisateurs, en particulier la section limitations.

Activer les espaces de noms utilisateur

Aucune configuration n’est nécessaire pour utiliser cette fonctionnalité. Si vous utilisez la version AKS requise, tout est prêt à l’emploi.

1. Créez un fichier nommé mypod.yaml et copiez-y le manifeste suivant :

   Pour utiliser des espaces de noms utilisateur, le yaml doit avoir le champ hostUsers: false.

   apiVersion: v1
   kind: Pod
   metadata:
     name: userns
   spec:
     hostUsers: false
     containers:
     - name: shell
       command: ["sleep", "infinity"]
       image: debian
   

2. Déployez l’application à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML.

   kubectl apply -f mypod.yaml
   

3. Vérifiez l'état des pods déployés à l'aide de la commande kubectl get pods.

   kubectl get pods
   

4. Exécutez dans le pod pour vérifier /proc/self/uid_map en utilisant la commande kubectl exec:

   kubectl exec -ti userns -- bash
   # Now inside the pod run
   cat /proc/self/uid_map
   

La sortie doit avoir 65536 dans la dernière colonne. Par exemple:

0  833617920      65536

Atténuation des CVEs

Voici quelques CVE totalement/partiellement atténuées avec des espaces de noms utilisateur.

N’oubliez pas que la liste n’est pas exhaustive. Il ne s’agit que d’une sélection de CVE avec un score élevé qui sont atténuées :

• CVE-2019-5736 - Score 8,6 (HAUTE)
• CVE 2024-21262 : Score 8,6 (HAUTE)
• CVE 2022-0492 : Score 7,8 (HAUTE)
• CVE-2021-25741 : Score : 8.1 (ÉLEVÉ) / 8.8 (ÉLEVÉ)
• CVE-2017-1002101 : Score : 9,6 (CRITIQUE) / 8.8(HIGH)

Pour en savoir plus, lisez ce billet de blog avec des informations supplémentaires sur les espaces de noms utilisateur.

AppArmor

Pour limiter les actions de conteneurs, vous pouvez utiliser le module de sécurité du noyau Linux AppArmor. AppArmor est disponible dans le cadre du système d’exploitation de nœud AKS sous-jacent et est activé par défaut. Vous créez des profils AppArmor qui limitent les actions de lecture, d’écriture ou d’exécution, ou des fonctions système telles que le montage de systèmes de fichiers. Les profils AppArmor par défaut limitent l’accès à divers emplacements /proc et /sys, et fournissent un moyen pour isoler de façon logique les conteneurs à partir du nœud sous-jacent. AppArmor fonctionne pour n’importe quelle application qui s’exécute sur Linux, pas seulement les pods Kubernetes.

Pour voir AppArmor en action, l’exemple suivant crée un profil qui empêche l’écriture de fichiers.

1. SSH vers un nœud AKS.

2. Créez un fichier nommé deny-write.profile.

3. Copiez et collez le contenu suivant :

   #include <tunables/global>
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
     # Deny all file writes.
     deny /** w,
   }
   

Les profils AppArmor sont ajoutés à l’aide de la commande apparmor_parser.

1. Ajoutez le profil à AppArmor.

2. Spécifiez le nom du profil créé à l’étape précédente :

   sudo apparmor_parser deny-write.profile
   

   Si le profil est analysé correctement et appliqué à AppArmor, vous ne verrez aucune sortie et vous serez redirigé vers l’invite de commandes.

3. À partir de votre machine locale, créez un manifeste de pod nommé aks-apparmor.yaml. Ce manifeste :

   • Définit une annotation pour container.apparmor.security.beta.kubernetes.
   • Référence le profil deny-write créé aux étapes précédentes.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
     annotations:
       container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
   spec:
     containers:
     - name: hello
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

4. Une fois le pod déployé, exécutez la commande suivante et vérifiez que le pod hello-apparmor affiche un état En cours d’exécution :

   kubectl get pods
   
   NAME             READY   STATUS    RESTARTS   AGE
   aks-ssh          1/1     Running   0          4m2s
   hello-apparmor   0/1     Running   0          50s
   

Pour plus d’informations sur AppArmor, consultez les Profils AppArmor dans Kubernetes.

Sécuriser le calcul (seccomp)

Tandis qu’AppArmor fonctionne pour toutes les applications Linux, seccomp (secure computing) agit au niveau du processus. Seccomp est également un module de sécurité du noyau Linux, pris en charge de façon native par le runtime containerd utilisé par les nœuds AKS. Avec seccomp, vous pouvez limiter les appels au système d’un conteneur. Seccomp établit une couche supplémentaire de protection contre les vulnérabilités d’appel système courantes exploitées par des acteurs malveillants et vous permet de spécifier un profil par défaut pour toutes les charges de travail du nœud.

Configurer un profil seccomp par défaut (préversion)

Vous pouvez appliquer des profils seccomp par défaut à l’aide de configurations de nœuds personnalisées lors de la création d’un pool de nœuds Linux. Il existe deux valeurs prises en charge sur AKS : RuntimeDefault et Unconfined. Certaines charges de travail peuvent nécessiter un nombre inférieur de restrictions syscall que d’autres. Cela signifie qu’elles peuvent échouer pendant l’exécution avec le profil « RuntimeDefault ». Pour atténuer ce type d’échec, vous pouvez spécifier le profil Unconfined . Si votre charge de travail nécessite un profil personnalisé, consultez Configurer un profil seccomp personnalisé.

Limites

• SeccompDefault n’est pas un paramètre pris en charge pour les pools de nœuds Windows.
• SeccompDefault est disponible à partir de l’API 2024-09-02-preview.

Inscrire l’indicateur de fonctionnalité KubeletDefaultSeccompProfilePreview

1. Inscrivez l’indicateur de fonctionnalité KubeletDefaultSeccompProfilePreview à l’aide de la commande az feature register.

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

   Quelques minutes sont nécessaires pour que l’état s’affiche Inscrit.

2. Vérifiez l’état de l’inscription en utilisant la commande az feature show.

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

3. 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
   

Restreindre les appels système de votre conteneur avec seccomp

1. Suivez les étapes pour appliquer un profil seccomp dans votre configuration kubelet en spécifiant "seccompDefault": "RuntimeDefault".

RuntimeDefault utilise le profil seccomp de containerD par défaut, qui restreint certains appels système afin d’améliorer la sécurité. Les syscalls restreints échoueront. Pour plus de détails, consultez le profil seccomp de containerD par défaut.

2. Vérifiez que la configuration a été appliquée.

Vous pouvez confirmer que les paramètres sont appliqués aux nœuds. Pour cela, connectez-vous à l’hôte et validez que les modifications de la configuration ont été apportées au système de fichiers.

3. Résoudre les échecs de charge de travail.

Lorsque SeccompDefault est activé, le profil seccomp par défaut du runtime de conteneur est utilisé par défaut pour toutes les charges de travail planifiées sur le nœud. Cela peut entraîner l’échec des charges de travail en raison de syscalls bloqués. Si une défaillance de charge de travail s’est produite, vous pouvez voir des erreurs telles que :

• La charge de travail est existante de façon inattendue une fois que la fonctionnalité est activée, avec l’erreur « autorisation refusée ».
• Les messages d’erreur Seccomp peuvent également être affichés dans audité ou syslog en remplaçant SCMP_ACT_ERRNO par SCMP_ACT_LOG dans le profil par défaut.

Si vous rencontrez les erreurs ci-dessus, nous vous recommandons de modifier votre profil seccomp par Unconfined. Unconfined n’impose aucune restriction sur les syscalls, en autorisant tous les appels système, ce qui réduit la sécurité.

Configurer un profil seccomp personnalisé

Avec un profil seccomp personnalisé, vous pouvez avoir un contrôle plus précis sur les syscalls restreints. Respectez la bonne pratique consistant à accorder l’autorisation minimale au conteneur pour une exécution en :

• Définissant avec des filtres les actions à autoriser ou à refuser.
• Annotant dans un manifeste YAML de pod afin d’associer au filtre seccomp.

Pour voir seccomp en action, créez un filtre qui empêche la modification des autorisations sur un fichier.

1. SSH vers un nœud AKS.

2. Créez un filtre seccomp nommé /var/lib/kubelet/seccomp/prevent-chmod.

3. Copiez et collez le contenu suivant :

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "name": "chmod",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "fchmodat",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "chmodat",
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

   Dans les versions 1.19 et ultérieures, vous devez configurer :

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "names": ["chmod","fchmodat","chmodat"],
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

4. À partir de votre machine locale, créez un manifeste de pod nommé aks-seccomp.yaml et collez le contenu suivant. Ce manifeste :

   • Définit une annotation pour seccomp.security.alpha.kubernetes.io.
   • Référence le filtre prevent-chmod créé à l’étape précédente.

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
     annotations:
       seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
   spec:
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

   Dans les versions 1.19 et ultérieures, vous devez configurer :

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
   spec:
     securityContext:
       seccompProfile:
         type: Localhost
         localhostProfile: prevent-chmod
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

5. Déployez l’exemple de pod à l’aide de la commande kubectl apply :

   kubectl apply -f ./aks-seccomp.yaml
   

6. Affichez l’état du pod à l’aide de la commande kubectl get pods.

   • Le pod signale une erreur.
   • La commande chmod ne peut pas être exécutée en raison du filtre seccomp, comme affiché dans l’exemple de sortie :

   kubectl get pods
   
   NAME                      READY     STATUS    RESTARTS   AGE
   chmod-prevented           0/1       Error     0          7s
   

Pour obtenir de l’aide sur la résolution des problèmes liés à votre profil seccomp, consultez l’article Résoudre les problèmes de configuration de profil seccomp dans Azure Kubernetes Service.

Options de profil de sécurité Seccomp

Les profils de sécurité Seccomp sont un ensemble de syscalls définis autorisés ou restreints. La plupart des runtimes de conteneur ont un profil seccomp par défaut similaire si ce n’est pas le même que celui qu’utilise Docker. Pour plus d’informations sur les profils disponibles, consultez profils Docker ou containerD profils seccomp par défaut.

AKS utilise le profil containerD seccomp par défaut pour notre runtimeDefault lorsque vous configurez seccomp à l’aide de la configuration de nœud personnalisée.

Syscalls significatifs bloqués par profil par défaut

Docker et containerD conservent les listes d’autorisation des syscalls sécurisés. Ce tableau répertorie les syscalls importants (mais pas tous) qui sont effectivement bloqués, car ils ne figurent pas sur la liste d’autorisation. Si l’un des syscalls bloqués est requis par votre charge de travail, n’utilisez pas le profil RuntimeDefault seccomp.

Lorsque des modifications sont apportées à docker et conteneurD, AKS met à jour sa configuration par défaut pour qu’elle corresponde. Les mises à jour apportées à cette liste peuvent entraîner une défaillance de la charge de travail. Pour des mises à jour de versions, consultez les notes de publication relatives à AKS.

Étapes suivantes

Pour connaître les meilleures pratiques associées, voir Meilleures pratiques relatives aux mises à jour et à la sécurité du cluster dans AKS et Bonnes pratiques relatives à la sécurité de pod dans AKS.