Benchmarks CIS

Cette page décrit l'approche adoptée par Google Kubernetes Engine (GKE) pour améliorer la conformité avec les benchmarks du CIS (Center for Internet Security) pour Kubernetes et GKE. Cette page contient les informations suivantes :

  • Comment nous configurons le plan de contrôle GKE géré pour qu'il soit conforme au benchmark CIS de Kubernetes
  • Comment configurer vos nœuds et vos charges de travail GKE pour qu'ils soient conformes au benchmark CIS de Google Kubernetes Engine (GKE)

À propos des benchmarks CIS

Le CIS publie les benchmarks suivants, qui contiennent des consignes de configuration sécurisée pour Kubernetes :

  • Benchmark CIS de Kubernetes : s'applique au projet Kubernetes Open Source. Il vise à fournir des conseils pour diverses implémentations Kubernetes autogérées et hébergées.
  • Benchmark CIS GKE : établit des consignes pour la configuration sécurisée des composants que vous pouvez contrôler dans les clusters GKE. Inclut des recommandations spécifiques à GKE sur Google Cloud.

Nous vous recommandons de privilégier le benchmark CIS GKE, car il est spécifique à GKE sur Google Cloud. Le benchmark CIS de Kubernetes contient de nombreuses recommandations de contrôles que vous ne pouvez pas afficher ni modifier dans GKE. Notre approche de la sécurité des clusters inclut des mesures d'atténuation qui dépassent le champ d'application du benchmark Open Source de Kubernetes et peut entraîner des conflits avec ces recommandations.

Autres benchmarks applicables à GKE

En plus du benchmark CIS de GKE et du benchmark CIS de Kubernetes, les benchmarks suivants s'appliquent aux systèmes d'exploitation disponibles dans GKE. Même si un benchmark d'OS spécifique ne traite pas explicitement de l'utilisation de Kubernetes, vous devez tout de même vous y référer pour obtenir des conseils de sécurité supplémentaires.

L'environnement d'exécution du conteneur par défaut, containerd, n'a pas de benchmark.

Modèle de responsabilité partagée

Selon le modèle de responsabilité partagée de GKE, nous gérons les composants suivants pour vous :

  • Le plan de contrôle, y compris les VM du plan de contrôle, le serveur d'API et les composants tels que la base de données d'état du cluster (etcd ou Spanner), kube-controller-manager et kube-scheduler
  • Le système d'exploitation du nœud

Ces composants existent dans un projet appartenant à GKE. Vous ne pouvez donc pas les modifier ni les évaluer par rapport aux contrôles de benchmark CIS correspondants. Toutefois, vous pouvez évaluer et corriger les contrôles du benchmark CIS qui s'appliquent à vos nœuds de calcul et à vos charges de travail. Selon le modèle de responsabilité partagée de GKE, ces composants relèvent de votre responsabilité.

Notre approche pour sécuriser GKE pour le benchmark CIS

GKE est une implémentation gérée de Kubernetes Open Source. Nous gérons entièrement le plan de contrôle et sommes responsables de la sécurisation de la configuration des composants du plan de contrôle. Le tableau suivant décrit certaines de nos décisions susceptibles d'affecter la notation des benchmarks CIS :

Approche de sécurité GKE
Authentification
  • Certains composants de surveillance de GKE utilisent l'authentification anonyme pour obtenir des métriques.
  • Certains composants du plan de contrôle sont amorcés à l'aide de jetons statiques, qui sont ensuite utilisés pour l'authentification sur le serveur d'API. Ces jetons sont générés chaque fois qu'une VM démarre ou redémarre.
Contrôleurs d'admission

