Benchmarks CIS

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 et Linux. Notez qu'il n'existe pas de benchmark CIS pour Container-Optimized OS (COS), le système d'exploitation de nœud par défaut pour GKE, ni pour l'environnement d'exécution du conteneur containerd.

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 (maître), 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 à :

  • être pratiques et prudentes ;
  • fournir un avantage clair en matière de sécurité ;
  • ne pas entraver l'utilité de la technologie au-delà du raisonnable.
  • Niveau 2

    Étend le profil du niveau 1.

    Les recommandations présentent une ou plusieurs des caractéristiques suivantes :

  • Elles sont destinés aux environnements ou aux cas d'utilisation où la sécurité est primordiale.
  • Elles servent de mesures de défense en profondeur.
  • Elles peuvent entraver l'utilité ou les performances de la technologie.
  • É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 Réussite
    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. É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 GCP 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 GKE 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 l'état de la sécurité
    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 GCP 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 vérifie s'il existe une configuration de cluster privé, mais pas si les nœuds sont privés
    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 GKE 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