Fonctionnalités de sécurité de GKE Autopilot

Cette page décrit les fonctionnalités, les configurations et les paramètres de sécurité dans Google Kubernetes Engine (GKE) Autopilot, qui est la méthode recommandée pour exécuter GKE.

À qui cette page est-elle destinée ?

Cette page est destinée aux administrateurs de sécurité qui souhaitent comprendre les restrictions de sécurité que Google applique spécifiquement aux clusters Autopilot, ainsi que les fonctionnalités de sécurité disponibles pour Autopilot.

Consultez également la présentation de la sécurité dans GKE, qui décrit les options, mesures et recommandations de renforcement qui s'appliquent à tous les clusters, configurations réseau et charges de travail GKE.

Mesures de sécurité dans Autopilot

Les clusters Autopilot activent et appliquent les bonnes pratiques et les paramètres de sécurité par défaut, y compris de nombreuses recommandations fournies dans la présentation de la sécurité et la section Renforcer la sécurité des clusters.

Si vous souhaitez obtenir des ressources recommandées en fonction de votre cas d'utilisation, passez à la section Ressources de sécurité par cas d'utilisation. Les sections suivantes décrivent les stratégies de sécurité qu'Autopilot applique à votre compte.

Autopilot et les normes de sécurité des pods Kubernetes

Le projet Kubernetes dispose d'un ensemble de consignes de sécurité nommées normes de sécurité des pods qui définissent les stratégies suivantes :

  • Accès restreint : aucune restriction d'accès. Non utilisé dans Autopilot.
  • Référence : empêche les élévations des privilèges connues. Autorise l'exécution de la plupart des charges de travail sans imposer de changements significatifs.
  • Accès limité : niveau de sécurité le plus élevé. Nécessite des changements significatifs pour la plupart des charges de travail.

Autopilot applique la stratégie de référence, avec quelques modifications par souci d'usabilité. Autopilot applique également de nombreuses contraintes de la stratégie restreinte, mais évite les restrictions qui empêchent l'exécution de la majorité de vos charges de travail. Autopilot applique ces contraintes au niveau du cluster à l'aide d'un contrôleur d'admission géré par Google. Si vous devez appliquer des restrictions supplémentaires pour vous conformer à la stratégie "Limité" complète, vous pouvez éventuellement utiliser le contrôleur d'admission PodSecurity dans des espaces de noms spécifiques.

Le tableau suivant décrit la façon dont les clusters Autopilot mettent en œuvre les stratégies de référence et les stratégies restreintes. Pour obtenir la description de chaque commande de ce tableau, consultez l'entrée correspondante dans la section Normes de sécurité des pods.

Pour évaluer la conformité, nous avons tenu compte de la façon dont les contraintes s'appliquent à vos propres charges de travail. Cela exclut les charges de travail des partenaires Google Cloud vérifiés et les charges de travail système, dont l'exécution nécessite des droits spécifiques.

Contrôle Conformité avec la stratégie de référence Conformité avec la stratégie "Limité" Informations supplémentaires
HostProcess Autopilot bloque HostProcess.
Espaces de noms d'hôte Autopilot bloque les espaces de noms d'hôte. Certains conteneurs de partenaires agréés sont autorisés à utiliser des espaces de noms hôtes.
Conteneurs privilégiés Autopilot bloque les conteneurs privilégiés par défaut. Autopilot autorise les conteneurs privilégiés de partenaires agréés pour l'exécution d'outils de sécurité et de surveillance.
Fonctionnalités Linux

Par défaut, les charges de travail Autopilot ne peuvent accéder qu'aux fonctionnalités spécifiées dans la norme de sécurité des pods de référence.

Vous pouvez activer manuellement les fonctionnalités suivantes :

  • NET_RAW pour le ping et SYS_PTRACE pour le débogage : à ajouter au champ SecurityContext du pod
  • NET_ADMIN pour les maillages de services tels qu'Istio : spécifiez --workload-policies=allow-net-admin dans votre commande de création de cluster. Disponible sur les clusters nouveaux et mis à niveau qui exécutent GKE 1.27 ou une version ultérieure.

