À propos de seccomp dans GKE

Autopilot Standard

Cette page fournit des informations sur le mode de calcul sécurisé de Linux (seccomp) dans Google Kubernetes Engine (GKE). Utilisez ces informations pour comprendre quelles actions vos applications conteneurisées peuvent effectuer sur la machine virtuelle (VM) hôte qui est la base de 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 base 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 racines exécutés sur des systèmes Linux peuvent nécessiter des droits spécifiques pour effectuer des actions en tant qu'utilisateur racine. Linux utilise des fonctionnalités permettant de 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 privilèges correspondants accordés par une capacité.

Pour obtenir la liste de toutes les fonctionnalités Linux, consultez la section 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 du processeur de la VM du nœud et de la version du kernel. La variable syscalls dans la fonction DefaultProfile liste 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 à ou de manipuler le système de fichiers du nœud en dehors des limites du conteneur. Refusé également, car la capacité `CAP_SYS_ADMIN` est abandonné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, la faille CVE-2021-3490 utilisait la fonction système `bpf`. Également refusé, car la fonctionnalité `CAP_SYS_ADMIN` est supprimée.
`clone`, `clone3`, `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 disposer d'autorisations et de capacités élevées. Par exemple, la faille CVE-2022-0185 utilisait la fonction système `unshare`. Également refusé, car la fonctionnalité `CAP_SYS_ADMIN` est supprimée.
`reboot`	Empêcher les processus de redémarrer le nœud. Refusé également, car la capacité `CAP_SYS_BOOT` est abandonné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. Refusé également, car la capacité `CAP_DAC_READ_SEARCH` et la capacité `CAP_SYS_ADMIN` sont abandonné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. Tentatives d'échec des appels système limités. 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 dans la spécification du 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 d'utiliser des appels système restreints. Les deux types de 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 peut manifester 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 limité pendant l'exécution du pod, vous pouvez remarquer des erreurs dans le conteneur. La gravité d'un appel système ayant échoué dépend de la manière dont l'application gère 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 assez restrictif), vous pouvez appliquer un profil seccomp personnalisé aux pods des clusters standards. Ce processus nécessite un 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.