Ce document explique ce que sont les benchmarks CIS de Kubernetes et Google Kubernetes Engine (GKE), comment auditer votre conformité aux benchmarks et ce que GKE configure lorsque vous ne pouvez pas réaliser un audit ou mettre en œuvre directement une recommandation.
Utiliser les benchmarks CIS
Le Center for Internet Security (CIS) publie des benchmarks sur les bonnes pratiques de sécurité. Le benchmark CIS de Kubernetes est un ensemble de recommandations permettant de configurer Kubernetes pour garantir un niveau de sécurité élevé. Le benchmark est lié à une version spécifique de Kubernetes. Le benchmark CIS de Kubernetes est écrit pour la distribution en Open Source de Kubernetes. Il est destiné à être appliqué de manière aussi universelle que possible entre les différentes distributions.
Avec un service géré tel que GKE, tous les éléments du benchmark ne relèvent pas de votre responsabilité. Il existe des recommandations que vous ne pouvez pas auditer ni corriger vous-même. Si vous travaillez avec GKE, utilisez le benchmark CIS de GKE, un enfant du benchmark CIS de Kubernetes destiné spécifiquement à la distribution GKE. Il s'appuie sur le benchmark CIS existant, mais supprime les éléments qui ne sont pas configurables ou gérés par l'utilisateur et ajoute des contrôles spécifiques à Google Cloud.
Plusieurs ensembles de benchmarks
Avec GKE, vous pouvez utiliser les benchmarks CIS pour GKE, Kubernetes, Docker, Container-Optimized OS et Linux. Pour télécharger les benchmarks à jour pour ces produits, consultez le site Web des benchmarks CIS.
L'environnement d'exécution du conteneur par défaut, containerd, ne dispose pas d'un benchmark CIS.
Les nœuds Windows Server utilisés avec GKE ne sont pas évalués par rapport à un benchmark CIS approprié, car les benchmarks CIS Windows Server n'autorisent pas spécifiquement l'utilisation de Kubernetes, et les benchmarks CIS Kubernetes ne prennent actuellement pas en charge les nœuds Windows.
Certains outils tentent d'analyser les nœuds Kubernetes en fonction de plusieurs benchmarks CIS (par exemple Linux, Docker et Kubernetes) et combinent les résultats. Toutefois, cela entraîne souvent des conseils confus et potentiellement contradictoires, car ces benchmarks n'ont pas été conçus pour être combinés et appliqués dans un environnement Kubernetes.
Modèle de responsabilité partagée
Dans GKE, en vertu du modèle de responsabilité partagée, Google gère les composants Kubernetes suivants :
- Le plan de contrôle, y compris les VM du plan de contrôle, le serveur d'API, les autres composants sur les VM, etc.
- La distribution Kubernetes
- Le système d'exploitation des nœuds
Les configurations associées à ces éléments ne sont généralement pas disponibles pour un audit ou une modification dans GKE.
Vous demeurez tout de même responsable de la mise à niveau des nœuds qui exécutent vos charges de travail, ainsi que des charges de travail elles-mêmes. En général, vous pouvez auditer ces composants et appliquer les recommandations qui les concernent.
Possibilité d'auditer et de corriger
Le Benchmark CIS de GKE s'appuie sur le benchmark CIS de Kubernetes, mais supprime les éléments non configurables ou gérés par l'utilisateur, et ajoute des contrôles spécifiques à Google Cloud.
Les sections du benchmark CIS de GKE sont les suivantes :
- Les composants du plan de contrôle, etcd et la configuration du plan de contrôle (sections 1, 2 et 3) font partie du benchmark CIS de Kubernetes. Il est généralement impossible de les auditer ou de les corriger sur GKE.
- Les nœuds de calcul (section 4) dépendent du benchmark CIS de Kubernetes. Certains de ces éléments peuvent être audités ou corrigés sur GKE, mais les instructions peuvent différer.
- Les règles (section 5) dépendent également du benchmark CIS de Kubernetes. En règle générale, elles sont directement applicables à GKE, sans aucune modification des instructions.
- Les services gérés (section 6) du benchmark CIS de GKE constituent un tout nouveau contenu spécifiquement conçu pour GKE. Cette section contient toutes les recommandations spécifiques aux contrôles de Google Cloud. Ces services peuvent être audités et corrigés sur GKE.
Pour les éléments ne pouvant pas être audités ou corrigés sur GKE, consultez la section Valeurs par défaut pour analyser les performances d'un cluster par défaut créé dans GKE vis-à-vis du benchmark CIS de Kubernetes.
Versions
Notez que les numéros de version peuvent différer selon les benchmarks.
Ce document fait référence aux versions suivantes :
| Version de Kubernetes | Version du benchmark CIS de Kubernetes | Version du benchmark CIS de GKE |
|---|---|---|
| 1.15 | 1.5.0 | 1.0.0 |
Benchmark CIS de Kubernetes
Accéder au benchmark
Le benchmark CIS de Kubernetes est disponible sur le site Web du CIS.
Niveaux de recommandation
Dans le benchmark CIS de Kubernetes :
| Niveau | Description |
|---|---|
| Niveau 1 | Les recommandations visent à : |
| Niveau 2 | Étend le profil du niveau 1. Les recommandations présentent une ou plusieurs des caractéristiques suivantes : |
Évaluation des recommandations
Dans le benchmark CIS de Kubernetes :
| Évaluation | Description |
|---|---|
| Évalué | Le non-respect de ces recommandations entraîne une diminution du score final du benchmark. |
| Non évalué | Le non-respect de ces recommandations n'entraîne pas de diminution du score final du benchmark. |
Évaluation sur GKE
Nous utilisons les valeurs suivantes pour spécifier l'état des recommandations Kubernetes dans GKE :
| État | Description |
|---|---|
| Réussite | Respecte une recommandation du benchmark. |
| Échec | Ne respecte pas une recommandation du benchmark. |
| Contrôle équivalent | Ne respecte pas les conditions exactes de la recommandation du benchmark, mais d'autres mécanismes existent dans GKE pour fournir des contrôles de sécurité équivalents. |
| Dépend de l'environnement | GKE ne configure pas les éléments liés à cette recommandation. La configuration de l'utilisateur détermine si son environnement respecte une recommandation du benchmark. |
État sur GKE
Lorsque vous créez un cluster GKE avec la version spécifiée, voici les performances auxquelles vous pouvez vous attendre vis-à-vis du benchmark CIS de Kubernetes.
État du cluster GKE par défaut :
| # | Recommandation | Évalué/Non évalué | Niveau | État par défaut |
|---|---|---|---|---|
| 1 | Composants du plan de contrôle | |||
| 1.1 | Fichiers de configuration de nœud du plan de contrôle | |||
| 1.1.1 | Assurez-vous que les autorisations du fichier de spécification du pod du serveur d'API sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 1.1.2 | Assurez-vous que la propriété du fichier de spécification du pod du serveur d'API est définie sur root:root |
Évalué | L1 | Réussite |
| 1.1.3 | Assurez-vous que les autorisations du fichier de spécification du pod du gestionnaire de contrôleurs sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 1.1.4 | Assurez-vous que la propriété du fichier de spécification du pod du gestionnaire de contrôleurs est définie sur root:root |
Évalué | L1 | Réussite |
| 1.1.5 | Assurez-vous que les autorisations du fichier de spécification du pod du programmeur sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 1.1.6 | Assurez-vous que la propriété du fichier de spécification du pod du programmeur est définie sur root:root |
Évalué | L1 | Réussite |
| 1.1.7 | Assurez-vous que les autorisations du fichier de spécification du pod d'etcd sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 1.1.8 | Assurez-vous que la propriété du fichier de spécification du pod d'etcd est définie sur root:root |
Évalué | L1 | Réussite |
| 1.1.9 | Assurez-vous que les autorisations du fichier de la Container Network Interface sont définies sur 644 ou sur une option plus restrictive |
Non évalué | L1 | Réussite |
| 1.1.10 | Assurez-vous que la propriété du fichier de la Container Network Interface est définie sur root:root |
Non évalué | L1 | Réussite |
| 1.1.11 | Assurez-vous que les autorisations du répertoire de données d'etcd sont définies sur 700 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 1.1.12 | Assurez-vous que la propriété du répertoire de données d'etcd est définie sur etcd:etcd |
Évalué | L1 | Réussite |
| 1.1.13 | Assurez-vous que les autorisations du fichier admin.conf sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 1.1.14 | Assurez-vous que la propriété du fichier admin.conf est définie sur root:root |
Évalué | L1 | Réussite |
| 1.1.15 | Assurez-vous que les autorisations du fichier scheduler.conf sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 1.1.16 | Assurez-vous que la propriété du fichier scheduler.conf est définie sur root:root |
Évalué | L1 | Réussite |
| 1.1.17 | Assurez-vous que les autorisations du fichier controller-manager.conf sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 1.1.18 | Assurez-vous que la propriété du fichier controller-manager.conf est définie sur root:root |
Évalué | L1 | Réussite |
| 1.1.19 | Assurez-vous que la propriété du fichier et du répertoire PKI de Kubernetes est définie sur root:root |
Évalué | L1 | Réussite |
| 1.1.20 | Assurez-vous que les autorisations du fichier de certificat PKI de Kubernetes sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 1.1.21 | Assurez-vous que les autorisation du fichier de clé PKI de Kubernetes sont définies sur 600 |
Évalué | L1 | Réussite |
| 1.2 | Serveur d'API | |||
| 1.2.1 | Assurez-vous que l'argument --anonym-auth est défini sur "false" | Non évalué | L1 | Échec |
| 1.2.2 | Assurez-vous que l'argument --basic-auth-file n'est pas défini | Évalué | L1 | Réussite |
| 1.2.3 | Assurez-vous que le paramètre --token-auth-file n'est pas défini | Évalué | L1 | Échec |
| 1.2.4 | Assurez-vous que l'argument --kubelet-https est défini sur "true" | Évalué | L1 | Réussite |
| 1.2.5 | Assurez-vous que les arguments --kubelet-client-certificate et --kubelet-client-key sont définis de manière appropriée | Évalué | L1 | Réussite |
| 1.2.6 | Assurez-vous que l'argument --kubelet-certificate-authority est défini de manière appropriée | Évalué | L1 | Réussite |
| 1.2.7 | Assurez-vous que l'argument --authorization-mode n'est pas défini sur "AlwaysAllow" | Évalué | L1 | Réussite |
| 1.2.8 | Assurez-vous que l'argument --authorization-mode inclut "Node" | Évalué | L1 | Réussite |
| 1.2.9 | Assurez-vous que l'argument --authorization-mode inclut "RBAC" | Évalué | L1 | Réussite |
| 1.2.10 | Assurez-vous que le plug-in de contrôle d'admission EventRateLimit est défini | Non évalué | L1 | Échec |
| 1.2.11 | Assurez-vous que le plug-in de contrôle d'admission AlwaysAdmit n'est pas défini | Évalué | L1 | Réussite |
| 1.2.12 | Assurez-vous que le plug-in de contrôle d'admission AlwaysPullImages est défini | Non évalué | L1 | Échec |
| 1.2.13 | Vérifiez que le plug-in de contrôle d'admission SecurityContextDeny est défini si PodSecurityPolicy n'est pas utilisé | Non évalué | L1 | Échec |
| 1.2.14 | Assurez-vous que le plug-in de contrôle d'admission ServiceAccount est défini | Évalué | L1 | Réussite |
| 1.2.15 | Assurez-vous que le plug-in de contrôle d'admission NamespaceLifecycle est défini | Évalué | L1 | Réussite |
| 1.2.16 | Assurez-vous que le plug-in de contrôle d'admission PodSecurityPolicy est défini | Évalué | L1 | Échec |
| 1.2.17 | Assurez-vous que le plug-in de contrôle d'admission NodeRestriction est défini | Évalué | L1 | Réussite |
| 1.2.18 | Assurez-vous que l'argument --insecure-bind-address n'est pas défini | Évalué | L1 | Réussite |
| 1.2.19 | Assurez-vous que l'argument --insecure-port est défini sur 0 | Évalué | L1 | Réussite |
| 1.2.20 | Assurez-vous que l'argument --secure-port n'est pas défini sur 0 | Évalué | L1 | Réussite |
| 1.2.21 | Assurez-vous que l'argument --profiling est défini sur "false" | Évalué | L1 | Échec |
| 1.2.22 | Assurez-vous que l'argument --audit-log-path est défini | Évalué | L1 | Contrôle équivalent |
| 1.2.23 | Assurez-vous que l'argument --audit-log-maxage est défini sur 30 ou sur la valeur appropriée | Évalué | L1 | Contrôle équivalent |
| 1.2.24 | Assurez-vous que l'argument --audit-log-maxbackup est défini sur 10 ou sur la valeur appropriée | Évalué | L1 | Contrôle équivalent |
| 1.2.25 | Assurez-vous que l'argument --audit-log-maxsize est défini sur 100 ou sur la valeur appropriée | Évalué | L1 | Contrôle équivalent |
| 1.2.26 | Assurez-vous que l'argument --request-timeout est défini de la manière appropriée | Évalué | L1 | Réussite |
| 1.2.27 | Assurez-vous que l'argument --service-account-lookup est défini sur "true" | Évalué | L1 | Réussite |
| 1.2.28 | Assurez-vous que l'argument --service-account-key-file est défini de la manière appropriée | Évalué | L1 | Réussite |
| 1.2.29 | Assurez-vous que les arguments --etcd-certfile et --etcd-keyfile sont définis de la manière appropriée | Évalué | L1 | Échec |
| 1.2.30 | Assurez-vous que les arguments --tls-cert-file et --tls-private-key-file sont définis de la manière appropriée | Évalué | L1 | Réussite |
| 1.2.31 | Assurez-vous que l'argument --client-ca-file est défini de la manière appropriée | Évalué | L1 | Réussite |
| 1.2.32 | Assurez-vous que l'argument --etcd-cafile est défini de la manière appropriée | Évalué | L1 | Échec |
| 1.2.33 | Assurez-vous que l'argument --encryption-provider-config est défini de la manière appropriée | Évalué | L1 | Réussite |
| 1.2.34 | Assurez-vous que les fournisseurs de services de chiffrement sont configurés de la manière appropriée | Évalué | L1 | Échec |
| 1.2.35 | Assurez-vous que le serveur d'API utilise uniquement des algorithmes de chiffrement sécurisés | Non évalué | L1 | Réussite |
| 1.3 | Gestionnaire de contrôleurs | |||
| 1.3.1 | Assurez-vous que l'argument --terminated-pod-gc-threshold est défini de la manière appropriée | Évalué | L1 | Réussite |
| 1.3.2 | Assurez-vous que l'argument --profiling est défini sur "false" | Évalué | L1 | Échec |
| 1.3.3 | Assurez-vous que l'argument --use-service-account-credentials est défini sur "true" | Évalué | L1 | Échec |
| 1.3.4 | Assurez-vous que l'argument --service-account-private-key-file est défini de la manière appropriée | Évalué | L1 | Réussite |
| 1.3.5 | Assurez-vous que l'argument --root-ca-file est défini de la manière appropriée | Évalué | L1 | Réussite |
| 1.3.6 | Assurez-vous que l'argument RotateKubeletServerCertificate est défini sur "true" | Évalué | L2 | Contrôle équivalent |
| 1.3.7 | Assurez-vous que l'argument --bind-address est défini sur 127.0.0.1 | Évalué | L1 | Réussite |
| 1.4 | Scheduler | |||
| 1.4.1 | Assurez-vous que l'argument --profiling est défini sur "false" | Évalué | L1 | Échec |
| 1.4.2 | Assurez-vous que l'argument --bind-address est défini sur 127.0.0.1 | Évalué | L1 | Réussite |
| 2 | etcd | |||
| 2.1 | Assurez-vous que les arguments --cert-file et --key-file sont définis de la manière appropriée | Évalué | L1 | Échec |
| 2.2 | Assurez-vous que l'argument --client-cert-auth est défini sur "true" | Évalué | L1 | Échec |
| 2.3 | Assurez-vous que l'argument --auto-tls n'est pas défini sur "true" | Évalué | L1 | Réussite |
| 2.4 | Assurez-vous que les arguments --peer-cert-file et --peer-key-file sont définis de la manière appropriée | Évalué | L1 | Contrôle équivalent |
| 2.5 | Assurez-vous que l'argument --peer-client-cert-auth est défini sur "true" | Évalué | L1 | Contrôle équivalent |
| 2.6 | Assurez-vous que l'argument --peer-auto-tls n'est pas défini sur "true" | Évalué | L1 | Contrôle équivalent |
| 2.7 | Assurez-vous qu'une autorité de certification unique est utilisée pour etcd | Non évalué | L2 | Réussite |
| 3 | Configuration du plan de contrôle | |||
| 3.1 | Authentification et autorisation | |||
| 3.1.1 | L'authentification par certificat client ne doit pas être utilisée pour les utilisateurs | Non évalué | L2 | Réussite |
| 3.2 | Logging | |||
| 3.2.1 | Assurez-vous qu'une stratégie d'audit minimale est créée | Évalué | L1 | Réussite |
| 3.2.2 | Assurez-vous que la stratégie d'audit couvre les principaux problèmes de sécurité | Non évalué | L2 | Réussite |
| 4 | Nœuds de calcul | |||
| 4.1 | Fichiers de configuration du nœud de calcul | |||
| 4.1.1 | Assurez-vous que les autorisations du fichier du service kubelet sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 4.1.2 | Assurez-vous que la propriété du fichier du service kubelet est définie sur root:root |
Évalué | L1 | Réussite |
| 4.1.3 | Assurez-vous que les autorisations du fichier kubeconfig du proxy sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 4.1.4 | Assurez-vous que la propriété du fichier kubeconfig du proxy est définie sur root:root |
Évalué | L1 | Réussite |
| 4.1.5 | Assurez-vous que les autorisations du fichier kubelet.conf sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 4.1.6 | Assurez-vous que la propriété du fichier kubelet.conf est définie sur root:root |
Évalué | L1 | Réussite |
| 4.1.7 | Assurez-vous que les autorisations du fichier des autorités de certification sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 4.1.8 | Assurez-vous que la propriété du fichier des autorités de certification du client est définie sur root:root |
Évalué | L1 | Réussite |
| 4.1.9 | Assurez-vous que les autorisations du fichier de configuration du service kubelet sont définies sur 644 ou sur une option plus restrictive |
Évalué | L1 | Réussite |
| 4.1.10 | Assurez-vous que la propriété du fichier de configuration de kubelet est définie sur root:root |
Évalué | L1 | Réussite |
| 4.2 | Kubelet | |||
| 4.2.1 | Assurez-vous que l'argument --anonym-auth est défini sur "false" | Évalué | L1 | Réussite |
| 4.2.2 | Assurez-vous que l'argument --authorization-mode n'est pas défini sur "AlwaysAllow" | Évalué | L1 | Réussite |
| 4.2.3 | Assurez-vous que l'argument --client-ca-file est défini de la manière appropriée | Évalué | L1 | Réussite |
| 4.2.4 | Assurez-vous que l'argument --read-only-port est défini sur 0 | Évalué | L1 | Échec |
| 4.2.5 | Assurez-vous que l'argument --streaming-connection-idle-timeout n'est pas défini sur 0 | Évalué | L1 | Réussite |
| 4.2.6 | Assurez-vous que l'argument --protect-kernel-defaults est défini sur "true" | Évalué | L1 | Échec |
| 4.2.7 | Assurez-vous que l'argument --make-iptables-util-chains est défini sur "true" | Évalué | L1 | Réussite |
| 4.2.8 | Assurez-vous que l'argument --hostname-override n'est pas défini | Non évalué | L1 | Réussite |
| 4.2.9 | Assurez-vous que l'argument --event-qps est défini sur 0 ou sur un niveau garantissant une capture d'événement appropriée | Non évalué | L2 | Échec |
| 4.2.10 | Assurez-vous que les arguments --tls-cert-file et --tls-private-key-file sont définis de la manière appropriée | Évalué | L1 | Contrôle équivalent |
| 4.2.11 | Assurez-vous que l'argument --rotate-certificates n'est pas défini sur "false" | Évalué | L1 | Contrôle équivalent |
| 4.2.12 | Assurez-vous que l'argument RotateKubeletServerCertificate est défini sur "true" | Évalué | L1 | Contrôle équivalent |
| 4.2.13 | Assurez-vous que le kubelet n'utilise que des algorithmes de chiffrement sécurisés | Non évalué | L1 | Échec |
| 5 | Règles | |||
| 5.1 | RBAC et comptes de service | |||
| 5.1.1 | Assurez-vous que le rôle d'administrateur de cluster n'est utilisé que lorsque cela est nécessaire | Non évalué | L1 | Dépend de l'environnement |
| 5.1.2 | Limitez l'accès aux secrets | Non évalué | L1 | Dépend de l'environnement |
| 5.1.3 | Réduisez l'utilisation des caractères génériques dans les objets Roles et ClusterRoles | Non évalué | L1 | Dépend de l'environnement |
| 5.1.4 | Limitez les accès permettant de créer des pods | Non évalué | L1 | Dépend de l'environnement |
| 5.1.5 | Assurez-vous que les comptes de service par défaut ne sont pas utilisés de manière active | Évalué | L1 | Dépend de l'environnement |
| 5.1.6 | Assurez-vous que les jetons de compte de service ne sont installés que si nécessaire | Non évalué | L1 | Dépend de l'environnement |
| 5.2 | Règles de sécurité relatives aux pods | |||
| 5.2.1 | Limitez l'admission de conteneurs privilégiés | Non évalué | L1 | Dépend de l'environnement |
| 5.2.2 | Limitez l'admission des conteneurs souhaitant partager l'espace de noms de l'ID de processus hôte | Évalué | L1 | Dépend de l'environnement |
| 5.2.3 | Limitez l'admission des conteneurs souhaitant partager l'espace de noms de l'IPC hôte | Évalué | L1 | Dépend de l'environnement |
| 5.2.4 | Limitez l'admission des conteneurs souhaitant partager l'espace de noms du réseau hôte | Évalué | L1 | Dépend de l'environnement |
| 5.2.5 | Limitez l'admission des conteneurs avec allowPrivilegeEscalation | Évalué | L1 | Dépend de l'environnement |
| 5.2.6 | Limitez l'admission des conteneurs racine | Non évalué | L2 | Dépend de l'environnement |
| 5.2.7 | Limitez l'admission des conteneurs avec la fonctionnalité NET_RAW | Non évalué | L1 | Dépend de l'environnement |
| 5.2.8 | Limitez l'admission des conteneurs avec des fonctionnalités supplémentaires | Non évalué | L1 | Dépend de l'environnement |
| 5.2.9 | Limitez l'admission des conteneurs avec des fonctionnalités attribuées | Non évalué | L2 | Dépend de l'environnement |
| 5.3 | Règles de réseau et CNI | |||
| 5.3.1 | Assurez-vous que l'interface CNI utilisée est compatible avec les règles de réseau | Non évalué | L1 | Réussite |
| 5.3.2 | Assurez-vous que des règles de réseau sont définies pour tous les espaces de noms | Évalué | L2 | Dépend de l'environnement |
| 5.4 | Gestion des secrets | |||
| 5.4.1 | Préférez l'utilisation de secrets sous forme de fichiers plutôt que sous forme de variables d'environnement | Non évalué | L1 | Dépend de l'environnement |
| 5.4.2 | Envisagez le stockage externe des secrets | Non évalué | L2 | Dépend de l'environnement |
| 5.5 | Contrôle d'admission extensible | |||
| 5.5.1 | Configurez la provenance de l'image à l'aide du contrôleur d'admission ImagePolicyWebhook | Non évalué | L2 | Dépend de l'environnement |
| 5.6 | Règles générales | |||
| 5.6.1 | Créez des limites administratives entre les ressources à l'aide d'espaces de noms | Non évalué | L1 | Dépend de l'environnement |
| 5.6.2 | Assurez-vous que le profil seccomp est défini sur "docker/default" dans vos définitions de pods | Non évalué | L2 | Dépend de l'environnement |
| 5.6.3 | Appliquez le contexte de sécurité à vos pods et conteneurs | Non évalué | L2 | Dépend de l'environnement |
| 5.6.4 | L'espace de noms par défaut ne doit pas être utilisé | Évalué | L2 | Dépend de l'environnement |
Valeurs par défaut sur GKE
Lorsque les valeurs par défaut d'un nouveau cluster GKE ne respectent pas une recommandation du benchmark CIS de Kubernetes, les valeurs par défaut suivantes, accompagnées ici d'une brève explication, sont utilisées dans GKE. Il est possible d'appliquer certaines de ces recommandations en suivant les procédures définies dans le benchmark CIS de GKE. Les éléments qui peuvent être audités automatiquement sont marqués comme "Évalués" dans le benchmark CIS de GKE.
Valeurs par défaut lorsque des recommandations échouent ou dépendent de l'environnement dans un cluster GKE par défaut :
| # | Recommandation | Évalué/Non évalué dans le benchmark CIS de Kubernetes |
Niveau | État par défaut | Valeur par défaut | Justification | Évalué/Non évalué dans le benchmark CIS de GKE |
|---|---|---|---|---|---|---|---|
| 1 | Composants du plan de contrôle | ||||||
| 1.2 | Serveur d'API | ||||||
| 1.2.1 | Assurez-vous que l'argument --anonym-auth est défini sur "false" | Non évalué | L1 | Échec | true |
Certains composants de surveillance de GKE utilisent l'authentification anonyme pour obtenir des métriques. Bien que GKE autorise l'authentification anonyme pour le kubelet, l'exposition est identique à celle du port en lecture seule, car GKE désactive les gestionnaires de débogage supplémentaires. | Non évalué |
| 1.2.3 | Assurez-vous que le paramètre --token-auth-file n'est pas défini | Évalué | L1 | Échec | Définir | 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. | Non évalué |
| 1.2.10 | Assurez-vous que le plug-in de contrôle d'admission EventRateLimit est défini | Non évalué | L1 | Échec | Non défini | GKE n'est pas compatible avec le contrôleur d'admission Event Rate Limit, car il s'agit d'une fonctionnalité alpha de Kubernetes. | Non évalué |
| 1.2.12 | Assurez-vous que le plug-in de contrôle d'admission AlwaysPullImages est défini | Non évalué | L1 | Échec | Non défini | Le contrôleur d'admission AlwaysPullImages 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 de conteneurs soient un point de défaillance unique pour la création des pods sur l'ensemble du cluster. GKE n'active pas le contrôleur d'admission AlwaysPullImages, ce sont donc les administrateurs du cluster qui décident de la mise en œuvre de la règle d'admission. | Non évalué |
| 1.2.13 | Vérifiez que le plug-in de contrôle d'admission SecurityContextDeny est défini si PodSecurityPolicy n'est pas utilisé | Non évalué | L1 | Échec | Non défini | GKE n'active pas le contrôleur d'admission Security Context par défaut. L'utilisation d'une règle de sécurité de pod est préférable, car elle offre un contrôle plus précis. | Non évalué |
| 1.2.16 | Assurez-vous que le plug-in de contrôle d'admission PodSecurityPolicy est défini | Évalué | L1 | Échec | Non défini | GKE n'active pas le contrôleur d'admission Pod Security Policy (règles de sécurité des pods) par défaut, car une règle doit être définie. Les clients GKE peuvent activer PodSecurityPolicy. | Non évalué, voir également 6.10.3 |
| 1.2.21 | Assurez-vous que l'argument --profiling est défini sur "false" | Évalué | L1 | Échec | Non défini | GKE utilise le profilage pour le débogage. | Non évalué |
| 1.2.22 | Assurez-vous que l'argument --audit-log-path est défini | Évalué | L1 | Contrôle équivalent | Non défini | GKE génère des journaux d'audit, mais n'utilise pas ces options pour les audits. Pour en savoir plus, consultez la page Stratégie d'audit de GKE. | Non évalué |
| 1.2.23 | Assurez-vous que l'argument --audit-log-maxage est défini sur 30 ou sur la valeur appropriée | Évalué | L1 | Contrôle équivalent | Non défini | GKE génère des journaux d'audit, mais n'utilise pas ces options pour les audits. Pour en savoir plus, consultez la page Stratégie d'audit de GKE. | Non évalué |
| 1.2.24 | Assurez-vous que l'argument --audit-log-maxbackup est défini sur 10 ou sur la valeur appropriée | Évalué | L1 | Contrôle équivalent | Non défini | GKE génère des journaux d'audit, mais n'utilise pas ces options pour les audits. Pour en savoir plus, consultez la page Stratégie d'audit de GKE. | Non évalué |
| 1.2.25 | Assurez-vous que l'argument --audit-log-maxsize est défini sur 100 ou sur la valeur appropriée | Évalué | L1 | Contrôle équivalent | Non défini | GKE génère des journaux d'audit, mais n'utilise pas ces options pour les audits. Pour en savoir plus, consultez la page Stratégie d'audit de GKE. | Non évalué |
| 1.2.29 | Assurez-vous que les arguments --etcd-certfile et --etcd-keyfile sont définis de la manière appropriée | Évalué | L1 | Échec | Non défini | Actuellement, GKE n'utilise pas mTLS pour protéger les connexions entre le serveur d'API et etcd. Notez que etcd écoute sur localhost. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Non évalué |
| 1.2.32 | Assurez-vous que l'argument --etcd-cafile est défini de la manière appropriée | Évalué | L1 | Échec | Non défini | Actuellement, GKE n'utilise pas mTLS pour protéger les connexions entre le serveur d'API et etcd. Notez que etcd écoute sur localhost. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Non évalué |
| 1.2.34 | Assurez-vous que les fournisseurs de services de chiffrement sont configurés de la manière appropriée | Évalué | L1 | Échec | identity |
GKE chiffre les contenus clients au repos par défaut. Pour chiffrer davantage les secrets, utilisez le chiffrement des secrets au niveau de la couche application. | Non évalué, voir également 6.3.1 |
| 1.3 | Gestionnaire de contrôleurs | ||||||
| 1.3.2 | Assurez-vous que l'argument --profiling est défini sur "false" | Évalué | L1 | Échec | true |
GKE utilise le profilage pour le débogage. | Non évalué |
| 1.3.6 | Assurez-vous que l'argument RotateKubeletServerCertificate est défini sur "true" | Évalué | L2 | Contrôle équivalent | false |
GKE assure la rotation des certificats kubelet, mais n'utilise pas cette option. | Non évalué |
| 1.4 | Scheduler | ||||||
| 1.4.1 | Assurez-vous que l'argument --profiling est défini sur "false" | Évalué | L1 | Échec | true |
GKE utilise le profilage pour le débogage. | Non évalué |
| 2 | etcd | ||||||
| 2.1 | Assurez-vous que les arguments --cert-file et --key-file sont définis de la manière appropriée | Évalué | L1 | Échec | Non défini | Actuellement, GKE n'utilise pas mTLS pour protéger les connexions entre le serveur d'API et etcd. Notez que etcd écoute sur localhost. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Non évalué |
| 2.2 | Assurez-vous que l'argument --client-cert-auth est défini sur "true" | Évalué | L1 | Échec | Non défini | Actuellement, GKE n'utilise pas mTLS pour protéger les connexions entre le serveur d'API et etcd. Notez que etcd écoute sur localhost. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Non évalué |
| 2.4 | Assurez-vous que les arguments --peer-cert-file et --peer-key-file sont définis de la manière appropriée | Évalué | L1 | Contrôle équivalent | Non défini | GKE utilise mTLS pour le trafic de pairs entre les instances d'etcd. Ces options sont utilisées pour les clusters régionaux, mais pas pour les clusters zonaux, car il n'existe qu'une seule instance d'etcd dans un cluster zonal. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Non évalué |
| 2.5 | Assurez-vous que l'argument --peer-client-cert-auth est défini sur "true" | Évalué | L1 | Contrôle équivalent | Non défini | GKE utilise mTLS pour le trafic de pairs entre les instances d'etcd. Ces options sont utilisées pour les clusters régionaux, mais pas pour les clusters zonaux, car il n'existe qu'une seule instance d'etcd dans un cluster zonal. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Non évalué |
| 2.6 | Assurez-vous que l'argument --peer-auto-tls n'est pas défini sur "true" | Évalué | L1 | Contrôle équivalent | Non défini | GKE utilise mTLS pour le trafic de pairs entre les instances d'etcd. Ces options sont utilisées pour les clusters régionaux, mais pas pour les clusters zonaux, car il n'existe qu'une seule instance d'etcd dans un cluster zonal. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Non évalué |
| 4 | Nœuds de calcul | ||||||
| 4.2 | Kubelet | ||||||
| 4.2.4 | Assurez-vous que l'argument --read-only-port est défini sur 0 | Évalué | L1 | Échec | 10255 |
Certains composants de surveillance de GKE utilisent le port en lecture seule du kubelet pour obtenir des métriques. | Évalué |
| 4.2.6 | Assurez-vous que l'argument --protect-kernel-defaults est défini sur "true" | Évalué | L1 | Échec | false |
GKE ne protège pas les valeurs par défaut du noyau de Kubernetes, car les charges de travail clientes sont susceptibles de les modifier. | Évalué |
| 4.2.9 | Assurez-vous que l'argument --event-qps est défini sur 0 ou sur un niveau garantissant une capture d'événement appropriée | Non évalué | L2 | Échec | 5 |
Les événements sont des objets Kubernetes stockés dans etcd. Pour éviter de surcharger etcd, ils ne sont conservés qu'une heure et ne constituent pas un mécanisme d'audit de sécurité approprié. Le fait d'autoriser des événements illimités, comme suggéré dans ce contrôle, expose le cluster à un risque de DoS inutile et va à l'encontre de la recommandation d'utiliser le contrôleur d'admission EventRateLimits. Les événements de sécurité nécessitant un stockage permanent doivent être envoyés dans des journaux. | Évalué |
| 4.2.10 | Assurez-vous que les arguments --tls-cert-file et --tls-private-key-file sont définis de la manière appropriée | Évalué | L1 | Contrôle équivalent | Non défini | GKE utilise mTLS pour le trafic entre le kubelet et le serveur d'API. GKE utilise TLS pour le trafic du serveur d'API vers le kubelet, qui est authentifié pour les clusters GKE v1.12+. GKE n'utilise pas ces options, mais cela est spécifié dans le fichier de configuration du kubelet. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Évalué |
| 4.2.11 | Assurez-vous que l'argument --rotate-certificates n'est pas défini sur "false" | Évalué | L1 | Contrôle équivalent | Non défini | GKE effectue une rotation des certificats de serveur pour les clusters GKE v1.12+. GKE n'utilise pas ces options, mais cela est spécifié dans le fichier de configuration du kubelet. GKE n'effectue pas de rotation des certificats clients, sauf si les nœuds GKE protégés sont activés. Dans ce cas, GKE n'utilise pas ces options, mais exécute un processus distinct pour la rotation des certificats. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Évalué |
| 4.2.12 | Assurez-vous que l'argument RotateKubeletServerCertificate est défini sur "true" | Évalué | L1 | Contrôle équivalent | Non défini | GKE effectue une rotation des certificats de serveur pour les clusters GKE v1.12+. GKE n'utilise pas ces options, mais cela est spécifié dans le fichier de configuration du kubelet. Pour plus d'informations, reportez-vous à la page Approbation de cluster. | Notés |
| 4.2.13 | Assurez-vous que le kubelet n'utilise que des algorithmes de chiffrement sécurisés | Non évalué | Échec | Non définie | GKE utilise l'ensemble de chiffrement autorisé par défaut golang, qui est considéré comme sécurisé pour les experts en cryptographie golang. Il s'agit également de l'ensemble de données par défaut pour Kubernetes. | Non évalué | |
| 5 | Règles | ||||||
| 5.1 | RBAC et comptes de service | ||||||
| 5.1.1 | Assurez-vous que le rôle d'administrateur de cluster n'est utilisé que lorsque cela est nécessaire | Non évalué | L1 | Dépend de l'environnement | n/a | Non évalué | |
| 5.1.2 | Limitez l'accès aux secrets | Non évalué | L1 | Dépend de l'environnement | n/a | Non évalué | |
| 5.1.3 | Réduisez l'utilisation des caractères génériques dans les objets Roles et ClusterRoles | Non évalué | L1 | Dépend de l'environnement | n/a | Non évalué | |
| 5.1.4 | Limitez les accès permettant de créer des pods | Non évalué | L1 | Dépend de l'environnement | n/a | Non évalué | |
| 5.1.5 | Assurez-vous que les comptes de service par défaut ne sont pas utilisés de manière active | Évalué | L1 | Dépend de l'environnement | n/a | Évalué | |
| 5.1.6 | Assurez-vous que les jetons de compte de service ne sont installés que si nécessaire | Non évalué | L1 | Dépend de l'environnement | n/a | Non évalué | |
| 5.2 | Règles de sécurité relatives aux pods | ||||||
| 5.2.1 | Limitez l'admission de conteneurs privilégiés | Non évalué | L1 | Dépend de l'environnement | n/a | Aucune règle de sécurité du pod n'est définie par défaut. | Évalué |
| 5.2.2 | Limitez l'admission des conteneurs souhaitant partager l'espace de noms de l'ID de processus hôte | Évalué | L1 | Dépend de l'environnement | n/a | Aucune règle de sécurité du pod n'est définie par défaut. | Évalué |
| 5.2.3 | Limitez l'admission des conteneurs souhaitant partager l'espace de noms de l'IPC hôte | Évalué | L1 | Dépend de l'environnement | n/a | Aucune règle de sécurité du pod n'est définie par défaut. | Évalué |
| 5.2.4 | Limitez l'admission des conteneurs souhaitant partager l'espace de noms du réseau hôte | Évalué | L1 | Dépend de l'environnement | n/a | Aucune règle de sécurité du pod n'est définie par défaut. | Évalué |
| 5.2.5 | Limitez l'admission des conteneurs avec allowPrivilegeEscalation | Évalué | L1 | Dépend de l'environnement | n/a | Aucune règle de sécurité du pod n'est définie par défaut. | Évalué |
| 5.2.6 | Limitez l'admission des conteneurs racine | Non évalué | L2 | Dépend de l'environnement | n/a | Aucune règle de sécurité du pod n'est définie par défaut. | Évalué |
| 5.2.7 | Limitez l'admission des conteneurs avec la fonctionnalité NET_RAW | Non évalué | L1 | Dépend de l'environnement | n/a | Aucune règle de sécurité du pod n'est définie par défaut. | Évalué |
| 5.2.8 | Limitez l'admission des conteneurs avec des fonctionnalités supplémentaires | Non évalué | L1 | Dépend de l'environnement | n/a | Aucune règle de sécurité du pod n'est définie par défaut. | Évalué |
| 5.2.9 | Limitez l'admission des conteneurs avec des fonctionnalités attribuées | Non évalué | L2 | Dépend de l'environnement | n/a | Aucune règle de sécurité du pod n'est définie par défaut. | Évalué |
| 5.3 | Règles de réseau et CNI | ||||||
| 5.3.2 | Assurez-vous que des règles de réseau sont définies pour tous les espaces de noms | Évalué | L2 | Dépend de l'environnement | n/a | Évalué | |
| 5.4 | Gestion des secrets | ||||||
| 5.4.1 | Préférez l'utilisation de secrets sous forme de fichiers plutôt que sous forme de variables d'environnement | Non évalué | L1 | Dépend de l'environnement | n/a | Non évalué | |
| 5.4.2 | Envisagez le stockage externe des secrets | Non évalué | L2 | Dépend de l'environnement | n/a | Non évalué | |
| 5.5 | Contrôle d'admission extensible | ||||||
| 5.5.1 | Configurez la provenance de l'image à l'aide du contrôleur d'admission ImagePolicyWebhook | Non évalué | L2 | Dépend de l'environnement | Désactivé | GKE n'active pas le contrôleur d'admission Webhook Image Policy par défaut. La fonctionnalité Image Provenance utilisant l'autorisation binaire n'est pas définie par défaut, car une règle doit être définie. | Non évalué, voir également 6.10.5 |
| 5.6 | Règles générales | ||||||
| 5.6.1 | Créez des limites administratives entre les ressources à l'aide d'espaces de noms | Non évalué | L1 | Dépend de l'environnement | n/a | Non évalué | |
| 5.6.2 | Assurez-vous que le profil seccomp est défini sur "docker/default" dans vos définitions de pods | Non évalué | L2 | Dépend de l'environnement | n/a | Aucun profil seccomp n'est défini par défaut. | Non évalué |
| 5.6.3 | Appliquez le contexte de sécurité à vos pods et conteneurs | Non évalué | L2 | Dépend de l'environnement | n/a | Aucun contexte de sécurité n'est défini par défaut. | Non évalué |
| 5.6.4 | L'espace de noms par défaut ne doit pas être utilisé | Évalué | L2 | Dépend de l'environnement | n/a | Évalué |
Benchmark CIS de GKE
Accéder au benchmark
Le benchmark CIS de GKE est disponible sur le site Web du CIS :
- Accédez à la liste complète des benchmarks CIS.
- Sous l'en-tête Kubernetes, cliquez sur Développer pour afficher le contenu associé.
- Le benchmark CIS de GKE est répertorié et disponible pour le téléchargement.
Niveaux de recommandation
Dans le benchmark CIS de GKE :
| Niveau | Description |
|---|---|
| Niveau 1 | Les recommandations sont destinées à être largement appliquées. Elles doivent être appliquées à presque tous les environnements. |
| Niveau 2 | Les recommandations génèrent un environnement de sécurité plus strict, mais ne s'appliquent pas nécessairement à tous les cas. Elles peuvent avoir un impact sur les performances ou ne pas pouvoir être appliquées de concert avec d'autres recommandations. Elles doivent être évaluées pour votre environnement avant d'être appliquées. Dans certains cas, par exemple pour les charges de travail mutualisées, ces recommandations peuvent être plus pertinentes. |
Évaluation des recommandations
Dans le benchmark CIS de GKE :
| Évaluation | Description |
|---|---|
| Évalué |
Les recommandations peuvent être testées facilement à l'aide d'une méthode automatisée et leur valeur peut être évaluée de manière définitive. Ces recommandations ne concernent que les produits ou fonctionnalités disponibles pour tous les utilisateurs. |
| Non évalué |
Les recommandations ne peuvent pas être facilement évaluées à l'aide de méthodes automatisées ou nécessitent une évaluation pour déterminer l'implémentation exacte adaptée à votre charge de travail. Ces recommandations peuvent concerner des produits ou des fonctionnalités en version bêta. Par exemple, la règle de sécurité du pod nécessite l'utilisation d'une règle spécifique à votre charge de travail et il s'agit d'une fonctionnalité bêta. Par conséquent, elle n'est pas évaluée. |
Évaluation sur GKE
En ce qui concerne les recommandations spécifiques à GKE (section 6), étant donné qu'elles peuvent toutes être configurées pour réussir dans votre environnement, nous utilisons les valeurs suivantes comme valeurs par défaut :
| État | Description |
|---|---|
| Par défaut | Par défaut, un nouveau cluster respecte une recommandation du benchmark. |
| Pas par défaut | Par défaut, un nouveau cluster ne respecte pas une recommandation du benchmark. |
| Dépend de l'environnement | GKE ne configure pas les éléments liés à cette recommandation. La configuration de l'utilisateur détermine si son environnement respecte une recommandation du benchmark. |
Valeurs par défaut sur GKE
Lorsque vous créez un cluster GKE avec la version spécifiée, voici les performances auxquelles vous pouvez vous attendre vis-à-vis du benchmark CIS de Kubernetes.
État du cluster GKE par défaut :
| # | Recommandation | Évalué/Non évalué | Niveau | État par défaut |
|---|---|---|---|---|
| 6 | Services gérés | |||
| 6.1 | Registre d'images et analyse des images | |||
| 6.1.1 | Assurez-vous que l'analyse des failles des images est activée à l'aide de Container Analysis GCR ou d'un fournisseur tiers | Évalué | L1 | Pas par défaut |
| 6.1.2 | Réduisez l'accès des utilisateurs à GCR | Évalué | L1 | Dépend de l'environnement |
| 6.1.3 | Réduisez l'accès au cluster en lecture seule pour GCR | Évalué | L1 | Pas par défaut |
| 6.1.4 | Limitez les registres de conteneurs à ceux qui sont approuvés | Non évalué | L2 | Pas par défaut |
| 6.2 | Identity and Access Management (IAM) | |||
| 6.2.1 | Évitez d'exécuter les clusters GKE à l'aide du compte de service Compute Engine par défaut | Évalué | L2 | Pas par défaut |
| 6.2.2 | Préférez l'utilisation de comptes de service Google Cloud dédiés et la fonctionnalité Workload Identity | Non évalué | L1 | Pas par défaut |
| 6.3 | Cloud Key Management Service (Cloud KMS) | |||
| 6.3.1 | Envisagez de chiffrer les secrets Kubernetes à l'aide des clés gérées dans Cloud KMS | Évalué | L1 | Pas par défaut |
| 6.4 | Métadonnées de nœud | |||
| 6.4.1 | Assurez-vous que les anciennes API de métadonnées de l'instance Compute Engine sont désactivées | Évalué | L1 | Par défaut |
| 6.4.2 | Vérifiez que le serveur de métadonnées GKE est activé | Non évalué | L2 | Pas par défaut |
| 6.5 | Configuration et maintenance des nœuds | |||
| 6.5.1 | Assurez-vous que Container-Optimized OS (COS) est utilisé pour les images de nœud GKE | Évalué | L2 | Par défaut |
| 6.5.2 | Assurez-vous que la réparation automatique des nœuds est activée pour les nœuds GKE | Évalué | L1 | Par défaut |
| 6.5.3 | Assurez-vous que la mise à niveau automatique des nœuds est activée pour les nœuds GKE | Évalué | L1 | Par défaut |
| 6.5.4 | Envisagez d'automatiser la gestion des versions de GKE en utilisant les versions disponibles | Non évalué | L1 | Pas par défaut |
| 6.5.5 | Assurez-vous que les nœuds GKE protégés sont activés | Non évalué | L1 | Pas par défaut |
| 6.5.6 | Assurez-vous que la surveillance de l'intégrité pour les nœuds GKE protégés est activée | Non évalué | L1 | Pas par défaut |
| 6.5.7 | Assurez-vous que le démarrage sécurisé pour les nœuds GKE protégés est activé | Non évalué | L2 | Pas par défaut |
| 6.6 | Mise en réseau des clusters | |||
| 6.6.1 | Envisagez d'activer les journaux de flux VPC et la visibilité intranœud | Non évalué | L2 | Pas par défaut |
| 6.6.2 | Préférez les clusters VPC natifs | Évalué | L1 | Pas par défaut |
| 6.6.3 | Assurez-vous que les réseaux autorisés maîtres sont activés | Évalué | L1 | Pas par défaut |
| 6.6.4 | Assurez-vous que les clusters sont créés avec le point de terminaison privé activé et l'accès public désactivé | Évalué | L2 | Pas par défaut |
| 6.6.5 | Assurez-vous que les clusters sont créés avec des nœuds privés | Évalué | L1 | Pas par défaut |
| 6.6.6 | Envisagez de mettre en place des pare-feu sur les nœuds de calcul GKE | Non évalué | L1 | Pas par défaut |
| 6.6.7 | Assurez-vous que la règle de réseau est activée et définie de manière appropriée | Non évalué | L1 | Pas par défaut |
| 6.6.8 | Envisagez d'utiliser des certificats SSL gérés par Google | Non évalué | L2 | Dépend de l'environnement |
| 6.7 | Logging | |||
| 6.7.1 | Assurez-vous que Stackdriver Kubernetes Logging et Stackdriver Kubernetes Monitoring sont activés | Évalué | L1 | Par défaut |
| 6.7.2 | Envisagez d'activer la journalisation d'audit Linux | Non évalué | L2 | Pas par défaut |
| 6.8 | Authentification et autorisation | |||
| 6.8.1 | Assurez-vous que l'authentification de base à l'aide de mots de passe statiques est désactivée | Évalué | L1 | Par défaut |
| 6.8.2 | Vérifiez que l'authentification à l'aide de certificats clients est désactivée | Évalué | L1 | Par défaut |
| 6.8.3 | Envisagez de gérer les utilisateurs de Kubernetes RBAC à l'aide de Google Groupes pour RBAC | Non évalué | L2 | Pas par défaut |
| 6.8.4 | Assurez-vous que l'ancienne autorisation (ABAC) est désactivée | Évalué | L1 | Par défaut |
| 6.9 | Stockage | |||
| 6.9.1 | Envisagez d'activer les clés de chiffrement gérées par le client (CMEK) pour les disques persistants GKE. | Non évalué | L1 | Pas par défaut |
| 6.10 | Autres configurations de cluster | |||
| 6.10.1 | Vérifiez que l'interface utilisateur Web de Kubernetes est désactivée | Évalué | L1 | Par défaut |
| 6.10.2 | Assurez-vous que les clusters alpha ne sont pas utilisés pour les charges de travail de production | Évalué | L1 | Par défaut |
| 6.10.3 | Assurez-vous que les règles de sécurité du pod sont activées et définies de manière appropriée | Non évalué | L1 | Pas par défaut |
| 6.10.4 | Envisagez d'utiliser GKE Sandbox pour exécuter des charges de travail non approuvées | Non évalué | L2 | Pas par défaut |
| 6.10.5 | Préférez l'activation de l'autorisation binaire et la configuration de la règle de manière appropriée | Non évalué | L2 | Pas par défaut |
| 6.10.6 | Préférez l'activation de Cloud Security Command Center (Cloud SCC) | Non évalué | L1 | Pas par défaut |
Comment auditer les benchmarks
Des instructions spécifiques pour l'audit de chaque recommandation sont disponibles dans le benchmark CIS approprié. Toutefois, vous souhaiterez peut-être automatiser certaines de ces vérifications afin de simplifier le contrôle de ces commandes dans votre environnement. Les outils répertoriés ci-dessous peuvent vous y aider.
Notez que cela ne vous permet pas d'auditer les recommandations du benchmark CIS de Kubernetes qui ne peuvent pas être auditées sur GKE. Pour les composants que vous ne pouvez pas auditer directement, consultez la section Valeurs par défaut afin de comprendre comment votre environnement est d'ores et déjà configuré par GKE.
Audit automatisé du benchmark CIS de Kubernetes
Vous pouvez utiliser un outil Open Source kube-bench pour tester la configuration de votre cluster vis-à-vis du benchmark CIS de Kubernetes. Notez que vous ne pourrez pas exécuter les tests kube-bench master sur vos charges de travail GKE, car vous n'avez pas directement accès au nœud du plan de contrôle. Vous ne pourrez exécuter que les tests kube-bench node.
Assurez-vous de spécifier la version appropriée, par exemple :
kube-bench node --benchmark cis-1.5
Audit automatisé du benchmark CIS GKE
L'analyse de l'état de sécurité identifie les erreurs de configuration courantes dans votre environnement, telles que les pare-feu laissés ouverts ou les buckets publics. Cette analyse inclut les recommandations sur la sécurité de GKE. Si vous activez l'analyse de l'état de sécurité, vous serez informé des erreurs de configuration du cluster par le biais de Cloud Security Command Center.
De nombreuses recommandations évaluées de niveau 1 sont couvertes par des résultats correspondants dans l'analyse de l'état de sécurité.
| # | Recommandation | Évalué/Non évalué | Niveau | Résultats des analyses de Security Health Analytics |
|---|---|---|---|---|
| 6.1 | Registre d'images et analyse des images | |||
| 6.1.1 | Assurez-vous que l'analyse des failles des images est activée à l'aide de Container Analysis GCR ou d'un fournisseur tiers | Évalué | L1 | n/a |
| 6.1.2 | Réduisez l'accès des utilisateurs à GCR | Évalué | L1 | n/a |
| 6.1.3 | Réduisez l'accès au cluster en lecture seule pour GCR | Évalué | L1 | n/a |
| 6.1.4 | Limitez les registres de conteneurs à ceux qui sont approuvés | Non évalué | L2 | n/a |
| 6.2 | Identity and Access Management (IAM) | |||
| 6.2.1 | Évitez d'exécuter les clusters GKE à l'aide du compte de service Compute Engine par défaut | Évalué | L2 | OVER_PRIVILEGED_ACCOUNT et OVER_PRIVILEGED_SCOPES |
| 6.2.2 | Préférez l'utilisation de comptes de service Google Cloud dédiés et la fonctionnalité Workload Identity | Non évalué | L1 | WORKLOAD_IDENTITY_DISABLED |
| 6.3 | Cloud Key Management Service (Cloud KMS) | |||
| 6.3.1 | Envisagez de chiffrer les secrets Kubernetes à l'aide des clés gérées dans Cloud KMS | Évalué | L1 | n/a |
| 6.4 | Métadonnées de nœud | |||
| 6.4.1 | Assurez-vous que les anciennes API de métadonnées de l'instance Compute Engine sont désactivées | Évalué | L1 | LEGACY_METADATA_ENABLED |
| 6.4.2 | Vérifiez que le serveur de métadonnées GKE est activé | Non évalué | L2 | n/a |
| 6.5 | Configuration et maintenance des nœuds | |||
| 6.5.1 | Assurez-vous que Container-Optimized OS (COS) est utilisé pour les images de nœud GKE | Évalué | L2 | COS_NOT_USED |
| 6.5.2 | Assurez-vous que la réparation automatique des nœuds est activée pour les nœuds GKE | Évalué | L1 | AUTO_REPAIR_DISABLED |
| 6.5.3 | Assurez-vous que la mise à niveau automatique des nœuds est activée pour les nœuds GKE | Évalué | L1 | AUTO_UPGRADE_DISABLED |
| 6.5.4 | Envisagez d'automatiser la gestion des versions de GKE en utilisant les versions disponibles | Non évalué | L1 | n/a |
| 6.5.5 | Assurez-vous que les nœuds GKE protégés sont activés | Non évalué | L1 | n/a |
| 6.5.6 | Assurez-vous que la surveillance de l'intégrité pour les nœuds GKE protégés est activée | Non évalué | L1 | n/a |
| 6.5.7 | Assurez-vous que le démarrage sécurisé pour les nœuds GKE protégés est activé | Non évalué | L2 | n/a |
| 6.6 | Mise en réseau des clusters | |||
| 6.6.1 | Envisagez d'activer les journaux de flux VPC et la visibilité intranœud | Non évalué | L2 | FLOW_LOGS_DISABLED |
| 6.6.2 | Préférez les clusters VPC natifs | Évalué | L1 | IP_ALIAS_DISABLED |
| 6.6.3 | Assurez-vous que les réseaux autorisés maîtres sont activés | Évalué | L1 | MASTER_AUTHORIZED_NETWORKS_DISABLED |
| 6.6.4 | Assurez-vous que les clusters sont créés avec le point de terminaison privé activé et l'accès public désactivé | Évalué | L2 | n/a |
| 6.6.5 | Assurez-vous que les clusters sont créés avec des nœuds privés | Évalué | L1 | PRIVATE_CLUSTER_DISABLED |
| 6.6.6 | Envisagez de mettre en place des pare-feu sur les nœuds de calcul GKE | Non évalué | L1 | n/a |
| 6.6.7 | Assurez-vous que la règle de réseau est activée et définie de manière appropriée | Non évalué | L1 | NETWORK_POLICY_DISABLED |
| 6.6.8 | Envisagez d'utiliser des certificats SSL gérés par Google | Non évalué | L2 | n/a |
| 6.7 | Logging | |||
| 6.7.1 | Assurez-vous que Stackdriver Kubernetes Logging et Stackdriver Kubernetes Monitoring sont activés | Évalué | L1 | CLUSTER_LOGGING_DISABLED et CLUSTER_MONITORING_DISABLED |
| 6.7.2 | Envisagez d'activer la journalisation d'audit Linux | Non évalué | L2 | n/a |
| 6.8 | Authentification et autorisation | |||
| 6.8.1 | Assurez-vous que l'authentification de base à l'aide de mots de passe statiques est désactivée | Évalué | L1 | n/a |
| 6.8.2 | Vérifiez que l'authentification à l'aide de certificats clients est désactivée | Évalué | L1 | n/a |
| 6.8.3 | Envisagez de gérer les utilisateurs de Kubernetes RBAC à l'aide de Google Groupes pour RBAC | Non évalué | L2 | n/a |
| 6.8.4 | Assurez-vous que l'ancienne autorisation (ABAC) est désactivée | Évalué | L1 | LEGACY_AUTHORIZATION_ENABLED |
| 6.9 | Stockage | |||
| 6.9.1 | Envisagez d'activer les clés de chiffrement gérées par le client (CMEK) pour les disques persistants GKE. | Non évalué | L1 | n/a |
| 6.10 | Autres configurations de cluster | |||
| 6.10.1 | Vérifiez que l'interface utilisateur Web de Kubernetes est désactivée | Évalué | L1 | WEB_UI_ENABLED |
| 6.10.2 | Assurez-vous que les clusters alpha ne sont pas utilisés pour les charges de travail de production | Évalué | L1 | n/a |
| 6.10.3 | Assurez-vous que les règles de sécurité du pod sont activées et définies de manière appropriée | Non évalué | L1 | POD_SECURITY_POLICY_DISABLED |
| 6.10.4 | Envisagez d'utiliser GKE Sandbox pour exécuter des charges de travail non approuvées | Non évalué | L2 | n/a |
| 6.10.5 | Préférez l'activation de l'autorisation binaire et la configuration de la règle de manière appropriée | Non évalué | L2 | n/a |
| 6.10.6 | Préférez l'activation de Cloud Security Command Center (Cloud SCC) | Non évalué | L1 | n/a |
Étape suivante
- Consultez la présentation de la sécurité dans GKE.
- Suivez les bonnes pratiques de sécurité décrites dans le guide de renforcement de la sécurité dans GKE.
- Apprenez-en davantage sur le modèle de responsabilité partagée dans GKE.