Autopilot permet également à certaines charges de travail partenaires agréées de définir des fonctionnalités abandonnées.
Volumes HostPath Conformité partielle Conformité partielle Autopilot permet aux conteneurs de demander un accès en lecture seule à /var/log pour le débogage, mais refuse tout autre accès en lecture ou en écriture.
HostPorts La définition de ports hôtes spécifiques n'est pas autorisée, ce qui limite certains problèmes de planification et empêche l'exposition accidentelle ou volontaire de réseau des services. Vous pouvez configurer manuellement l'attribution de ports hôtes aléatoires à partir d'une plage connue pour accepter les applications réseau de connexion directe, telles que les serveurs de jeu.
AppArmor Le profil de sécurité AppArmor par défaut de Docker est appliqué automatiquement à Container-Optimized OS.
SELinux SELinux n'est pas appliqué car AppArmor est déjà appliqué. SELinux n'est pas non plus obligatoire dans les normes de sécurité des pods.
Type d'installation /proc GKE ne définit pas le flag de fonctionnalité ProcMountType. Si le champ securityContext du pod définit procMount sur "Unmasked" (non masqué), GKE le remplace automatiquement par "Default" (défaut).
profil seccomp Autopilot applique le profil seccomp RuntimeDefault à toutes les charges de travail. Vous pouvez remplacer ce paramètre manuellement par des charges de travail spécifiques en définissant le profil sur Unconfined dans la spécification du pod.
sysctls GKE ne définit pas l'option kubelet --allowed-unsafe-sysctls. Par conséquent, la programmation des pods avec des sysctls non sécurisés échoue. Pour une protection supplémentaire, à compter du 11 juillet 2023, les nouveaux clusters en versions 1.27 et ultérieures disposent également d'une règle de stratégie pour forcer les paramètres securityContext et rejeter les pods qui utilisent des sysctls non sécurisés.
Types de volumes Autopilot n'autorise que les types de volumes dans la stratégie "Limité" avec les ajouts suivants : volumes HostPath avec accès en lecture seule à /var/log pour le débogage, gcePersistentDisk pour les disques persistants Compute Engine et nfs pour les volumes NFS.
Élévation des privilèges Ce paramètre n'offre une protection qu'aux conteneurs qui ne sont pas exécutés en tant qu'utilisateur racine. Selon une étude du secteur, 76 % des conteneurs s'exécutent en mode root. Par conséquent, Autopilot permet l'exécution en mode root pour autoriser la plupart des charges de travail. Ce paramètre est également utile pour supprimer les droits des charges de travail et les faire passer en utilisateur non racine, en autorisant l'utilisation des fonctionnalités du système de fichiers, afin de contourner les défaillances liées à la gestion des fonctionnalités racine de Kubernetes.
Exécuter en mode non racine Selon une étude du secteur, 76 % des conteneurs s'exécutent en mode root. Par conséquent, Autopilot permet l'exécution en mode root pour autoriser la plupart des charges de travail.
Exécuter en tant qu'utilisateur non racine Les conteneurs peuvent définir runAsUser sur 0. Selon une étude du secteur, 76 % des conteneurs s'exécutent en mode root. Par conséquent, Autopilot permet l'exécution en mode root pour autoriser la plupart des charges de travail.

Configurations de sécurité intégrées

Google applique de nombreux paramètres de sécurité intégrés aux clusters Autopilot en fonction des bonnes pratiques du secteur et de notre expertise. Le tableau suivant décrit certaines des configurations de sécurité qu'Autopilot applique pour vous :

Configuration Description
Options d'hôte
Fonctionnalités Linux

Vous pouvez utiliser les fonctionnalités Linux suivantes :

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE"

Vous pouvez aussi activer manuellement les fonctionnalités suivantes :

  • NET_RAW pour le ping : à ajouter au champSecurityContext du pod.
  • SYS_PTRACE pour le débogage : à ajouter au champ SecurityContext du pod.
  • NET_ADMIN pour les maillages de services tels qu'Istio : utilisez --workload-policies=allow-net-admin lorsque vous créez un cluster ou mettez à jour un cluster existant. Ensuite, ajoutez la fonctionnalité au champ SecurityContext du pod. Disponible sur GKE 1.27 et versions ultérieures.

