Cette page décrit l'approche adoptée par Google Kubernetes Engine (GKE) pour améliorer la conformité avec les benchmarks du CIS (Center for Internet Security) pour Kubernetes et GKE. Cette page contient les informations suivantes :
Comment nous configurons le plan de contrôle GKE géré pour qu'il soit conforme au benchmark CIS de Kubernetes
Comment configurer vos nœuds et vos charges de travail GKE pour qu'ils soient conformes au benchmark CIS de Google Kubernetes Engine (GKE)
À propos des benchmarks CIS
Le CIS publie les benchmarks suivants, qui contiennent des consignes de configuration sécurisée pour Kubernetes :
Benchmark CIS de Kubernetes : s'applique au projet Kubernetes Open Source.
Il vise à fournir des conseils pour diverses implémentations Kubernetes autogérées et hébergées.
Benchmark CIS GKE : établit des consignes pour la configuration sécurisée des composants que vous pouvez contrôler dans les clusters GKE. Inclut des recommandations spécifiques à GKE sur Google Cloud.
Nous vous recommandons de privilégier le benchmark CIS GKE, car il est spécifique à GKE sur Google Cloud. Le benchmark CIS de Kubernetes contient de nombreuses recommandations de contrôles que vous ne pouvez pas afficher ni modifier dans GKE. Notre approche de la sécurité des clusters inclut des mesures d'atténuation qui dépassent le champ d'application du benchmark Open Source de Kubernetes et peut entraîner des conflits avec ces recommandations.
Autres benchmarks applicables à GKE
En plus du benchmark CIS de GKE et du benchmark CIS de Kubernetes, les benchmarks suivants s'appliquent aux systèmes d'exploitation disponibles dans GKE. Même si un benchmark d'OS spécifique ne traite pas explicitement de l'utilisation de Kubernetes, vous devez tout de même vous y référer pour obtenir des conseils de sécurité supplémentaires.
Le plan de contrôle, y compris les VM du plan de contrôle, le serveur d'API et les composants tels que la base de données d'état du cluster (etcd ou Spanner), kube-controller-manager et kube-scheduler
Le système d'exploitation du nœud
Ces composants existent dans un projet appartenant à GKE. Vous ne pouvez donc pas les modifier ni les évaluer par rapport aux contrôles de benchmark CIS correspondants. Toutefois, vous pouvez évaluer et corriger les contrôles du benchmark CIS qui s'appliquent à vos nœuds de calcul et à vos charges de travail. Selon le modèle de responsabilité partagée de GKE, ces composants relèvent de votre responsabilité.
Notre approche pour sécuriser GKE pour le benchmark CIS
GKE est une implémentation gérée de Kubernetes Open Source. Nous gérons entièrement le plan de contrôle et sommes responsables de la sécurisation de la configuration des composants du plan de contrôle. Le tableau suivant décrit certaines de nos décisions susceptibles d'affecter la notation des benchmarks CIS :
Approche de sécurité GKE
Authentification
Certains composants de surveillance de GKE utilisent l'authentification anonyme pour obtenir des métriques.
Certains composants du plan de contrôle sont amorcés à l'aide de jetons statiques, qui sont ensuite utilisés pour l'authentification sur le serveur d'API. Ces jetons sont générés chaque fois qu'une VM démarre ou redémarre.
Contrôleurs d'admission
GKE désactive les contrôleurs d'admission suivants :
EventRateLimit : il s'agit d'une fonctionnalité alpha de Kubernetes.
AlwaysPullImages : ce contrôleur fournit une protection pour les images de registre privé dans des clusters mutualisés non coopératifs, et pour ce faire, il fait en sorte que les registres d'images soient un point de défaillance unique pour la création de pods dans le cluster.
SecurityContextDeny : le contrôleur d'admission de sécurité des pods est préféré et disponible dans toutes les éditions GKE.
Si vous utilisez GKE Enterprise, vous pouvez également activer l'application des normes de sécurité des pods à l'aide de Policy Controller.
ImagePolicyWebhook : GKE désactive ImagePolicyWebhook par défaut, car il possède ses propres mécanismes de gestion et de sécurité des images. Cela permet à GKE de maintenir un contrôle plus strict sur l'environnement et de s'assurer que ses pratiques de sécurité sont appliquées de manière cohérente.
Toutefois, vous pouvez utiliser l'autorisation binaire ou Policy Controller pour la gestion des règles.
Journaux d'audit
GKE capture les journaux d'audit à l'aide de la stratégie d'audit GKE.
Par conséquent, nous n'avons pas besoin de définir d'indicateurs de journalisation d'audit du serveur d'API Kubernetes.
GKE utilise mTLS pour le trafic entre les composants du plan de contrôle, ainsi qu'entre le plan de contrôle et les nœuds. Pour en savoir plus, consultez Confiance dans les clusters.
etcd
Dans la version Open Source de Kubernetes, la base de données d'état du cluster utilise etcd. Dans GKE, la base de données backend qui stocke l'état du cluster est l'une des technologies suivantes :
etcd : le cluster exécute des instances etcd sur le plan de contrôle.
Spanner : GKE stocke l'état du cluster dans une base de données Spanner distincte des VM du plan de contrôle.
Tous les clusters GKE diffusent l'API etcd dans les VM du plan de contrôle. Toutes les interactions client avec l'API Kubernetes sont identiques à celles de Kubernetes Open Source. En fonction de la technologie de base de données qui sert de backend à l'API etcd de votre cluster, vous pouvez constater des écarts dans les scores liés à etcd du benchmark CIS Kubernetes Open Source.
kubelet
GKE active le port en lecture seule du kubelet non authentifié. Vous pouvez désactiver le port en définissant --no-autoprovisioning-enable-insecure-kubelet-readonly-port.
Le port en lecture seule sera désactivé par défaut dans une prochaine version, après vous avoir laissé le temps de migrer.
Le mode GKE Standard permet à vos charges de travail de modifier les valeurs par défaut du noyau si nécessaire.
GKE limite le nombre d'événements Kubernetes dans le kubelet afin de réduire le risque d'attaques par déni de service.
GKE utilise mTLS pour sécuriser le trafic entre le kubelet et le serveur d'API.
GKE effectue une rotation des certificats de serveur par défaut et des certificats clients lorsque les nœuds GKE protégés sont activés.
Vous pouvez automatiser l'évaluation de vos clusters par rapport aux benchmarks à l'aide de l'une des méthodes suivantes :
Benchmark CIS de GKE :
Toutes les éditions GKE :
Exécutez kube-bench pour évaluer les nœuds de calcul par rapport au benchmark. Pour en savoir plus, consultez le dépôt GitHub kube-bench.
Utilisez un outil tiers tel que Twistlock Defender pour évaluer les nœuds par rapport au benchmark.
Édition GKE Enterprise : utilisez le tableau de bord de conformité pour évaluer la conformité de tous vos clusters avec le benchmark CIS de GKE. Pour en savoir plus, consultez À propos du tableau de bord GKE Compliance.
Benchmark CIS de Kubernetes : exécutez kube-bench pour évaluer les nœuds de calcul par rapport au benchmark. Vous ne pouvez pas évaluer le plan de contrôle géré par rapport à ces recommandations dans le benchmark.
Découvrez comment surveiller les problèmes de sécurité dans vos clusters avec la posture de sécurité GKE.
Découvrez comment évaluer vos clusters pour détecter les problèmes de conformité dans le tableau de bord de conformité GKE pour GKE Enterprise.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/01 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/01 (UTC)."],[],[],null,["# CIS Benchmarks\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page describes the approach that Google Kubernetes Engine (GKE) takes to\nimprove compliance with the Center for Internet Security (CIS) benchmarks for\nKubernetes and for GKE. This page includes the following\ninformation:\n\n- How we configure the managed GKE control plane to conform to the CIS Kubernetes Benchmark\n- How you can configure your GKE nodes and workloads to conform to the CIS Google Kubernetes Engine (GKE) Benchmark\n\nAbout the CIS Benchmarks\n------------------------\n\nCIS releases the following benchmarks that contain secure configuration\nguidelines for Kubernetes:\n\n- **CIS Kubernetes Benchmark**: Applies to the open source Kubernetes project. Intended to provide guidance for a variety of self-managed and hosted Kubernetes implementations.\n- **CIS GKE Benchmark**: Establishes guidelines for the secure configuration of components you can control in GKE clusters. Includes recommendations that are specific to GKE on Google Cloud.\n\nWe recommend that you **prioritize the CIS GKE Benchmark**, because it is\nspecific to GKE on Google Cloud. The CIS Kubernetes\nBenchmark contains many recommendations for controls that you can't view or\nmodify in GKE. Our approach to cluster security includes\nmitigations that go beyond the scope of the open source Kubernetes benchmark and\nmight result in conflicts with those recommendations.\n\n### Other benchmarks that apply to GKE\n\nIn addition to the CIS GKE Benchmark and the CIS Kubernetes Benchmark, the following benchmarks apply to the operating systems that are available in GKE. Even if a specific OS benchmark doesn't explicitly address Kubernetes usage, you should still reference that benchmark for additional security guidance.\n\n- [**Container-Optimized OS Benchmark**](https://www.cisecurity.org/benchmark/google_cloud_computing_platform): the default operating system that's installed on all GKE Linux nodes\n- [**Ubuntu Linux Benchmark**](https://www.cisecurity.org/benchmark/ubuntu_linux): available for GKE Standard\n- [**Windows Server Benchmark**](https://www.cisecurity.org/benchmark/microsoft_windows_server): available for GKE Standard\n\nThe default container runtime, containerd, doesn't have a benchmark.\n\n### Shared responsibility model\n\nBased on the\n[GKE shared responsibility model](/kubernetes-engine/docs/concepts/shared-responsibility),\nwe manage the following components for you:\n\n- The control plane, including the control plane VMs, API server, and components like the cluster state database (etcd or Spanner-based), kube-controller-manager, and kube-scheduler.\n- The node operating system.\n\nThese components exist in a project that GKE owns, so you can't\nmodify or evaluate any of these components against corresponding CIS Benchmark\ncontrols. You can, however, evaluate and remediate any CIS Benchmark controls\nthat apply to your worker nodes and your workloads. Based on the\nGKE shared responsibility model, these components are your\nresponsibility.\n\nOur approach to securing GKE for the CIS Benchmark\n--------------------------------------------------\n\nGKE is a managed implementation of open source Kubernetes. We\nfully manage the control plane and are responsible for securing the\nconfiguration of control plane components. The following table describes some of\nour decisions that might affect scoring of the CIS benchmarks:\n\nEvaluate GKE against the CIS Benchmarks\n---------------------------------------\n\n| **Note:** This section mentions third-party applications like `kube-bench`. The versions of the CIS Benchmarks that these applications evaluate might not be the latest available versions. Ensure that you check which version your chosen application uses for evaluations.\n\nYou can automate evaluation of your clusters against the Benchmarks by using one\nof the following methods:\n\n- CIS GKE Benchmark:\n - Run `kube-bench` to evaluate worker nodes against the Benchmark. For details, see the [kube-bench GitHub repository](https://github.com/aquasecurity/kube-bench).\n - Use a third-party tool like Twistlock Defender to evaluate nodes against the Benchmark.\n- CIS Kubernetes Benchmark: Run `kube-bench` to evaluate worker nodes against the Benchmark. You can't evaluate the managed control plane against those recommendations in the Benchmark.\n\nWhat's next\n-----------\n\n- Read the [GKE security overview](/kubernetes-engine/docs/concepts/security-overview).\n- Follow security best practices in the [GKE hardening guide](/kubernetes-engine/docs/how-to/hardening-your-cluster).\n- Learn about monitoring your clusters for security issues with [GKE security posture](/kubernetes-engine/docs/concepts/about-security-posture-dashboard).\n- Learn how to evaluate your clusters for compliance issues in the [GKE compliance dashboard](/kubernetes-engine/fleet-management/docs/about-compliance-dashboard) for GKE Enterprise."]]
