GKE Sandbox

Les conteneurs qui exécutent du code inconnu ou non approuvé dans les clusters Google Kubernetes Engine (GKE) présentent un risque potentiel pour la sécurité du noyau hôte de vos nœuds. Vous pouvez protéger votre noyau hôte contre ces menaces en isolant le code du noyau. Ce document explique comment GKE Sandbox crée cette couche d'isolation à l'aide de technologies telles que gVisor et les microVM.

Ce document est destiné aux spécialistes de la sécurité qui souhaitent réduire la surface d'attaque dans leurs nœuds GKE et les protéger contre le code non fiable. Vous devez déjà connaître les éléments suivants :

• Appels système
• Architecture des nœuds GKE
• Exécution en bac à sable dans les systèmes informatiques

À propos du sandboxing dans GKE

L'environnement d'exécution de conteneur installé sur les nœuds, tel que containerd, fournit un certain degré d'isolation entre les processus du conteneur et le noyau exécuté sur le nœud. Toutefois, l'environnement d'exécution du conteneur fonctionne souvent en tant qu'utilisateur disposant de privilèges sur le nœud et dispose d'un accès à la plupart des appels système dans le noyau hôte.

Dans Kubernetes et GKE, le bac à sable isole les conteneurs en cours d'exécution pour limiter l'impact potentiel des failles ou des erreurs qui affectent d'autres conteneurs ou l'environnement d'exécution des conteneurs. Vous pouvez exécuter des conteneurs dans des bacs à sable pour protéger le noyau de l'instance Compute Engine sous-jacente contre le code non approuvé ou inconnu. L'exécution en bac à sable est également une bonne mesure de défense en profondeur pour protéger les conteneurs à forte valeur contre les effets d'autres charges de travail. Vous pouvez exécuter des charges de travail dans des bacs à sable à l'aide de GKE Sandbox.

Menaces potentielles

Une faille dans l'environnement d'exécution du conteneur ou dans le noyau hôte pourrait permettre à un processus exécuté dans un conteneur de "s'échapper" du conteneur et d'affecter le noyau du nœud. Les clusters multitenants et les clusters dans lesquels les conteneurs exécutent des charges de travail non fiables sont plus exposés aux failles de sécurité que les autres clusters. Voici quelques exemples :

• Les organisations qui autorisent les utilisateurs à importer et à exécuter du code, comme les fournisseurs SaaS et les fournisseurs d'hébergement Web.
• Agents IA qui génèrent et exécutent du code, souvent sans supervision.

Les technologies de bac à sable utilisées par GKE Sandbox permettent d'atténuer l'impact potentiel des échappements de conteneurs suivants :

• Code malveillant ou défectueux qui plante le noyau de l'hôte et met le nœud hors service.
• Locataires malveillants qui exfiltrent les données d'un autre locataire en mémoire ou sur un disque.
• Charges de travail non fiables qui accèdent à d'autres services Cloud de Confiance by S3NS ou métadonnées de cluster.

Technologies de bac à sable dans GKE

GKE Sandbox est compatible avec les technologies de bac à sable suivantes, qui utilisent chacune une approche différente pour isoler les charges de travail et qui fonctionnent bien pour différents cas d'utilisation :

• gVisor : réimplémentation de l'espace utilisateur de l'API du noyau Linux qui ne nécessite pas de privilèges élevés. Le noyau de l'espace utilisateur et l'environnement d'exécution du conteneur réimplémentent la majorité des appels système et les traitent au nom du noyau hôte. L'accès direct au noyau hôte est limité. Pour en savoir plus sur le fonctionnement du noyau invité, consultez le guide d'architecture gVisor.

• MicroVMs : machines virtuelles légères qui exécutent un noyau et un système d'exploitation Linux complets. Chaque pod s'exécute dans sa propre microVM, ce qui assure une isolation stricte des autres pods et du nœud hôte. GKE Sandbox utilise le logiciel Open Source Kata Containers et le moniteur de machine virtuelle (VMM) Cloud Hypervisor pour créer et gérer des micro-VM.

Le tableau suivant récapitule les principales différences entre gVisor et les microVM. Utilisez ces informations pour choisir la technologie de bac à sable appropriée à votre cas d'utilisation.

Pour en savoir plus sur les applications à exécuter dans un type de bac à sable spécifique, consultez Limites.

Demander des bacs à sable

Pour exécuter une application dans un bac à sable, procédez comme suit :