Dans les versions de GKE antérieures à la version 1.21, la fonctionnalité "SYS_PTRACE" n'est pas prise en charge.
Conteneurs privilégiés Les conteneurs ne peuvent pas être exécutés en mode privilégié, sauf s'ils sont déployés par un partenaire Google Cloud. Les conteneurs privilégiés peuvent modifier le nœud sous-jacent, par exemple en modifiant le kubelet. Cet accès peut augmenter l'impact d'un piratage de pod.
Espaces de noms gérés par GKE Par mesure de sécurité, Autopilot n'autorise pas le déploiement de charges de travail dans les espaces de noms gérés par GKE, tels que kube-system.
Isolement du conteneur

Autopilot applique les restrictions suivantes sur les conteneurs pour limiter l'impact des failles de fuite de conteneur.

Fonctionnalités Linux et sécurité du noyau

  • Autopilot applique le profil seccomp RuntimeDefault à tous les pods du cluster, sauf si les pods utilisent GKE Sandbox. GKE Sandbox applique l'isolation de l'hôte et ignore les règles seccomp spécifiées dans le fichier manifeste du pod. Le bac à sable est considéré comme la limite de sécurité pour les pods GKE Sandbox.
  • Autopilot supprime la fonctionnalité Linux CAP_NET_RAW pour tous les conteneurs. Cette autorisation n'est pas souvent utilisée et a été la cible de plusieurs failles de fuite. La commande ping peut échouer dans vos conteneurs, car cette fonctionnalité est supprimée. Vous pouvez réactiver manuellement cette fonctionnalité en la définissant dans le champ SecurityContext de votre Pod.
  • Autopilot supprime la fonctionnalité Linux CAP_NET_ADMIN pour tous les conteneurs. Pour réactiver cette fonctionnalité, spécifiez l'option --workload-policies=allow-net-admin dans votre commande de création ou de mise à jour de cluster. NET_ADMIN est requis par certaines charges de travail telles qu'Istio.
  • Autopilot active la fédération d'identité de charge de travail pour GKE, qui empêche l'accès du pod aux métadonnées sensibles sur le nœud.
  • Autopilot bloque les services Kubernetes qui définissent le champ spec.externalIPs afin d'assurer la protection contre la faille CVE-2020-8554.

  • Autopilot n'autorise que les types de volumes suivants :

    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "nfs", "persistentVolumeClaim", "projected", "secret"

    Les autres types de volumes sont bloqués, car ils nécessitent des privilèges de nœud. Les volumes HostPath sont bloqués par défaut, mais les conteneurs peuvent demander un accès en lecture seule aux chemins /var/log, à des fins de débogage.
Application des règles de sécurité au niveau des pods Autopilot est compatible avec les mécanismes d'application des règles de sécurité au niveau des pods, tels que le contrôleur d'admission PodSecurity, Gatekeeper ou Policy Controller. Cependant, vous n'aurez peut-être pas besoin d'utiliser ces options si les configurations de sécurité intégrées décrites sur cette page répondent déjà à vos exigences.
Connexion aux nœuds via SSH

Autopilot bloque l'accès SSH aux nœuds. GKE gère tous les aspects du fonctionnement des nœuds, y compris leur état et l'ensemble des composants Kubernetes qui s'y exécutent.

Vous pouvez toujours vous connecter à distance à vos conteneurs en cours d'exécution à l'aide de la fonctionnalité Kubernetes exec afin d'exécuter des commandes dans vos conteneurs pour le débogage, y compris en vous connectant à un shell interactif, par exemple avec kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh.
Emprunt d'identité Les versions 1.22.4-gke.1501 et ultérieures de GKE sont compatibles avec l'emprunt d'identité d'utilisateur pour tous les utilisateurs et groupes définis par l'utilisateur. Les utilisateurs et les groupes système tels que l'utilisateur kube-apiserver et le groupe system:masters ne peuvent pas être usurpés.
Webhooks d'admission dynamiques de mutation

Autopilot modifie les webhooks de mutation pour exclure les ressources dans les espaces de noms gérés, tels que kube-system, du processus d'interception.

Autopilot rejette également les webhooks qui spécifient une ou plusieurs des ressources suivantes, ainsi que les sous-ressources de ces ressources.

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Vous ne pouvez pas utiliser le caractère générique * pour les ressources ou les groupes afin de contourner cette restriction.
ValidatingAdmissionPolicies

Autopilot modifie les objets ValidatingAdmissionPolicy afin d'éviter que des ressources figurant dans les espaces de noms gérés, tels que kube-system, ne soient interceptées.