GKE désactive les contrôleurs d'admission suivants :

  • EventRateLimit : il s'agit d'une fonctionnalité alpha de Kubernetes.
  • AlwaysPullImages : ce contrôleur fournit une protection pour les images de registre privé dans des clusters mutualisés non coopératifs, et pour ce faire, il fait en sorte que les registres d'images soient un point de défaillance unique pour la création de pods dans le cluster.
  • SecurityContextDeny : le contrôleur d'admission de sécurité des pods est préféré et disponible dans toutes les éditions GKE. Si vous utilisez GKE Enterprise, vous pouvez également activer l'application des normes de sécurité des pods à l'aide de Policy Controller.
  • ImagePolicyWebhook : GKE désactive ImagePolicyWebhook par défaut, car il possède ses propres mécanismes de gestion et de sécurité des images. Cela permet à GKE de maintenir un contrôle plus strict sur l'environnement et de s'assurer que ses pratiques de sécurité sont appliquées de manière cohérente. Toutefois, vous pouvez utiliser l'autorisation binaire ou Policy Controller pour la gestion des règles.
Journaux d'audit GKE capture les journaux d'audit à l'aide de la stratégie d'audit GKE. Par conséquent, nous n'avons pas besoin de définir d'indicateurs de journalisation d'audit du serveur d'API Kubernetes.
Débogage GKE utilise le profilage pour le débogage.
Chiffrement
etcd

Dans la version Open Source de Kubernetes, la base de données d'état du cluster utilise etcd. Dans GKE, la base de données backend qui stocke l'état du cluster est l'une des technologies suivantes :

  • etcd : le cluster exécute des instances etcd sur le plan de contrôle.
  • Spanner : GKE stocke l'état du cluster dans une base de données Spanner distincte des VM du plan de contrôle.

Tous les clusters GKE diffusent l'API etcd dans les VM du plan de contrôle. Toutes les interactions client avec l'API Kubernetes sont identiques à celles de Kubernetes Open Source. En fonction de la technologie de base de données qui sert de backend à l'API etcd de votre cluster, vous pouvez constater des écarts dans les scores liés à etcd du benchmark CIS Kubernetes Open Source.
kubelet
  • GKE active le port en lecture seule du kubelet non authentifié. Vous pouvez désactiver le port en définissant --no-autoprovisioning-enable-insecure-kubelet-readonly-port. Le port en lecture seule sera désactivé par défaut dans une prochaine version, après vous avoir laissé le temps de migrer.
  • Le mode GKE Standard permet à vos charges de travail de modifier les valeurs par défaut du noyau si nécessaire.
  • GKE limite le nombre d'événements Kubernetes dans le kubelet afin de réduire le risque d'attaques par déni de service.
  • GKE utilise mTLS pour sécuriser le trafic entre le kubelet et le serveur d'API.
  • GKE effectue une rotation des certificats de serveur par défaut et des certificats clients lorsque les nœuds GKE protégés sont activés.
  • GKE utilise l'ensemble d'algorithmes de chiffrement autorisés par défaut de Golang, qui est également celui par défaut pour Kubernetes.

Évaluer GKE par rapport aux benchmarks CIS

Vous pouvez automatiser l'évaluation de vos clusters par rapport aux benchmarks à l'aide de l'une des méthodes suivantes :

  • Benchmark CIS de GKE :

    • Toutes les éditions GKE :
      • Exécutez kube-bench pour évaluer les nœuds de calcul par rapport au benchmark. Pour en savoir plus, consultez le dépôt GitHub kube-bench.
      • Utilisez un outil tiers tel que Twistlock Defender pour évaluer les nœuds par rapport au benchmark.
    • Édition GKE Enterprise : utilisez le tableau de bord de conformité pour évaluer la conformité de tous vos clusters avec le benchmark CIS de GKE. Pour en savoir plus, consultez À propos du tableau de bord GKE Compliance.

  • Benchmark CIS de Kubernetes : exécutez kube-bench pour évaluer les nœuds de calcul par rapport au benchmark. Vous ne pouvez pas évaluer le plan de contrôle géré par rapport à ces recommandations dans le benchmark.

Étapes suivantes