Résoudre les problèmes de configuration de profil seccomp dans Azure Kubernetes Service

2025-06-06

Secure computing (seccomp) est une fonctionnalité du noyau Linux qui limite les appels système que les conteneurs peuvent effectuer, améliorant ainsi la sécurité des charges de travail conteneurisées. Dans Azure Kubernetes Service (AKS), le runtime containerd utilisé par les nœuds AKS prend en charge seccomp de manière native. L’activation d’un profil seccomp peut entraîner l’échec des charges de travail AKS car les appels système critiques de ces charges sont bloqués. Cet article présente les profils seccomp, leur fonctionnement et leur résolution des problèmes à l’aide du projet open source Inspektor Gadget.

Contexte

Syscalls est l’interface qui permet aux programmes d’espace utilisateur de demander des services de noyau. Les profils Seccomp spécifient les syscalls autorisés ou refusés pour un conteneur spécifique. AKS prend en charge deux valeurs :

RuntimeDefault: utilisez le profil seccomp par défaut donné par le runtime.
Unconfined: tous les syscalls sont autorisés.

Pour activer seccomp sur vos pools de nœuds AKS, consultez Accès sécurisé aux ressources à l’aide des fonctionnalités de sécurité Linux intégrées. Vous pouvez également configurer un profil personnalisé pour répondre aux besoins spécifiques de votre charge de travail, consultez Configurer un profil seccomp personnalisé pour plus d’informations.

Lorsque vous utilisez des profils seccomp, il est important de tester et de valider l’effet sur vos charges de travail. Certaines charges de travail peuvent nécessiter un nombre inférieur de restrictions syscall que d’autres. Cela signifie que si les charges de travail nécessitent des syscalls qui ne sont pas inclus dans le profil configuré, elles peuvent échouer pendant l’exécution.

Cet article explique comment utiliser le projet open source Inspektor Gadget pour diagnostiquer les problèmes et obtenir une visibilité sur les syscalls bloqués.

Symptômes

Après avoir configuré des charges de travail AKS pour utiliser un profil seccomp, les charges de travail s'arrêtent de façon inattendue avec l'une des erreurs suivantes :

autorisation refusée
fonction non implémentée

Conditions préalables

Outil permettant de se connecter au cluster Kubernetes, tel que l’outil kubectl . Pour effectuer l’installation kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .
Gestionnaire de package krew pour l’installation du plug-in Inspektor Gadget. Vous pouvez suivre le guide de démarrage rapide krew pour l’installer.
Profil seccomp que vous essayez de résoudre.
Le projet open source Inspektor Gadget.

Liste de contrôle pour la résolution des problèmes

Étape 1 : Modifier votre profil seccomp

Créez un profil seccomp personnalisé correspondant à celui que vous dépannez et remplacez son action par défaut, comme SCMP_ACT_ERRNO, par SCMP_ACT_LOG pour journaliser les appels système bloqués au lieu de les échouer.

Votre profil seccomp personnalisé peut ressembler à ceci :

{
    "defaultAction": "SCMP_ACT_ALLOW",
    "syscalls": [
      {
        "names": ["acct",
                "add_key",
                "bpf",
                "clock_adjtime",
                "clock_settime",
                "clone",
                "create_module",
                "delete_module",
                "finit_module",
                "get_kernel_syms",
                "get_mempolicy",
                "init_module",
                "ioperm",
                "iopl",
                "kcmp",
                "kexec_file_load",
                "kexec_load",
                "keyctl",
                "lookup_dcookie",
                "mbind",
                "mount",
                "move_pages",
                "nfsservctl",
                "open_by_handle_at",
                "perf_event_open",
                "personality",
                "pivot_root",
                "process_vm_readv",
                "process_vm_writev",
                "ptrace",
                "query_module",
                "quotactl",
                "reboot",
                "request_key",
                "set_mempolicy",
                "setns",
                "settimeofday",
                "stime",
                "swapon",
                "swapoff",
                "sysfs",
                "_sysctl",
                "umount",
                "umount2",
                "unshare",
                "uselib",
                "userfaultfd",
                "ustat",
                "vm86",
                "vm86old"],
        "action": "SCMP_ACT_LOG"
      }
    ]
  }

L’article Configurer un profil seccomp personnalisé montre comment appliquer votre profil seccomp personnalisé à votre cluster AKS. Vous pouvez également suivre ces étapes :

Obtenez les noms des nœuds dans votre cluster AKS en exécutant la commande suivante :
```
kubectl get nodes 
```
Utilisez la kubectl debug commande pour démarrer un pod de débogage sur le nœud et vérifiez que le dossier seccomp existe et que l’outil tar est installé (pour copier le profil dans le nœud à l’étape suivante) :
```
kubectl debug node/<node-name> -it --image=mcr.microsoft.com/azurelinux/base/core:3.0
root [ / ]# mkdir -p /host/var/lib/kubelet/seccomp
root [ / ]# tdnf install -y tar
```
Copiez le nom du pod imprimé lors de l’exécution de la kubectl debug commande. Il ressemble à node-debugger-<node-name>-<random-sufix>. Il peut également être obtenu en énumérant les pods dans l'espace de noms default.

Dans un autre terminal, transférez directement le fichier de profil seccomp vers le nœud :

kubectl cp <the path of the local seccomp profile>/my-profile.json <pod name>:/host/var/lib/kubelet/seccomp/my-profile.json

Remarque