Autopilot rejette également les objets ValidatingAdmissionPolicy qui spécifient une ou plusieurs des ressources suivantes, ainsi que les sous-ressources de ces ressources.

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Vous ne pouvez pas utiliser le caractère générique * pour les ressources ou les groupes afin de contourner cette restriction.
Demandes de signature de certificat Vous pouvez créer des requêtes CertificateSigningRequests dans Autopilot pour créer des certificats signés par l'autorité de certification du cluster. Pour éviter les interférences avec les composants système, Autopilot rejette les requêtes CertificateSigningRequests pour les identités privilégiées connues, telles que les groupes système, les agents système ou les agents de service IAM gérés par Google.
Fonctionnalités de sécurité de GKE Les clusters Autopilot activent les fonctionnalités de sécurité GKE recommandées. Pour obtenir la liste des fonctionnalités de sécurité activées et facultatives, consultez la section Fonctionnalités de sécurité dans Autopilot.
Système d'exploitation du nœud Les clusters Autopilot utilisent Container-Optimized OS avec containerd comme système d'exploitation des nœuds. Container-Optimized OS est créé et géré par Google.
Mises à niveau des versions de GKE Les clusters Autopilot sont enregistrés dans une version disponible GKE lors de leur création, et les mises à niveau automatiques sont toujours activées. Au fil du temps, Google met automatiquement à niveau votre plan de contrôle et vos nœuds vers la dernière version qualifiée disponible.

Limites de sécurité dans Autopilot

Autopilot fournit un accès à l'API Kubernetes mais supprime les autorisations nécessaires à l'utilisation de certaines fonctionnalités Kubernetes à privilèges élevés, telles que les pods privilégiés. L'objectif est de limiter la capacité d'accès, de modification ou de contrôle direct de la machine virtuelle (VM) des nœuds. Autopilot implémente ces restrictions afin d'empêcher les charges de travail de disposer d'un accès de bas niveau à la VM de nœud, pour que Google Cloud puisse proposer une gestion complète des nœuds et un SLA au niveau du pod.

Notre objectif consiste à empêcher tout accès involontaire à la VM du nœud. Nous acceptons les envois à cet effet via l'Initiative Vulnerability Reward Program (VRP) de Google et nous récompenserons les rapports, à la discrétion du panneau de récompense VRP de Google.

Par principe, les utilisateurs privilégiés tels que les administrateurs de cluster ont un contrôle total sur tout cluster GKE. Pour respecter nos bonnes pratiques de sécurité, nous vous recommandons d'éviter d'attribuer des droits GKE ou Kubernetes étendus, et de privilégier chaque fois que cela est possible la délégation d'administrateur d'espace de noms, comme décrit dans nos conseils sur l'architecture mutualisée.

Autopilot provisionne des VM à locataire unique dans votre projet pour votre usage exclusif. Sur chaque VM, vos charges de travail Autopilot peuvent s'exécuter ensemble en partageant un noyau à sécurité renforcée. Étant donné que le noyau partagé représente une limite de sécurité unique, si vous avez besoin d'une isolation importante telle que des charges de travail à haut risque ou non approuvées, nous vous recommandons d'exécuter vos charges de travail sur des pods GKE Sandbox afin d'assurer une protection multicouche.

Ressources de sécurité en fonction des cas d'utilisation

Les sections suivantes vous fournissent des liens et des recommandations pour planifier, implémenter et gérer la sécurité de vos clusters Autopilot en fonction de votre cas d'utilisation.

Planifier la sécurité des clusters

Cas d'utilisation Ressources
Comprendre comment GKE en tant que plate-forme aborde la sécurité
Comprendre votre rôle dans le renforcement de votre environnement Apprenez-en plus sur le modèle de responsabilité partagée.
Afficher les recommandations de Google concernant les mesures de renforcement de la sécurité et la gestion des incidents
Comprendre comment GKE implémente la journalisation d'audit

Authentification et autorisation

Après avoir configuré vos clusters Autopilot, vous devrez peut-être authentifier vos utilisateurs et applications pour utiliser des ressources telles que l'API Kubernetes ou les API Google Cloud.

Cas d'utilisation Ressources
Authentifier des utilisateurs ou des applications auprès du serveur d'API du cluster
  • Pour authentifier des utilisateurs, consultez la section Authentifier les utilisateurs.
  • Pour authentifier des applications, consultez la section Authentifier des applications, qui fournit des étapes d'authentification depuis des applications du même cluster, d'autres environnements Google Cloud ou d'environnements externes.