1. Activez une technologie de bac à sable dans les nœuds en utilisant ComputeClasses pour créer automatiquement les nœuds ou en créant manuellement des pools de nœuds.
2. Demandez un bac à sable pour les pods en utilisant la RuntimeClass correspondante pour ce type de bac à sable, comme gvisor ou microvm. Pour en savoir plus, consultez Renforcer l'isolation d'une charge de travail avec GKE Sandbox.

GKE planifie les pods sur les nœuds qui utilisent la technologie de bac à sable demandée, qui gère ensuite l'exécution de l'application dans le bac à sable. Vous pouvez éventuellement exécuter des pods qui ne demandent pas de bac à sable sur des nœuds sur lesquels GKE Sandbox est activé, à l'aide de sélecteurs et de tolérances de nœuds. Cela est utile pour les charges de travail approuvées, comme les outils de surveillance que vous souhaitez exécuter sur chaque nœud.

Autres recommandations de sécurité

Lorsque vous utilisez GKE Sandbox, nous vous conseillons également de suivre ces recommandations :

• Spécifiez des limites de ressources pour tous les conteneurs s'exécutant dans un bac à sable. Vous éviterez ainsi qu'une application défaillante ou malveillante épuise les ressources du nœud et affecte les autres applications ou processus système exécutés sur le nœud.

• Si vous utilisez la fédération d'identité de charge de travail pour GKE, bloquez l'accès aux métadonnées du cluster à l'aide d'une règle de réseau, de façon à bloquer l'accès à 169.254.169.254. Vous éviterez ainsi qu'une application malveillante accède à des informations sur des données potentiellement privées, telles que l'ID du projet, le nom du nœud et la zone. La fédération d'identité de charge de travail pour GKE est toujours activée dans les clusters GKE Autopilot.

Limites

GKE Sandbox fonctionne bien avec de nombreuses applications, mais pas toutes. Cette section fournit des informations supplémentaires sur les limites actuelles de GKE Sandbox.

GPU dans GKE Sandbox

Vous pouvez exécuter des charges de travail GPU dans des bacs à sable à l'aide de gVisor. gVisor n'atténue pas toutes les failles du pilote NVIDIA, mais conserve une protection contre les failles du noyau Linux. N'utilisez pas le temps partagé des GPU dans les pods en bac à sable, car le GPU n'est pas entièrement isolé entre les pods. Pour en savoir plus sur la manière dont gVisor protège les charges de travail des GPU, consultez le guide d'assistance GPU.

Les limites suivantes s'appliquent aux charges de travail GPU dans GKE Sandbox :

• Les microVM ne sont pas compatibles avec les GPU.
• Pour gVisor, les limites suivantes s'appliquent :
  • Seules les charges de travail CUDA sont acceptées.
  • Seul un sous-ensemble des modèles de GPU disponibles est compatible. Pour en savoir plus, consultez Compatibilité des modèles de GPU.
  • Seules les versions latest et default du pilote NVIDIA sont compatibles avec chaque version de GKE. Il est possible que d'autres versions du pilote ne fonctionnent pas.
  • Toutes les fonctionnalités de GPU, telles que RDMA ou IMEX, ne sont pas compatibles. En fonction des besoins des clients, gVisor peut prendre en charge des fonctionnalités spécifiques au cas par cas. Pour demander de l'aide concernant une fonctionnalité spécifique, ouvrez une demande d'assistance ou ouvrez une demande de fonctionnalité gVisor.

Compatibilité avec les modèles de GPU

Le tableau suivant décrit la compatibilité des différents modèles de GPU avec GKE Sandbox :

TPU dans GKE Sandbox

Dans GKE version 1.31.3-gke.1111001 et ultérieure, vous pouvez exécuter des charges de travail de TPU dans des bacs à sable à l'aide de gVisor. gVisor n'atténue pas toutes les failles du pilote de TPU, mais conserve une protection contre les failles du noyau Linux. Pour en savoir plus sur la manière dont le projet gVisor protège les charges de travail des TPU, consultez le guide d'assistance TPU.

Les limites suivantes s'appliquent aux charges de travail TPU dans GKE Sandbox :

• Les microVM ne sont pas compatibles avec les TPU.

• gVisor est compatible avec les versions de TPU suivantes :

  • V4pod
  • V4lite
  • V5litepod
  • V5pod
  • V6e

Configuration des nœuds

Les limites suivantes s'appliquent aux nœuds qui utilisent GKE Sandbox :

