Renforcer la sécurité d'un cluster

Étant donné la rapidité de développement de Kubernetes, de nouvelles fonctionnalités de sécurité sont souvent introduites. Cette page vous guide dans la mise en œuvre de nos conseils actuels sur le renforcement de votre cluster Google Kubernetes Engine (GKE).

Ce guide donne la priorité aux mesures d'atténuation des risques dans les domaines où la sécurité est particulièrement importante et qui nécessitent l'intervention du client lors de la création du cluster. Les fonctionnalités moins critiques, les paramètres de sécurité par défaut et ceux qui peuvent être activés après la création d'un cluster sont mentionnés plus loin dans le document. Pour obtenir des informations générales sur les sujets relatifs à la sécurité, consultez la page Présentation des fonctionnalités de sécurité.

La plupart des recommandations de cette page, ainsi que d'autres erreurs de configuration courantes, peuvent être vérifiées automatiquement à l'aide de l'analyse de l'état de la sécurité.

Lorsque les recommandations ci-dessous concernent une recommandation de benchmark CIS GKE, celle-ci est spécifiée.

Mettre à niveau votre infrastructure GKE en temps opportun (par défaut, 11/11/2019)

Recommandation de benchmark CIS GKE : 6.5.3. Assurez-vous que la mise à niveau automatique des nœuds est activée pour les nœuds GKE

Maintenir à jour la version de Kubernetes est l'une des choses les plus simples que vous puissiez faire pour améliorer la sécurité de votre cluster. Kubernetes introduit fréquemment de nouvelles fonctionnalités de sécurité et fournit des correctifs de sécurité.

Consultez les bulletins de sécurité GKE pour plus d'informations sur les correctifs de sécurité.

Dans Google Kubernetes Engine, les maîtres sont corrigés et mis à niveau automatiquement. La mise à niveau automatique des nœuds met également à niveau automatiquement les nœuds de votre cluster.

Si vous décidez de désactiver la mise à niveau automatique des nœuds, nous vous recommandons de procéder à une mise à niveau mensuelle selon votre propre calendrier. Pour les clusters les plus anciens, vous devez activer la mise à niveau automatique des nœuds et suivre de près les bulletins de sécurité GKE pour les correctifs critiques.

Pour en savoir plus, consultez la page Mettre à niveau automatiquement des nœuds.

Limiter l'accès réseau au plan de contrôle et aux nœuds