Authentifier des applications auprès des API et services Google Cloud Les clusters Autopilot vous permettent d'utiliser la fédération d'identité de charge de travail pour GKE afin d'authentifier de façon sécurisée vos charges de travail auprès des API Google Cloud, en configurant des comptes de service Kubernetes qui agiront en tant que comptes de service IAM. Pour obtenir des instructions, consultez la page Configurer des applications pour utiliser la fédération d'identité de charge de travail pour GKE.
Autoriser des actions au niveau du projet Pour autoriser des actions sur les clusters au niveau du projet, utilisez IAM. Vous pouvez accorder ou refuser l'accès à des ressources d'API GKE et Kubernetes spécifiques à l'aide de rôles et d'autorisations IAM. Pour obtenir des instructions, consultez la section Créer des stratégies IAM.
Autoriser des actions au niveau du cluster Pour autoriser des actions sur les ressources de l'API Kubernetes dans des clusters spécifiques, utilisez le mécanisme intégré de contrôle des accès basé sur les rôles (RBAC) de Kubernetes. Pour obtenir des instructions, consultez la section Autoriser des actions dans les clusters à l'aide de RBAC.
Autoriser des actions au niveau de l'organisation Vous pouvez utiliser le service de règles d'administration Google Cloud pour appliquer des contraintes sur des opérations spécifiques sur les ressources GKE au sein de votre organisation Google Cloud. Pour obtenir des instructions, consultez la section Limiter les actions sur les ressources GKE à l'aide de règles d'administration personnalisées.

Renforcer les clusters et les charges de travail

Si vous avez des besoins spécifiques en matière d'isolation ou de renforcement de la sécurité au-delà des mesures préconfigurées d'Autopilot, voici quelques ressources qui pourraient vous intéresser :

Cas d'utilisation Ressources
Limiter l'accès public à votre point de terminaison de cluster Créez vos clusters Autopilot en tant que clusters privés, ce qui désactive l'adresse IP publique du plan de contrôle du cluster. Pour obtenir des instructions, consultez la section Clusters privés.
Limiter l'accès au cluster à des réseaux spécifiques Utilisez les réseaux autorisés du plan de contrôle pour spécifier les plages d'adresses IP pouvant accéder à votre cluster.
Stocker des informations sensibles en dehors de votre cluster Stocker les données sensibles dans un fournisseur de stockage externe chiffré et avec la gestion des versions activée est une exigence de conformité courante et une bonne pratique. Utilisez Secret Manager pour stocker vos données et y accéder à partir de vos clusters Autopilot à l'aide de la fédération d'identité de charge de travail pour GKE. Pour obtenir des instructions, consultez la section Accéder aux secrets stockés en dehors des clusters GKE à l'aide de la fédération d'identité de charge de travail pour GKE.
Vérifier les images de conteneur avant le déploiement sur votre cluster Utilisez l'autorisation binaire pour vérifier l'intégrité des images de conteneur référencées dans vos fichiers manifestes de pod au moment du déploiement. Pour obtenir des instructions, consultez la section Vérifier les images de conteneurs au moment du déploiement à l'aide de l'autorisation binaire.

Surveiller votre stratégie de sécurité

Après avoir configuré vos clusters et déployé vos charges de travail, vous devez configurer la surveillance et la journalisation afin de pouvoir observer la stratégie de sécurité de votre cluster. Nous vous recommandons d'effectuer les opérations suivantes :

  • Enregistrez vos clusters dans le tableau de bord de stratégie de sécurité GKE pour auditer les charges de travail afin de détecter des problèmes tels que des configurations de sécurité problématiques ou des failles dans les packages de votre système d'exploitation de conteneurs, et obtenir des informations sur les mesures d'atténuation possibles.
  • Recevez des notifications concernant les nouveaux bulletins de sécurité et les événements de mise à niveau à l'aide des notifications de cluster.
  • Observez vos clusters à l'aide du tableau de bord GKE dans Cloud Monitoring ou de l'onglet Observabilité de GKE.
  • Découvrez comment afficher et gérer vos journaux d'audit GKE dans Cloud Logging.

Étapes suivantes