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 :

  • La manière dont 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. Destiné à 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 donner la priorité au benchmark CIS de GKE, car il est spécifique à GKE sur Google Cloud. Le benchmark CIS de Kubernetes contient de nombreuses recommandations pour les 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 s'appliquant à GKE

Outre le benchmark CIS de GKE et le 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 toujours vous référer à ce benchmark 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 etcd, 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 ni les modifier, ni les évaluer par rapport aux contrôles du benchmark CIS correspondants. Cependant, 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 concernant la sécurisation de 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 la sécurité dans GKE
Authentification
  • Certains composants de surveillance de GKE utilisent l'authentification anonyme pour obtenir des métriques. GKE autorise l'authentification anonyme pour le kubelet, mais cette exposition est identique à celle du port en lecture seule, car nous désactivons les gestionnaires de débogage supplémentaires.
  • 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 démarrage ou redémarrage d'une VM.
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 génère des journaux d'audit à l'aide de la stratégie d'audit GKE. Par conséquent, il n'est pas nécessaire de définir d'options de journalisation d'audit du serveur d'API Kubernetes.
Débogage GKE utilise le profilage pour le débogage.
Chiffrement
kubelet
  • GKE active le port en lecture seule du kubelet non authentifié.
  • 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 effectue une rotation des certificats clients lorsque les nœuds GKE protégés sont activés.
  • GKE utilise l'ensemble de chiffrement autorisé par défaut golang, qui est également la valeur 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 de 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 la section À 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