Recommandations de benchmark CIS GKE : 6.6.2. Préférez les clusters VPC natifs (6.6.3). Assurez-vous que les réseaux autorisés maîtres sont activés, (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é, et en version 6.6.5. Assurez-vous que les clusters sont créés avec des nœuds privés

Vous devez limiter l'exposition du plan de contrôle et des nœuds des clusters à Internet. Ces paramètres ne peuvent être définis qu'au moment de la création du cluster.

Par défaut, le plan de contrôle et les nœuds des clusters GKE disposent d'adresses Internet routables auxquelles il est possible d'accéder depuis n'importe quelle adresse IP.

Pour le plan de contrôle des clusters GKE, consultez la page Configurer un cluster privé. Il existe trois types de clusters privés pouvant fournir une protection au niveau du réseau :

  • Accès public aux points de terminaison désactivé : cette option est la plus sécurisée, car elle empêche tout accès Internet à la fois aux maîtres et aux nœuds. C'est un bon choix si vous avez configuré votre réseau sur site pour une connexion à Google Cloud via Cloud Interconnect et Cloud VPN. Ces technologies relient efficacement le réseau de votre entreprise à votre VPC.
  • Accès public aux points de terminaison activé, réseaux autorisés maîtres activés (recommandé) : cette option permet un accès restreint au serveur maître à partir des adresses IP sources que vous définissez. Cette option est idéale si vous ne disposez pas d'une infrastructure VPN existante, ou si vous avez des utilisateurs distants ou des filiales qui se connectent via l'Internet public plutôt qu'avec le VPN d'entreprise et Cloud Interconnect ou Cloud VPN.
  • Accès public aux points de terminaison activé, réseaux autorisés maîtres désactivés : cette option est activée par défaut et permet à tous les internautes de se connecter au plan de contrôle.

Pour désactiver l'accès Internet direct aux nœuds, spécifiez l'option "--enable-private-nodes" de l'outil gcloud lors de la création du cluster.

Cela indique à GKE de provisionner des nœuds avec des adresses IP internes, ce qui signifie que les nœuds ne sont pas directement accessibles via l'Internet public.

Nous recommandons que les clusters utilisent au moins des réseaux autorisés maîtres et des nœuds privés. Ainsi, le plan de contrôle est accessible par :

  • les adresses CIDR autorisées dans les réseaux autorisés maîtres ;
  • les nœuds au sein du VPC de votre cluster ;
  • les tâches de production internes de Google qui gèrent votre maître.

Cela correspond aux options gcloud suivantes lors de la création du cluster :

  • --enable-ip-alias
  • --enable-private-nodes
  • --enable-master-authorized-networks

Authentification de groupe (version bêta)

Recommandation de benchmark CIS GKE : 6.8.3. Envisagez de gérer les utilisateurs de Kubernetes RBAC à l'aide de Google Groupes pour GKE

Ce paramètre ne peut être activé qu'au moment de la création du cluster.

Vous devez utiliser des groupes pour gérer vos utilisateurs. L'utilisation de groupes permet de contrôler les identités à l'aide de votre système de gestion des identités et de vos administrateurs d'identité. Si vous ajustez l'appartenance au groupe, vous n'avez pas besoin de mettre à jour votre configuration RBAC chaque fois qu'un utilisateur est ajouté ou supprimé du groupe.

Pour gérer les autorisations des utilisateurs à l'aide de Google Groupes, vous devez activer la fonction Google Groupes pour GKE lors de la création de votre cluster. Cela vous permet de gérer facilement les utilisateurs disposant des mêmes autorisations, tout en permettant à vos administrateurs d'identité de gérer les utilisateurs de manière centralisée et cohérente.

Pour activer Google Groupes pour GKE, créez un groupe Google, gke-security-groups, afin de gérer l'accès des utilisateurs et spécifiez l'option gcloud --security-group lors de la création du cluster.

Choix du nœud du conteneur

Les sections suivantes décrivent les choix de configuration sécurisée des nœuds.

Activer les nœuds GKE protégés

Recommandation de benchmark CIS GKE : 6.5.5. Assurez-vous que les nœuds GKE protégés sont activés

Les nœuds GKE protégés offrent une identité et une intégrité de nœud solides et vérifiables pour renforcer la sécurité des nœuds GKE. Ils doivent être activés sur tous les clusters GKE.

Pour activer les nœuds GKE protégés, spécifiez l'option gcloud --enable-shielded-nodes lors de la création ou de la mise à jour du cluster. Les nœuds GKE protégés doivent être activés avec le démarrage sécurisé. Le démarrage sécurisé ne doit pas être utilisé si vous avez besoin de modules de noyau non signés tiers. Pour activer le démarrage sécurisé, spécifiez l'option gcloud --shielded-secure-boot lors de la création du cluster.

Choisir une image de nœud renforcée avec l'environnement d'exécution containerd

L'image Container-Optimized OS avec Containerd (cos_containerd) est une variante de l'image Container-Optimized OS où containerd est l'environnement d'exécution principal des conteneurs et est directement intégré à Kubernetes.

Containerd est le composant d'exécution principal de Docker et a été conçu pour fournir la fonctionnalité principale du conteneur pour la spécification Container Runtime Interface (CRI, Interface de l'environnement d'exécution de conteneurs) Kubernetes. Il est nettement moins complexe que le daemon Docker complet et présente donc une surface d'attaque plus petite.

Pour utiliser l'image cos_containerd dans votre cluster, spécifiez l'option gcloud --image-type=cos_containerd lors de la création ou de la mise à niveau du cluster.

Cos_containerd est l'image à privilégier pour GKE, car elle a été personnalisée, optimisée et renforcée spécialement pour l'exécution de conteneurs.

Activer Workload Identity

Recommandation de benchmark CIS GKE : 6.2.2. Préférez l'utilisation de comptes de service Google Cloud dédiés et la fonctionnalité Workload Identity

Workload Identity est la méthode recommandée pour s'authentifier auprès des API Google. Cette fonctionnalité remplace les pratiques habituelles consistant à utiliser le compte de service de nœud ou à exporter des clés de compte de service dans des secrets comme décrit dans la page S'authentifier sur Google Cloud avec des comptes de service.

Workload Identity vous évite par ailleurs d'avoir à utiliser la dissimulation de métadonnées. Par conséquent, les deux approches sont incompatibles. Les métadonnées sensibles protégées par la dissimulation de métadonnées sont également protégées par Workload Identity.

Renforcer l'isolation d'une charge de travail avec GKE Sandbox

Recommandation de benchmark CIS GKE : 6.10.4. Envisagez d'utiliser GKE Sandbox pour renforcer l'isolation des charges de travail, en particulier pour les charges de travail non approuvées.

GKE Sandbox offre un niveau de sécurité supplémentaire pour empêcher un code malveillant d'affecter le noyau hôte sur vos nœuds de cluster.

Découvrez comment utiliser GKE Sandbox dans l'article Renforcer l'isolation d'une charge de travail avec GKE Sandbox.

Autorisations

Utiliser le principe du moindre privilège pour les comptes de service Google

Recommandation de benchmark CIS GKE : 6.2.1. Évitez d'exécuter les clusters GKE à l'aide du compte de service Compute Engine par défaut.

Chaque nœud GKE est associé à un compte de service de gestion de l'authentification et des accès (IAM). Par défaut, les nœuds se voient affecter le compte de service par défaut de Compute Engine, que vous trouverez dans la section "IAM" de Cloud Console. Ce compte dispose d'un accès étendu par défaut, ce qui le rend utile pour une grande variété d'applications. Cependant, il dispose de plus d'autorisations que nécessaire pour exécuter votre cluster Kubernetes Engine. Vous devez créer et utiliser un compte de service associé à des privilèges minimaux pour exécuter le cluster GKE, plutôt que le compte de service par défaut de Compute Engine.

Avec le lancement de Workload Identity, nous suggérons une utilisation plus limitée du compte de service de nœud. Nous pensons que le compte de service de nœud sera utilisé par les daemons système chargés de la journalisation, de la surveillance et d'autres tâches similaires. À la place, les charges de travail hébergées dans les pods doivent être des identités Google provisionnées avec Workload Identity.

GKE exige, au minimum, que le compte de service dispose des rôles monitoring.viewer, monitoring.metricWriter et logging.logWriter. Pour en savoir plus, consultez les informations sur les rôles Monitoring et Logging.

Les commandes suivantes permettent de créer un compte de service IAM avec les autorisations minimales requises pour exécuter GKE :

gcloud

gcloud iam service-accounts create sa-name \
  --display-name=sa-name

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/logging.logWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.viewer

Connecteur de configuration

Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

  1. Pour créer le compte de service, téléchargez la ressource suivante en tant que service-account.yaml. Remplacez [SA_NAME] par le nom que vous souhaitez utiliser pour le compte de service.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    metadata:
      name: [SA_NAME]
    spec:
      displayName: [SA_NAME]
    Exécutez ensuite la commande ci-dessous :
    kubectl apply -f service-account.yaml

  2. Appliquez le rôle logging.logWriter au compte de service. Téléchargez la ressource suivante en tant que policy-logging.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-logging
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/logging.logWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-logging.yaml

  3. Appliquez le rôle monitoring.metricWriter. Téléchargez la ressource suivante en tant que policy-metrics-writer.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-metrics-writer
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.metricWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-metrics-writer.yaml

  4. Appliquez le rôle monitoring.viewer. Téléchargez la ressource suivante en tant que policy-monitoring.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-monitoring
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.viewer
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-monitoring.yaml

Si vous utilisez des images privées dans Google Container Registry, vous devez également autoriser l'accès à ces éléments :

gcloud

gcloud projects add-iam-policy-binding project-id \
--member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
--role roles/storage.objectViewer

Connecteur de configuration

Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

Appliquez le rôle storage.objectViewer à votre compte de service. Téléchargez la ressource suivante en tant que policy-object-viewer.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-object-viewer.yaml

Si vous souhaitez qu'un autre utilisateur puisse créer des clusters ou des pools de nœuds avec ce compte de service, vous devez lui accorder le rôle d'utilisateur du compte de service sur ce compte de service :

gcloud

gcloud iam service-accounts add-iam-policy-binding \
sa-name@project-id.iam.gserviceaccount.com \
--member=user:user \
--role=roles/iam.serviceAccountUser

Connecteur de configuration

Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

Appliquez le rôle iam,serviceAccountUser à votre compte de service. Téléchargez la ressource suivante en tant que policy-service-account-user.yaml. Remplacez [SA_NAME] et [PROJECT_ID] par vos propres informations.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-service-account-user.yaml

Si le cluster existe déjà, vous pouvez désormais créer un pool de nœuds avec le nouveau compte de service :

gcloud container node-pools create node-pool \
  --service-account=sa-name@project-id.iam.gserviceaccount.com \
  --cluster=cluster-name

Si vous souhaitez que votre cluster GKE ait accès à d'autres services Google Cloud, vous devez créer un compte de service supplémentaire et accorder à vos charges de travail l'accès au compte de service à l'aide de Workload Identity.

Restreindre l'accès à la détection d'API de cluster

Par défaut, Kubernetes amorce les clusters avec un ensemble de ClusterRoleBindings de découverte qui donnent un large accès aux informations sur les API d'un cluster, y compris celles des CustomResourceDefinitions.

Les utilisateurs doivent savoir que le groupe system:authenticated inclus dans les sujets des ClusterRoleBindings system:discovery et system:basic-user peut inclure tout utilisateur authentifié, y compris tout utilisateur disposant d'un compte Google, et ne représente pas un niveau de sécurité significatif pour les clusters sur GKE.

Les personnes souhaitant renforcer la sécurité des API de découverte de leur cluster doivent envisager de procéder à l'une ou plusieurs des opérations suivantes :

Si aucune de ces options ne convient à votre cas d'utilisation GKE, vous devez traiter toutes les informations de découverte d'API (le schéma de CustomResources, les définitions d'APIService et les informations de découverte hébergées par des serveurs d'API d'extension) comme divulguées publiquement.

Utiliser les espaces de noms et les autorisations RBAC pour limiter l'accès aux ressources du cluster

Recommandation de benchmark CIS GKE : 5.6.1. Créez des limites administratives entre les ressources à l'aide d'espaces de noms

Lorsque vous définissez les accès de vos équipes à Kubernetes, appliquez le principe du moindre privilège en créant des espaces de noms ou des clusters distincts pour chaque équipe et chaque environnement. Affectez des centres de coûts et les libellés appropriés à chaque espace de noms pour renforcer la responsabilisation et permettre le rejet de débit. N'accordez aux développeurs que le niveau d'accès à l'espace de noms dont ils ont besoin pour déployer et gérer leur application, en particulier en production. Planifiez les tâches que vos utilisateurs doivent effectuer sur le cluster et définissez les autorisations dont ils ont besoin pour chaque tâche.

Pour en savoir plus sur la création d'espaces de noms, consultez la documentation Kubernetes.

IAM et le contrôle des accès basé sur les rôles (RBAC) fonctionnent conjointement, et une entité doit disposer des autorisations nécessaires, dans les deux cadres, pour travailler avec les ressources de votre cluster.

Attribuez les rôles IAM appropriés pour GKE aux groupes et aux utilisateurs afin de leur fournir des autorisations au niveau du projet et d'utiliser le contrôle d'accès RBAC pour accorder des autorisations au niveau d'un cluster et d'un espace de noms. Pour en savoir plus, consultez la page sur le contrôle des accès.

Pour plus d'informations, consultez la page Préparer un environnement Google Kubernetes Engine pour la production.

Limiter le trafic entre les pods avec une règle de réseau

Recommandation de benchmark CIS GKE : 6.6.7. Assurez-vous que la règle de réseau est activée et définie de manière appropriée

Par défaut, tous les pods d'un cluster peuvent communiquer entre eux. Vous devez contrôler les communications entre les pods en fonction de vos charges de travail.

Lorsque vous limitez l'accès réseau des services, il est beaucoup plus difficile pour les pirates informatiques de se déplacer latéralement au sein du cluster. Cela présente également l'avantage de doter les services d'une protection contre les dénis de service accidentels ou provoqués délibérément. Voici deux méthodes recommandées pour contrôler le trafic :

  1. Utilisez Istio. Consultez la page Installer Istio sur GKE. Choisissez cette option si vous envisagez d'avoir recours à l'équilibrage de charge, à l'autorisation de services, à la limitation de la bande passante, aux quotas, aux métriques, etc.
  2. Utilisez les règles de réseau Kubernetes. Consultez la page Créer une règle de réseau pour un cluster. Choisissez cette option si vous recherchez la fonctionnalité de contrôle d'accès de base exposée par Kubernetes. Pour mettre en œuvre des approches courantes pour restreindre le trafic à l'aide de règles de réseau, suivez le guide de mise en œuvre des plans de sécurité Anthos. En outre, la documentation Kubernetes propose un excellent tutoriel pour un déploiement nginx simple. Pensez à utiliser la journalisation des règles de réseau (bêta) pour vérifier que vos règles de réseau fonctionnent comme prévu.

Istio et les règles de réseau peuvent être utilisés conjointement si besoin est.

Gestion secrète

Recommandation de benchmark CIS GKE : 6.3.1. Envisagez de chiffrer les secrets Kubernetes à l'aide des clés gérées dans Cloud KMS

Vous devez fournir une couche de protection supplémentaire pour les données sensibles (par exemple, les secrets) stockées dans etcd. Pour ce faire, vous devez configurer un gestionnaire de secrets intégré aux clusters GKE. Certaines solutions fonctionnent à la fois dans GKE et dans GKE On-Prem. Elles peuvent donc être plus utiles si vous exécutez des charges de travail dans plusieurs environnements. Si vous choisissez d'utiliser un gestionnaire de secrets externe (par exemple, HashiCorp Vault), vous devez configurer ce gestionnaire avant de créer votre cluster.

Vous disposez de plusieurs options pour la gestion des secrets.

  • Vous pouvez utiliser les secrets Kubernetes en mode natif dans GKE. Vous pouvez éventuellement les chiffrer au niveau de l'application avec une clé que vous gérez, en utilisant le chiffrement des secrets au niveau de la couche d'application.
  • Vous pouvez utiliser un gestionnaire de secrets tel que HashiCorp Vault. L'utilisation d'un mode renforcé à haute disponibilité permet une gestion des secrets cohérente et prête pour la production. Vous pouvez vous authentifier auprès de HashiCorp Vault à l'aide d'un compte de service Kubernetes ou d'un compte de service Google Cloud. Pour en savoir plus sur l'utilisation de GKE avec Vault, consultez la page indiquant comment exécuter et connecter HashiCorp Vault sur Kubernetes.

Les VM GKE sont chiffrées au niveau de la couche de stockage par défaut, ce qui inclut etcd.

Utiliser des contrôleurs d'admission pour appliquer les règles

Recommandation de benchmark CIS GKE : 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

Les contrôleurs d'admission sont des plug-ins qui régissent et appliquent la façon dont le cluster est utilisé. Ils doivent être activés pour utiliser certaines des fonctionnalités de sécurité les plus avancées de Kubernetes et constituent un élément important de l'approche de défense en profondeur pour renforcer votre cluster.

Par défaut, les pods de Kubernetes peuvent fonctionner avec des fonctionnalités allant au-delà de leurs besoins. Vous devez limiter les capacités des pods à celles requises pour la charge de travail.

Kubernetes permet de contrôler l'exécution des pods afin qu'elle se limite aux fonctionnalités explicitement autorisées. Les règles de sécurité des pods permettent de définir des valeurs par défaut intelligentes pour les pods et d'appliquer les contrôles à activer sur l'ensemble du parc. Les règles que vous définissez doivent être spécifiques aux besoins de votre application. L'exemple de règle restricted-psp.yaml est un bon point de départ.

Pour en savoir plus sur les règles de sécurité des pods, consultez la page Utiliser PodSecurityPolicies.

Si vous utilisez un NetworkPolicy et que vous avez un pod soumis à un PodSecurityPolicy, créez un Role ou un ClusterRole RBAC autorisé à utiliser le PodSecurityPolicy. Liez ensuite le Role ou le ClusterRole au compte de service du pod. Accorder des autorisations aux comptes utilisateur n'est pas suffisant dans ce cas. Pour plus d'informations, consultez la section Autoriser les règles.

Surveiller la configuration du cluster

Vous devez vérifier les configurations de votre cluster pour repérer d'éventuels écarts par rapport aux paramètres que vous avez définis.

La plupart des recommandations présentées dans ce guide de renforcement, ainsi que d'autres erreurs de configuration courantes, peuvent être vérifiées automatiquement à l'aide de l'analyse de l'état de la sécurité.

Configuration par défaut sécurisée

Les sections suivantes décrivent les options qui sont configurées de manière sécurisée par défaut dans les nouveaux clusters. Vous devez vérifier que les clusters préexistants sont configurés de manière sécurisée.

Protéger les métadonnées des nœuds (par défaut pour les versions 1.12 et supérieures)

Recommandations de benchmark CIS GKE : 6.4.1. Assurez-vous que les anciennes API de métadonnées de l'instance Compute Engine sont désactivées et en version 6.4.2. Vérifiez que le serveur de métadonnées GKE est activé

Le serveur de métadonnées d'instance de Compute Engine expose les anciens points de terminaison /0.1/ et /v1beta1/ qui n'appliquent pas les en-têtes de requête de métadonnées. Ces API ont été désactivées par défaut pour les nouveaux clusters des versions 1.12 et supérieures. Si vous avez mis à niveau des clusters à partir de versions plus anciennes, vous devez désactiver ces anciennes API manuellement.

Certaines attaques menées contre Kubernetes reposent sur un accès au serveur de métadonnées de la VM visant à extraire les identifiants. Ces attaques sont bloquées si vous utilisez Workload Identity ou la dissimulation de métadonnées.

Les points de terminaison du serveur de métadonnées v1beta1 et v0.1 de Compute Engine sont obsolètes et doivent être arrêtés. Veillez à mettre à jour toutes les requêtes de sorte qu'elles utilisent le point de terminaison v1.

Pour en savoir plus, consultez la page Protéger les métadonnées d'un cluster.

Conserver les anciennes méthodes d'authentification client en mode inactif (par défaut pour les versions 1.12 et supérieures)

Recommandations de benchmark CIS GKE : 6.8.1. Assurez-vous que l'authentification de base à l'aide de mots de passe statiques est désactivée et en version 6.8.2. Vérifiez que l'authentification à l'aide de certificats clients est désactivée

Il existe plusieurs méthodes d'authentification sur le serveur d'API Kubernetes. Dans GKE, les méthodes acceptées sont les jetons de support de compte de service, les jetons OAuth et les certificats client x509. GKE gère l'authentification avec gcloud en utilisant la méthode du jeton OAuth, en gérant la configuration de Kubernetes, ainsi qu'en obtenant un jeton d'accès et en le maintenant à jour.

Avant l'intégration de GKE à OAuth, les seules méthodes d'authentification disponibles étaient les certificats x509 générés pour un usage unique et les mots de passe statiques. Aujourd'hui, ces méthodes ne sont plus recommandées et il est préférable de les désactiver. Ces méthodes présentent une surface d'attaque plus étendue pouvant compromettre la sécurité du cluster. Elles sont désactivées par défaut depuis la version 1.12 de GKE. Si vous utilisez d'anciennes méthodes d'authentification, nous vous recommandons de les désactiver. L'authentification avec un mot de passe statique est obsolète et a été supprimée depuis la version 1.19 de GKE.

Les clusters existants doivent désormais utiliser la méthode OAuth. Si un système externe au cluster requiert des identifiants de longue durée, nous vous recommandons de créer un compte de service Google ou un compte de service Kubernetes avec les privilèges nécessaires, puis d'exporter la clé.

Pour mettre à jour un cluster existant et supprimer le mot de passe statique, exécutez cette commande :

gcloud container clusters update cluster-name \
  --no-enable-basic-auth

Il n'existe actuellement aucun moyen de supprimer le certificat client pré-émis d'un cluster existant, mais il ne dispose d'aucune autorisation si le contrôle d'accès RBAC est activé et si ABAC est désactivé.

Laisser Cloud Logging activé (configuration par défaut)

Recommandation de benchmark CIS GKE : 6.7.1. Assurez-vous que Stackdriver Kubernetes Logging et Stackdriver Kubernetes Monitoring sont activés

Pour réduire la charge opérationnelle et conserver une vue consolidée de vos journaux, mettez en œuvre une stratégie de journalisation cohérente partout où vos clusters sont déployés. Par défaut, les clusters Anthos sont intégrés à Cloud Logging et doivent rester configurés.

Par défaut, tous les clusters GKE ont la fonctionnalité de journalisation d'audit Kubernetes activée. Elle conserve un enregistrement chronologique des appels envoyés au serveur d'API Kubernetes. Les entrées du journal d'audit Kubernetes sont utiles pour enquêter sur les requêtes API suspectes, pour collecter des statistiques ou pour créer des alertes de surveillance pour les appels d'API indésirables.

Les clusters GKE intègrent la journalisation d'audit Kubernetes avec Cloud Audit Logging et Cloud Logging. Les journaux peuvent être exportés depuis Cloud Logging vers vos propres systèmes de journalisation, si vous le souhaitez.

Conserver l'UI Web de Kubernetes en mode inactif (par défaut pour les versions 1.10 et supérieures)

Recommandation de benchmark CIS GKE : 6.10.1. Vérifiez que l'interface utilisateur Web de Kubernetes est désactivée

Vous ne devez pas activer l'UI Web de Kubernetes (tableau de bord) lorsque vous utilisez GKE.

L'UI Web de Kubernetes (tableau de bord) est protégée par un compte de service Kubernetes à privilèges élevés. La Cloud Console offre presque les mêmes fonctionnalités. Vous n'avez donc pas besoin de ces autorisations.

Pour désactiver l'UI Web de Kubernetes, exécutez cette commande :

gcloud container clusters update cluster-name \
    --update-addons=KubernetesDashboard=DISABLED

Conserver ABAC en mode inactif (par défaut pour les versions 1.10 et supérieures)

Recommandation de benchmark CIS GKE : 6.8.4. Assurez-vous que l'ancienne autorisation (ABAC) est désactivée

Vous devez désactiver le contrôle des accès basé sur les attributs (ABAC, Attribute-Based Access Control) et utiliser à la place le contrôle des accès basé sur les rôles (RBAC, Role-Based Access Control) dans GKE.

Dans Kubernetes, RBAC permet d'accorder des autorisations aux ressources au niveau du cluster et de l'espace de noms. Le contrôle d'accès RBAC permet de définir des rôles avec des règles contenant un ensemble d'autorisations. Il présente des avantages considérables en matière de sécurité et est désormais stable dans Kubernetes. Vous pouvez donc à présent désactiver le contrôle d'accès ABAC.

Si vous utilisez toujours le contrôle d'accès ABAC, lisez d'abord les conditions préalables correspondantes. Si vous avez mis à niveau votre cluster à partir d'une version antérieure et que vous utilisez le contrôle d'accès ABAC, vous devez mettre à jour la configuration des contrôles d'accès :

gcloud container clusters update cluster-name \
    --no-enable-legacy-authorization

Pour créer un cluster avec la recommandation ci-dessus, exécutez cette commande :

gcloud container clusters create cluster-name \
    --no-enable-legacy-authorization

Étapes suivantes