GKE Sandbox

Cette page explique comment GKE Sandbox protège le noyau hôte sur vos nœuds lorsque des conteneurs du pod exécutent un code inconnu ou non approuvé. Par exemple, les clusters mutualisés, tels que les fournisseurs d'applications SaaS (Software as a service), exécutent souvent du code inconnu transmis par leurs utilisateurs. GKE Sandbox est également une mesure de défense en profondeur utile pour l'exécution de conteneurs à forte valeur.

GKE Sandbox utilise gVisor, un projet Open Source. Cet article présente une vue d'ensemble de gVisor. Pour une description plus détaillée, reportez-vous à la documentation officielle de gVisor.

Pour obtenir des instructions concernant l'activation et l'utilisation de GKE Sandbox, consultez la page Configurer GKE Sandbox.

Présentation

GKE Sandbox offre un niveau de sécurité supplémentaire pour empêcher un code non approuvé d'affecter le noyau hôte sur vos nœuds de cluster. Avant d'aborder le fonctionnement de GKE Sandbox, il est important de comprendre la nature des risques potentiels qu'il permet d'atténuer.

Un environnement d'exécution de conteneur 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.

Menaces potentielles

Les clusters mutualisés et les clusters dont les conteneurs exécutent des charges de travail non approuvées sont davantage exposés à des failles de sécurité que les autres clusters. Il peut s'agir, par exemple, de fournisseurs SaaS, de fournisseurs d'hébergement Web ou d'autres organisations qui autorisent leurs utilisateurs à importer et à exécuter du code. Une faille dans l'environnement d'exécution du conteneur ou dans le noyau hôte peut permettre à un processus s'exécutant dans un conteneur "d'échapper" au conteneur et d'affecter le noyau du nœud, entraînant éventuellement sa désactivation.

Un locataire malveillant pourrait également accéder aux données en mémoire ou sur disque d'un autre locataire, et exploiter la faille pour les extraire.

Enfin, une charge de travail non approuvée peut potentiellement accéder à d'autres services Google Cloud ou à des métadonnées de cluster.

Comment GKE Sandbox atténue ces menaces

gVisor est une réimplémentation de l'espace utilisateur de l'API du noyau Linux qui ne nécessite pas de privilèges élevés. Conjointement à un environnement d'exécution de conteneur tel que containerd, le noyau de l'espace utilisateur réimplémente la majorité des appels système et les traite pour le compte du noyau hôte. L'accès direct au noyau hôte est limité. Consultez le Guide d'architecture de gVisor pour obtenir des informations détaillées sur ce fonctionnement. Du point de vue du conteneur, gVisor est quasi transparent et ne nécessite aucune modification de l'application conteneurisée.

Lorsque vous demandez GKE Sandbox dans un pod dans des clusters Autopilot, GKE exécute ce pod dans un bac à sable. Dans GKE Standard, si vous activez GKE Sandbox sur des nœuds, tous les pods qui s'exécutent sur ces nœuds s'exécutent dans des bacs à sable.

Chaque bac à sable utilise son propre noyau d'espace utilisateur. Dans ce contexte, vous pouvez décider de regrouper vos conteneurs dans des pods, en fonction du niveau d'isolation requis et des caractéristiques de vos applications.

GKE Sandbox est particulièrement adapté aux applications suivantes. Pour plus d'informations sur les applications de bac à sable, consultez la section Limites.

  • Applications tierces ou non approuvées utilisant des environnements d'exécution tels que Rust, Java, Python, PHP, Node.js ou Golang
  • Interfaces utilisateur, caches ou proxy du serveur Web
  • Applications de traitement de données ou supports externes utilisant des processeurs
  • Charges de travail de machine learning utilisant des processeurs
  • Applications nécessitant une utilisation intensive du processeur ou de la mémoire
  • Charges de travail nécessitant une utilisation intensive des GPU

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

Dans GKE version 1.29.2-gke.1108000 et ultérieure, GKE Sandbox est compatible avec l'utilisation des GPU NVIDIA.

GKE Sandbox n'atténuera pas toutes les failles du pilote NVIDIA, 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 GPU, consultez le guide d'assistance GPU.

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

  • Seule la version du pilote NVIDIA latest sur une version de GKE donnée est compatible. Les clusters Autopilot installent automatiquement les versions de pilotes NVIDIA compatibles avec GKE Sandbox.
  • Seules les charges de travail CUDA sont acceptées.
  • Les modèles de GPU suivants sont compatibles: nvidia-tesla-t4, nvidia-tesla-a100, nvidia-a100-80gb, nvidia-l4 et nvidia-h100-80gb.

Vous pouvez utiliser GKE Sandbox avec des charges de travail GPU sans frais supplémentaires.

Configuration du pool de nœuds

