À propos de seccomp dans GKE

Autopilot Standard

Cette page fournit des informations sur le mode de calcul sécurisé Linux (seccomp) dans Google Kubernetes Engine (GKE). Utilisez ces informations pour comprendre quelles actions vos applications en conteneur peuvent effectuer sur la machine virtuelle (VM) hôte qui sauvegarde vos nœuds.

Qu'est-ce que seccomp ?

Le mode de calcul sécurisé, ou seccomp, est une fonctionnalité de sécurité de Linux qui vous permet de limiter les appels système (syscalls) qu'un processus peut effectuer sur le noyau Linux.

Par défaut, les nœuds GKE utilisent le Système d'exploitation Container-Optimized OS avec l'environnement d'exécution du conteneurcontainerd. containerd protège le noyau Linux en limitant le nombre de fonctionnalités Linux autorisées à une liste par défaut. Vous pouvez limiter davantage les appels système autorisés avec un profil seccomp. containerd dispose d'un profil seccomp par défaut disponible. La manière dont GKE applique le profil seccomp par défaut dépend du mode de cluster que vous utilisez, tel que :

Autopilot (recommandé): GKE applique automatiquement le profil seccomp par défaut de containerd à toutes les charges de travail.
Standard : GKE n'applique pas automatiquement le profil seccomp par défaut de containerd à toutes les charges de travail. Nous vous recommandons d'appliquer le profil seccomp par défaut ou un profil seccomp personnalisé à vos charges de travail.

Le profil seccomp par défaut de containerd fournit un renforcement de référence tout en maintenant la compatibilité avec la plupart des charges de travail. La définition complète du profil seccomp pour containerd est disponible sur GitHub.

Fonctionnalités Linux et appels système

Les processus non racine exécutés sur des systèmes Linux peuvent nécessiter des privilèges spécifiques pour effectuer des actions en tant qu'utilisateur racine. Linux utilise des fonctionnalités pour diviser les privilèges disponibles en groupes, afin qu'un processus non racine puisse effectuer une action spécifique sans disposer de tous les privilèges. Pour qu'un processus puisse effectuer un appel système spécifique, il doit disposer des droits correspondants.

Pour obtenir la liste de toutes les fonctionnalités Linux, consultez la page Fonctionnalités.

Appels système refusés dans le profil seccomp GKE par défaut

Le profil seccomp par défaut de containerd bloque tous les appels système, puis autorise de manière sélective des appels système spécifiques, dont certains dépendent de l'architecture de processeur de la VM du nœud et de la version du noyau. La variable syscalls de la fonction DefaultProfile répertorie les appels système autorisés pour toutes les architectures.

Le profil seccomp par défaut bloque les appels système pouvant être utilisés pour contourner les limites d'isolation des conteneurs et autoriser un accès privilégié au nœud ou à d'autres conteneurs. Le tableau suivant décrit certains des appels système importants que le profil seccomp par défaut refuse:

Appels système refusés
`mount`, `umount`, `umount2`, `fsmount`, `mount_setattr`	Empêcher les processus d'accéder au système de fichiers de nœud ou de le manipuler en dehors des limites du conteneur. Refusé également, car la fonctionnalité `CAP_SYS_ADMIN` a été supprimée.
`bpf`	Empêcher les processus de créer des programmes eBPF dans le noyau, ce qui peut entraîner une élévation des privilèges sur le nœud. Par exemple, CVE-2021-3490 a utilisé l'appel système `bpf`. Refusé également, car la fonctionnalité `CAP_SYS_ADMIN` a été supprimée.
`clone`, `clone3` et `unshare`	Empêcher les processus de créer des processus dans de nouveaux espaces de noms qui peuvent se trouver en dehors de l'espace de noms restreint du conteneur. Ces nouveaux processus peuvent avoir des autorisations et des capacités élevées. Par exemple, CVE-2022-0185 a utilisé l'appel système `unshare`. Refusé également, car la fonctionnalité `CAP_SYS_ADMIN` a été supprimée.
`reboot`	Empêcher les processus de redémarrer le nœud. Refusé également, car la fonctionnalité `CAP_SYS_BOOT` a été supprimée.
`open_by_handle_at`, `name_to_handle_at`	Restreindre l'accès aux fichiers en dehors du conteneur. Ces appels système ont été utilisés dans l'une des premières exploitations de fuite de conteneur Docker. Également refusée, car les fonctionnalités `CAP_DAC_READ_SEARCH` et `CAP_SYS_ADMIN` ont été supprimées.

Utiliser seccomp dans GKE

Dans les clusters Autopilot, GKE applique automatiquement le profil seccomp par défaut de containerd à toutes vos charges de travail. Aucune action supplémentaire n'est requise. Les tentatives d'exécution d'appels système restreints échouent. Autopilot interdit les profils seccomp personnalisés, car GKE gère les nœuds.

Dans les clusters standards, vous devez appliquer manuellement un profil seccomp. GKE n'applique pas de profil pour vous.

Activer seccomp dans les clusters standards

Appliquez un profil seccomp manuellement en définissant le contexte de sécurité du pod ou du conteneur à l'aide du champ spec.securityContext.seccompProfile de la spécification de pod, comme dans l'exemple suivant. Nous vous recommandons vivement d'utiliser un profil seccomp pour vos charges de travail, sauf si votre cas d'utilisation nécessite des appels système restreints. Les deux types seccompProfile acceptés sont les suivants:

RuntimeDefault: profil par défaut spécifié par l'environnement d'exécution containerd.
Localhost: définition de profil personnalisé.

L'exemple de fichier manifeste suivant définit le profil seccomp sur le profil par défaut de l'environnement d'exécution :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: default-pod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: default-pod
  template:
    metadata:
      labels:
        app: default-pod
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: seccomp-test
        image: nginx

Lorsque vous déployez ce fichier manifeste, si un conteneur du pod tente d'effectuer un appel système qui ne respecte pas le profil seccomp par défaut de l'environnement d'exécution, le pod ou la charge de travail peuvent rencontrer un comportement inattendu. Par exemple, un pod qui effectue un appel système restreint au démarrage échoue. Si une application tente d'effectuer un appel système restreint pendant l'exécution du pod, vous remarquerez peut-être des erreurs dans le conteneur. La gravité d'un appel système ayant échoué dépend de la façon dont l'application traite les erreurs.

Utiliser un profil seccomp personnalisé dans les clusters standards

Si le profil seccomp par défaut de l'environnement d'exécution est trop restrictif pour votre application (ou pas suffisamment restrictif), vous pouvez appliquer un profil seccomp personnalisé aux pods des clusters standards. Ce processus nécessite l'accès au système de fichiers sur le nœud. Pour accéder au tutoriel sur le chargement et l'utilisation de profils seccomp personnalisés, consultez la page Restreindre les appels système d'un conteneur avec seccomp.