Répétez les étapes précédentes pour chaque nœud du cluster pour vous assurer que le profil seccomp est disponible sur tous les nœuds où votre charge de travail peut s’exécuter.

À présent, vous pouvez modifier la seccompProfile spécification du pod cible, qui doit être limitée aux syscalls enregistrés. Par exemple:

apiVersion: v1
kind: Pod
metadata:
  name: default-pod
  labels:
    app: default-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: my-profile.json
  containers:
  - name: test-container
    image: docker.io/library/nginx:latest

Étape 2 : Installer Inspektor Gadget

Inspektor Gadget fournit des aperçus concernant les syscalls affectant vos conteneurs. Pour l’utiliser, exécutez les commandes suivantes pour installer le gadget plug-in kubectl dans votre hôte et déployer Inspektor Gadget dans le cluster :

kubectl krew install gadget

kubectl gadget deploy

Pour plus d’informations, consultez Comment installer Inspektor Gadget dans un cluster AKS.

Étape 3 : Exécuter le gadget audit_seccomp

Avec Inspektor Gadget installé, démarrez le gadget audit_seccomp à l’aide de la commande kubectl gadget run :

kubectl gadget run audit_seccomp

Étape 4 : Analyser les syscalls bloqués

Exécutez votre charge de travail à l’aide de la kubectl apply -f commande. Ensuite, le gadget audit_seccomp journalise les syscalls que le profil seccomp doit bloquer, ainsi que leurs pods, conteneurs et processus associés. Vous pouvez utiliser ces informations pour identifier les causes racines des défaillances de charge de travail.

Par exemple, si vous exécutez le pod mentionné default-pod ci-dessus avec le my-profile.json profil, la sortie ressemble à la suivante :

K8S.NODE                           K8S.NAMESPACE K8S.PODNAME  K8S.CONTAINERNAME  COMM                 PID      TID  CODE             SYSCALL
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     docker-entrypoi  3996610  3996610  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     docker-entrypoi  3996610  3996610  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     docker-entrypoi  3996610  3996610  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     docker-entrypoi  3996610  3996610  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     docker-entrypoi  3996610  3996610  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     10-listen-on-ip  3996628  3996628  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     10-listen-on-ip  3996628  3996628  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     10-listen-on-ip  3996632  3996632  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     10-listen-on-ip  3996632  3996632  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     10-listen-on-ip  3996632  3996632  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     10-listen-on-ip  3996628  3996628  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     10-listen-on-ip  3996628  3996628  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     20-envsubst-on-  3996639  3996639  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     20-envsubst-on-  3996639  3996639  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     20-envsubst-on-  3996641  3996641  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     30-tune-worker-  3996643  3996643  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     nginx            3996610  3996610  SECCOMP_RET_LOG  SYS_CLONE
aks-nodepool1-38695788-vmss000002  default       default-pod  test-container     nginx            3996610  3996610  SECCOMP_RET_LOG  SYS_CLONE

La sortie indique que le test-container exécute l'appel système SYS_CLONE que le profil seccomp devrait bloquer. Avec ces informations, vous pouvez déterminer s’il faut autoriser les syscalls répertoriés dans votre conteneur. Dans ce cas, ajustez le profil seccomp en les supprimant, ce qui prévient l’échec de la charge de travail.

Voici quelques syscalls couramment bloqués auxquels faire attention. Une liste plus complète est disponible dans les syscalls significatifs bloqués par profil par défaut.

Syscall bloqué	Considération
`clock_settime` ou `clock_adjtime`	Si votre charge de travail a besoin d’une synchronisation de temps précise, vérifiez que ce syscall n’est pas bloqué.
`add_key` ou `key_ctl`	Si votre charge de travail nécessite une gestion des clés, ces syscalls bloqués empêchent les conteneurs d’utiliser le keyring du noyau utilisé pour conserver les données de sécurité, les clés d’authentification, les clés de chiffrement et d’autres données au sein du noyau.
`clone`	Ce syscall empêche le clonage de nouveaux espaces de noms, à l’exception de `CLONE_NEWUSER`. Les charges de travail qui dépendent de la création de nouveaux espaces de noms peuvent être affectées si ce syscall est bloqué.
`io_uring`	Ce syscall est bloqué avec la transition vers la version `containerd` 2.0. Toutefois, il n’est pas bloqué dans le profil pour `containerd` version 1.7.

Étapes suivantes

Si vous rencontrez des problèmes avec vos charges de travail en raison de syscalls bloqués, envisagez d’utiliser un profil seccomp personnalisé adapté aux besoins spécifiques de votre application. Vous pouvez consulter l'Inspektor Gadget advise_seccomp gadget.

Le test et l’affinement des profils seccomp permettent de maintenir les performances et la sécurité des charges de travail AKS. Pour obtenir de l’aide supplémentaire, consultez Le service Informatique sécurisée.

Sécuriser l’accès des conteneurs aux ressources à l’aide des fonctionnalités de sécurité Linux intégrées

Exclusion de responsabilité des informations tierces

Les produits tiers abordés par cet article sont fabriqués par des entreprises indépendantes de Microsoft. Microsoft ne donne aucune garantie, implicite ou autre, concernant la performance ou la fiabilité de ces produits.

Exclusion de responsabilité pour contact avec des tiers

Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent changer sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.

Contactez-nous pour obtenir de l’aide

Si vous avez des questions ou avez besoin d’aide, créez une demande de support ou demandez le support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.