• gVisor et les microVM ne sont compatibles qu'avec les nœuds Linux. Les nœuds Windows Server ne sont pas acceptés.
• gVisor n'est compatible qu'avec l'image de nœud Container-Optimized OS. Les micro-VM sont compatibles avec les images de nœuds Container-Optimized OS et Ubuntu.
• Les microVM nécessitent que la virtualisation imbriquée soit activée sur les nœuds. Toutes les exigences et limites de la virtualisation imbriquée s'appliquent.
• Dans les clusters Standard, vous ne pouvez pas activer GKE Sandbox sur le pool de nœuds par défaut. Le cluster doit toujours comporter au moins un pool de nœuds qui n'utilise pas GKE Sandbox. Ce pool de nœuds doit contenir au moins un nœud, même si toutes vos charges de travail sont en bac à sable. Cette limitation existe pour séparer les services système des charges de travail non approuvées.

Accéder aux métadonnées du cluster

Si vos nœuds utilisent le type de bac à sable gVisor, les pods sur les nœuds ne peuvent pas accéder aux métadonnées du cluster au niveau de l'OS du nœud. Les pods ne peuvent pas non plus accéder aux services Cloud de Confiance, sauf si vous utilisez Workload Identity Federation pour GKE afin d'attribuer des rôles aux identités des pods.

Cette limite ne s'applique pas au type de bac à sable microVM. Pour empêcher l'accès aux métadonnées du cluster depuis les pods des microVM, utilisez une NetworkPolicy qui refuse le trafic de sortie vers 169.254.169.252/32 sur le port 988 ou, dans les clusters qui utilisent GKE Dataplane V2, vers 169.254.169.254/32 sur le port 80.

Le SMT peut être désactivé

Les paramètres de multithreading simultané (SMT, également appelé Hyper-Threading sur les processeurs Intel) permettent d'atténuer les failles des versions secondaires qui exploitent l'état de partage des threads (failles Microarchitectural Data Sampling (MDS), par exemple).

Pour limiter les attaques sur les canaux auxiliaires, gVisor utilise la planification de cœur Linux. Les paramètres SMT restent inchangés par rapport aux valeurs par défaut. La planification de cœur Linux ne s'applique qu'aux pods qui s'exécutent dans des bacs à sable gVisor.

Le paramètre SMT ou Hyper-Threading par défaut pour un type de machine dépend de la vulnérabilité de la machine au MDS, comme suit :

• Pods Autopilot qui utilisent la ComputeClass Scale-Out : le SMT est toujours désactivé.
• Types de machines utilisant des processeurs Intel : l'hyperthreading est désactivé par défaut.
• Types de machines utilisant des processeurs AMD : le SMT est activé par défaut.
• Types de machines qui n'utilisent qu'un seul thread par cœur, tels que les processeurs Arm : pas de compatibilité SMT. Tous les processeurs virtuels demandés sont visibles.

Activer le SMT

Dans les pools de nœuds GKE Standard, vous pouvez activer le SMT s'il est désactivé par défaut pour le type de machine sélectionné. Chaque processeur virtuel vous est facturé, que vous activiez ou non le mode SMT. Pour en savoir plus, consultez les tarifs lorsque vous modifiez le nombre de threads par cœur. Pour modifier le paramètre SMT, effectuez l'une des opérations suivantes :

• Définissez l'option --threads-per-core lorsque vous créez un pool de nœuds GKE Sandbox qui utilise gVisor :

  gcloud container node-pools create smt-enabled \
      --cluster=CLUSTER_NAME \
      --location=LOCATION \
      --machine-type=MACHINE_TYPE \
      --threads-per-core=2 \
      --sandbox=type=gvisor
  

  • CLUSTER_NAME : nom d'un cluster existant dans lequel vous souhaitez créer le pool de nœuds.
  • LOCATION : région ou zone Compute Engine du cluster.
  • MACHINE_TYPE : type de machine

• Utilisez un DaemonSet pour activer le SMT sur un pool de nœuds existant :

  1. Ajoutez le libellé de nœud cloud.google.com/gke-smt-disabled=false à un pool de nœuds existant qui utilise gVisor :

     gcloud container node-pools update NODE_POOL_NAME \
         --cluster=CLUSTER_NAME \
         --location=LOCATION \
         --node-labels=cloud.google.com/gke-smt-disabled=false
     

     Remplacez les éléments suivants :

     • NODE_POOL_NAME : nom du pool de nœuds existant.
     • CLUSTER_NAME : nom d'un cluster existant dans lequel vous souhaitez créer le pool de nœuds.
     • LOCATION : région ou zone Compute Engine du cluster.

  2. Déployez le DaemonSet. DaemonSet ne s'exécute que sur les nœuds portant le libellé cloud.google.com/gke-smt-disabled=false.

     kubectl create -f \
         https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml
     

  3. Assurez-vous que les pods DaemonSet sont en cours d'exécution.

     kubectl get pods --selector=name=enable-smt -n kube-system
     

     Le résultat ressemble à ce qui suit :

     NAME               READY     STATUS    RESTARTS   AGE
     enable-smt-2xnnc   1/1       Running   0          6m
     

  4. Vérifiez que SMT has been enabled apparaît dans les journaux des pods :

     kubectl logs enable-smt-2xnnc enable-smt -n kube-system
     