S'applique aux clusters Standard

  • Vous ne pouvez pas utiliser GKE Sandbox sur des pools de nœuds Windows Server.
  • Vous ne pouvez pas activer par défaut GKE Sandbox sur le pool de nœuds pour séparer les services système exécutés dans le pool de nœuds des charges de travail non approuvées à l'aide de GKE Sandbox.
  • Lorsque vous utilisez GKE Sandbox, votre cluster doit comporter au moins deux pools de nœuds. Vous devez toujours disposer d'au moins un pool de nœuds dans lequel GKE Sandbox est désactivé. Ce pool de nœuds doit contenir au moins un nœud, même si toutes vos charges de travail sont en bac à sable.
  • Les versions de GKE antérieures à la version 1.24.2-gke.300 ne sont pas compatibles avec les types de machines e2-micro, e2-small et e2-medium. Les versions 1.24.2-gke.300 et ultérieures de GKE sont compatibles avec ces types de machines.
  • Les nœuds doivent utiliser l'image de nœud Container-Optimized OS avec containerd (cos_containerd).

Accéder aux métadonnées du cluster

S'applique aux clusters Autopilot et Standard

  • Les nœuds exécutant des pods en bac à sable ne peuvent pas accéder aux métadonnées du cluster au niveau du système d'exploitation sur le nœud.
  • Dans GKE Standard, vous pouvez exécuter des pods standards sur un nœud avec GKE Sandbox activé. Cependant, ces pods standards ne peuvent pas accéder par défaut aux services Google Cloud ni aux métadonnées du cluster.
  • Utilisez la fédération d'identité de charge de travail pour GKE afin d'accorder l'accès aux pods aux services Google Cloud.

Le SMT peut être désactivé

S'applique aux clusters Autopilot et Standard

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

Dans les version de GKE 1.25.5-gke.2500 ou ultérieure et 1.26.0-gke.2500 ou ultérieure, gVisor est configuré pour utiliser la planification de cœur Linux afin de limiter les attaques sur les versions secondaires. Les paramètres SMT restent inchangés par défaut. La planification de cœur n'est utilisée que pour les charges de travail exécutées avec gVisor.

À partir de la version 1.24.2-gke.300 de GKE, le SMT est configuré par type de machine en fonction de la vulnérabilité du type de machine au MDS, comme suit :

  • Pods Autopilot exécutés sur la classe de calcul Scale-Out : SMT désactivé.

  • Types de machines avec processeurs Intel : SMT désactivé par défaut.

  • Types de machines sans processeur Intel : SMT activé par défaut.

  • Types de machines avec un seul thread par cœur : pas de compatibilité SMT. Tous les processeurs virtuels demandés sont visibles.

Avant la version 1.24.2-gke.300, le SMT est désactivé sur tous les types de machines.

Activer le SMT

S'applique aux clusters Standard

Dans les clusters GKE Standard, vous pouvez activer le SMT s'il est désactivé sur le type de machine sélectionné. Chaque processeur virtuel vous est facturé, que vous activiez ou non le mode SMT. Pour en savoir plus sur les tarifs, consultez la page Tarifs de Compute Engine.

GKE version 1.24.2-gke.300 et versions ultérieures

Définissez l'option --threads-per-core lors de la création d'un pool de nœuds GKE Sandbox :

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

Pour en savoir plus sur --threads-per-core, consultez la section Définir le nombre de threads par cœur.

Versions de GKE antérieures à 1.24.2-gke.300

  1. Créez un pool de nœuds portant le libellé de nœud cloud.google.com/gke-smt-disabled=false dans votre cluster :

    gcloud container node-pools create smt-enabled \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --node-labels=cloud.google.com/gke-smt-disabled=false \
    --image-type=cos_containerd \
    --sandbox type=gvisor

  2. Déployez DaemonSet dans le pool de nœuds. 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 leurs fonctionnalités 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, Google Cloud 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

Vous ne pouvez pas utiliser GKE Sandbox avec les fonctionnalités Kubernetes suivantes :

Caractéristiques de la charge de travail

S'applique aux clusters Autopilot et Standard

Imposer un niveau d'indirection supplémentaire pour accéder au noyau du nœud s'accompagne de compromis en termes de performances. GKE Sandbox offre l'avantage le plus tangible pour les grands clusters mutualisés où l'isolation est importante. Gardez à l'esprit les recommandations suivantes lorsque vous testez vos charges de travail avec GKE Sandbox.

Appels système

S'applique aux clusters Autopilot et Standard

Dans un bac à sable, les charges de travail qui génèrent un volume élevé d'appels système à faible charge, tels qu'un grand nombre d'opérations d'E/S de petite taille, peuvent nécessiter des ressources système plus importantes. Vous devrez peut-être utiliser des nœuds plus puissants ou ajouter des nœuds à votre cluster.

Accès direct au matériel ou aux fonctionnalités de virtualisation

S'applique aux clusters Autopilot et Standard

Si votre charge de travail nécessite l'un des éléments suivants, GKE Sandbox peut ne pas convenir, car il empêche l'accès direct au noyau hôte sur le nœud :

  • Accès direct au matériel du nœud
  • Fonctionnalités de virtualisation au niveau du noyau
  • Conteneurs privilégiés

Étape suivante