Capacités

S'applique aux clusters Standard

Par défaut, le conteneur ne peut pas ouvrir de socket brut afin de réduire le risque d'attaques malveillantes. Certains outils réseau, tels que ping et tcpdump, créent des sockets bruts dans le cadre de leur fonctionnement de base. Pour activer les sockets bruts, vous devez explicitement ajouter la fonctionnalité NET_RAW au contexte de sécurité du conteneur :

spec:
  containers:
  - name: my-container
    securityContext:
      capabilities:
        add: ["NET_RAW"]

Si vous utilisez GKE Autopilot, Cloud de Confiance vous empêche d'ajouter l'autorisation NET_RAW aux conteneurs en raison des implications de sécurité de cette fonctionnalité.

Dépendances externes

S'applique aux clusters Autopilot et Standard

Le code non approuvé exécuté dans le bac à sable peut être autorisé à atteindre des services externes tels que des serveurs de base de données, des API, d'autres conteneurs et des pilotes CSI. Ces services sont exécutés en dehors de la limite du bac à sable et doivent être protégés individuellement. Un pirate informatique peut tenter d'exploiter les failles de ces services pour sortir du bac à sable. Vous devez tenir compte du risque et de l'impact de l'accès à ces services par le code exécuté dans le bac à sable, et appliquer les mesures nécessaires pour les sécuriser.

Cela inclut l'implémentation de systèmes de fichiers pour les volumes de conteneurs, par exemple ext4 et les pilotes CSI. Les pilotes CSI s'exécutent en dehors de l'isolation du bac à sable et peuvent avoir un accès privilégié à l'hôte et aux services. Une exploitation de ces pilotes peut affecter le noyau hôte et compromettre l'intégralité du nœud. Nous vous recommandons d'exécuter le pilote CSI dans un conteneur disposant uniquement des autorisations indispensables afin de réduire l'exposition en cas d'exploitation. GKE Sandbox est compatible avec le pilote CSI de disque persistant Compute Engine.

Fonctionnalités incompatibles

Les limites de fonctionnalités suivantes s'appliquent à GKE Sandbox :

• Les limites suivantes s'appliquent aux bacs à sable gVisor et microVM :

  • Cloud Service Mesh n'est pas compatible avec les bacs à sable dans les clusters Autopilot.
  • Les modules de sécurité du noyau Linux tels que seccomp, AppArmor, SELinux, l'indicateur "No New Privileges", la propagation bidirectionnelle des montages et le contexte de sécurité des pods procMount ne sont pas compatibles avec les pods en bac à sable.
  • Les métriques d'utilisation de la mémoire au niveau du conteneur ne sont pas compatibles. Toutefois, l'utilisation de la mémoire des pods est acceptée.

• Les limites suivantes ne s'appliquent qu'aux bacs à sable gVisor :

  • Les conteneurs qui utilisent le mode privilégié ne sont pas compatibles.
  • Les volumes de blocs bruts ne sont pas acceptés.
  • Le transfert de port, par exemple à l'aide de kubectl port-forward, n'est pas pris en charge.
  • Le stockage Hostpath n'est pas accepté.
  • Le paramétrage des paramètres du noyau sysctl n'est pas pris en charge.
  • Les limites de processeur et de mémoire ne sont appliquées qu'aux pods qui ont les classes QoS Guaranteed ou Burstable, et uniquement lorsque les limites de processeur et de mémoire sont spécifiées pour tous les conteneurs du pod.

• Les limites suivantes ne s'appliquent qu'aux bacs à sable de microVM :

  • Les pods qui utilisent le paramètre hostNetwork: true ne sont pas compatibles. Les pods qui s'exécutent dans un bac à sable de microVM et qui utilisent le paramètre hostNetwork: true ne peuvent accéder à aucune ressource en dehors du pod.
  • Tous les outils de diagnostic qui s'appuient sur le traçage au niveau du socket ne peuvent accéder qu'aux interfaces réseau associées à la microVM.

Étapes suivantes

• Apprenez à configurer GKE Sandbox.
• Consultez la présentation de la sécurité.
• En savoir plus sur le cycle de vie d'un pod (en anglais).