Renforcer la sécurité d'un cluster

Cette page vous guide dans la mise en œuvre des bonnes pratiques actuelles pour renforcer la sécurité 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.

Ce document s'adresse aux spécialistes de la sécurité qui définissent, régissent et mettent en œuvre des règles et des procédures permettant de protéger les données d'une organisation contre tout accès non autorisé. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Avant de lire cette page, assurez-vous de connaître les éléments suivants:

• Présentation générale de la sécurité dans GKE
• Recommandation de benchmark CIS GKE

Si vous créez des clusters dans GKE, la plupart de ces protections sont activées par défaut. Si vous mettez à niveau des clusters existants, consultez régulièrement ce guide de renforcement et activez les nouvelles fonctionnalités.

Les clusters créés en mode Autopilot mettent en œuvre de nombreuses fonctions de renforcement de la sécurité par défaut dans GKE.

La plupart des recommandations de cette page, ainsi que d'autres erreurs de configuration courantes, peuvent être vérifiées automatiquement à l'aide de Security Health Analytics.

Mettre régulièrement à niveau votre infrastructure GKE

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 plans de contrôle sont corrigés et mis à niveau automatiquement. La mise à niveau automatique des nœuds met également à niveau automatiquement les nœuds de votre cluster.

La mise à niveau automatique des nœuds est activée par défaut pour les clusters créés avec la consoleGoogle Cloud depuis juin 2019 et pour les clusters créés avec l'API depuis le 11 novembre 2019.

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 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

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.

Limiter l'accès au plan de contrôle

Pour limiter l'accès au plan de contrôle du cluster GKE, consultez Configurer l'accès au plan de contrôle. Voici les options disponibles pour la protection au niveau du réseau:

• Point de terminaison basé sur DNS activé (recommandé) : vous pouvez contrôler qui peut accéder au point de terminaison basé sur DNS à l'aide de VPC Service Controls. VPC Service Controls vous permet de définir un paramètre de sécurité pour toutes les API Google de votre projet avec des attributs contextuels tels que l'origine du réseau. Ces paramètres peuvent être contrôlés de manière centralisée pour un projet dans l'ensemble des API Google, ce qui réduit le nombre d'endroits où vous devez configurer des règles d'accès.

• Accès aux points de terminaison externes et internes basés sur les adresses IP désactivé:cette option empêche tout accès au plan de contrôle via des points de terminaison basés sur les adresses IP.

• Accès au point de terminaison externe basé sur l'adresse IP désactivé:cette option empêche tout accès Internet aux deux plans de contrôle. 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 au point de terminaison externe basé sur l'adresse IP activé, réseaux autorisés activés:cette option permet un accès restreint au plan de contrôle à 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 au point de terminaison externe activé, réseaux autorisés désactivés:cette option permet à tous les internautes de se connecter au plan de contrôle.

Si vous utilisez des points de terminaison basés sur l'adresse IP, nous vous recommandons d'utiliser des réseaux autorisés pour les clusters.

Ainsi, le plan de contrôle est accessible par :

• les CIDR autorisés dans les réseaux autorisés ;
• les nœuds au sein du VPC de votre cluster ;
• Adresses IP réservées par Google à des fins de gestion de cluster.

Limiter l'accès aux nœuds

Pour désactiver l'accès Internet direct aux nœuds, spécifiez l'option --enable-private-nodes de la gcloud CLI 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.

Utiliser les règles de pare-feu selon le principe du moindre privilège

Minimiser le risque d'accès inattendu en utilisant le principe du moindre privilège pour les règles de pare-feu

GKE crée des règles de pare-feu VPC par défaut pour activer les fonctionnalités du système et appliquer les bonnes pratiques de sécurité. Pour obtenir la liste complète des règles de pare-feu créées automatiquement, consultez la section Règles de pare-feu créées automatiquement.

GKE crée ces règles de pare-feu par défaut avec une priorité de 1 000. Si vous créez des règles de pare-feu permissives avec une priorité plus élevée, par exemple une règle de pare-feu allow-all pour le débogage, votre cluster présente un risque d'accès inattendu.

Utiliser l'authentification de groupe

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

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 des groupes Google, vous devez activer la fonction Google Groupes pour RBAC sur votre cluster. Cela vous permet de gérer 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 savoir comment activer Google Groupes pour RBAC, consultez la page Google Groupes pour RBAC.

Configurer la sécurité des nœuds de 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.

Vous pouvez activer les nœuds GKE protégés 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 savoir comment activer les nœuds GKE protégés et comment activer le démarrage sécurisé à l'aide des nœuds GKE protégés, consultez la section Utiliser des nœuds GKE protégés.

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, consultez la page Images Containerd.

L'image 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 Federation for GKE

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

La fédération d'identité de charge de travail pour GKE est la méthode recommandée pour s'authentifier auprès des API Google Cloud .

La fédération d'identité de charge de travail pour GKE se substitue à la nécessité d'utiliser la dissimulation de métadonnées et 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 la fédération d'identité de charge de travail pour GKE.

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.

Vous pouvez exécuter des conteneurs dans un environnement de bac à sable pour limiter la plupart des attaques de fuite de conteneur, également appelées attaques par élévation des privilèges locaux. Pour connaître les failles de fuite des conteneurs, consultez les bulletins de sécurité. Ce type d'attaque permet à un pirate informatique d'accéder à la VM hôte du conteneur et, par conséquent, à d'autres conteneurs sur la même VM. Un bac à sable tel que GKE Sandbox peut vous aider à limiter l'impact de ces attaques.

Envisagez d'utiliser une charge de travail en bac à sable dans les situations suivantes :

• La charge de travail exécute du code non approuvé
• Vous souhaitez limiter l'impact si un pirate informatique compromet un conteneur dans la charge de travail.

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

Activer les notifications concernant les bulletins de sécurité

Lorsque des bulletins de sécurité sont disponibles et concernent votre cluster, GKE publie des notifications sur ces événements sous forme de messages dans les sujets Pub/Sub que vous configurez. Vous pouvez recevoir ces notifications sur un abonnement Pub/Sub, les intégrer à des services tiers et filtrer les types de notifications que vous souhaitez recevoir.

Pour en savoir plus sur la réception des bulletins de sécurité à l'aide des notifications de cluster GKE, consultez la page Notifications de cluster.

Désactiver le port accessible en lecture seule et non sécurisé du kubelet

Désactivez le port en lecture seule du kubelet et modifiez toutes les charges de travail qui utilisent le port 10255 pour qu'elles utilisent le port plus sécurisé 10250.

Le processus kubelet s'exécutant sur les nœuds diffuse une API en lecture seule via le port non sécurisé 10255. Kubernetes n'effectue aucune vérification d'authentification ni d'autorisation sur ce port. Le kubelet diffuse les mêmes points de terminaison sur le port 10250, authentifié et plus sécurisé.

Pour obtenir des instructions, consultez la section Désactiver le port accessible en lecture seule du kubelet sur les clusters GKE.

Accorder des autorisations d'accès

Les sections suivantes expliquent comment accorder l'accès à votre infrastructure GKE.

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

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.

GKE utilise des comptes de service IAM associés à vos nœuds pour exécuter des tâches système telles que la journalisation et la surveillance. Ces comptes de service de nœud doivent au minimum disposer du rôle Compte de service de nœud par défaut Kubernetes Engine (roles/container.defaultNodeServiceAccount) sur votre projet. Par défaut, GKE utilise le compte de service Compute Engine par défaut, qui est créé automatiquement dans votre projet, comme compte de service de nœud.

Si vous utilisez le compte de service par défaut de Compute Engine pour d'autres fonctions de votre projet ou de votre organisation, il est possible que le compte de service dispose d'autorisations supérieures aux besoins de GKE, ce qui pourrait vous exposer à des risques de sécurité.

Le compte de service associé à vos nœuds ne doit être utilisé que par les charges de travail système qui effectuent des tâches telles que la journalisation et la surveillance. Pour vos propres charges de travail, provisionnez des identités à l'aide de Workload Identity Federation for GKE.

Pour créer un compte de service personnalisé et lui attribuer le rôle requis pour GKE, procédez comme suit:

Vous pouvez également utiliser ce compte de service pour les ressources d'autres projets. Pour obtenir les instructions nécessaires, consultez la page Activer l'emprunt d'identité des comptes de service entre les projets.

Accorder l'accès aux dépôts d'images privées

Pour utiliser des images privées dans Artifact Registry, accordez le rôle Lecteur Artifact Registry (roles/artifactregistry.reader) au compte de service.

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

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

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

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 iam service-accounts add-iam-policy-binding \
    SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member=user:USER \
    --role=roles/iam.serviceAccountUser

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

Pour les clusters standards existants, vous pouvez désormais créer un pool de nœuds avec ce nouveau compte de service. Pour les clusters Autopilot, vous devez créer un nouveau cluster avec le compte de service. Pour obtenir des instructions, consultez la section Créer un cluster Autopilot.

• Créez un pool de nœuds utilisant le nouveau compte de service :

  gcloud container node-pools create NODE_POOL_NAME \
  --service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --cluster=CLUSTER_NAME

Si vous souhaitez que votre cluster GKE ait accès à d'autres Google Cloudservices, vous devez utiliser la fédération d'identité de charge de travail pour GKE.

Restreindre l'accès à la détection des API d'un 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. Pour en savoir plus, consultez la section Éviter les rôles et les groupes par défaut.

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 :

• N'activez que le point de terminaison basé sur DNS pour accéder au plan de contrôle.
• Configurer des réseaux autorisés pour limiter l'accès aux plages d'adresses IP définies.
• Limitez l'accès au plan de contrôle et activez les nœuds privés.

Si aucune de ces options ne convient à votre cas d'utilisation GKE, vous devez traiter toutes les informations de découverte d'API (à savoir le schéma des CustomResources, les définitions de services d'API et les informations de détection hébergées par des serveurs d'API d'extension) comme étant 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. Pour connaître les bonnes pratiques à appliquer lorsque vous planifiez votre configuration RBAC, consultez la page Bonnes pratiques pour GKE RBAC.

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 utilisez 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.

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 Google Kubernetes Engine si vous êtes intéressé par l'équilibrage de charge, l'autorisation de service, la limitation de bande passante, les quotas, les métriques, etc.
2. Utilisez les règles de réseau Kubernetes. Consultez la section Créer une règle de réseau de 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 inclus dans les plans de sécurité GKE Enterprise. 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 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.

Protéger vos données avec la gestion des secrets

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). Pour ce faire, vous devez configurer un gestionnaire de secrets intégré aux clusters GKE. Certaines solutions fonctionnent à la fois dans GKE et dans Google Distributed Cloud. 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 Google Cloud compte de service. Pour en savoir plus sur l'utilisation de GKE avec Vault, consultez la page indiquant comment exécuter et connecter HashiCorp Vault sur Kubernetes.

Google Cloud chiffre les données au niveau de la couche de stockage par défaut. Ce chiffrement par défaut de la couche de stockage inclut la base de données qui stocke l'état de votre cluster, qui est basé sur etcd ou Spanner.

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

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 nombreux contrôles de l'exécution des pods afin qu'elle se limite aux fonctionnalités explicitement autorisées. Par exemple, Policy Controller est disponible pour les clusters dans les parcs. Kubernetes dispose également du contrôleur d'admission PodSecurity intégré qui vous permet d'appliquer les normes de sécurité des pods dans des clusters individuels.

Policy Controller est une fonctionnalité de GKE Enterprise qui vous permet d'appliquer et de valider la sécurité sur des clusters GKE à grande échelle à l'aide de stratégies déclaratives. Pour savoir comment utiliser Policy Controller pour appliquer des contrôles déclaratifs sur votre cluster GKE, consultez la page Installer Policy Controller.

Le contrôleur d'admission PodSecurity vous permet d'appliquer des règles prédéfinies dans des espaces de noms spécifiques ou dans l'ensemble du cluster. Ces règles correspondent aux différentes normes de sécurité des pods.

Restreindre les capacités d'automodification des charges de travail

Certaines charges de travail Kubernetes, en particulier les charges de travail système, sont autorisées à s'automodifier. Par exemple, certaines charges de travail effectuent des autoscaling verticaux sur elle-mêmes. Bien que cette capacité soit pratique, elle peut permettre à un pirate informatique ayant déjà compromis un nœud de passer au niveau supérieur dans le cluster. Par exemple, un pirate informatique peut faire en sorte qu'une charge de travail sur le nœud se modifie pour s'exécuter en tant que compte de service plus privilégié qui existe dans le même espace de noms.

Idéalement, les charges de travail ne doivent pas être autorisées à se modifier elles-mêmes. Lorsque l'automodification est nécessaire, vous pouvez limiter les autorisations en appliquant des contraintes Gatekeeper ou Policy Controller, telles que NoUpdateServiceAccount de la bibliothèque Open Source Gatekeeper, qui offre plusieurs règles de sécurité utiles.

Lorsque vous déployez des règles, il est généralement nécessaire de permettre aux contrôleurs qui gèrent le cycle de vie du cluster de contourner les règles. Cela est nécessaire pour que les contrôleurs puissent apporter des modifications au cluster, telles que l'application de mises à niveau de cluster. Par exemple, si vous déployez la règle NoUpdateServiceAccount sur GKE, vous devez définir les paramètres suivants dans Constraint :

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Restreindre l'utilisation du type de volume obsolète gcePersistentDisk

Le type de volume obsolète gcePersistentDisk vous permet d'installer un disque persistant Compute Engine sur des pods. Nous vous recommandons de limiter l'utilisation du type de volume gcePersistentDisk dans vos charges de travail. GKE n'applique aucun contrôle des autorisations IAM sur le pod lors de l'installation de ce type de volume, bien que Google Cloud applique des contrôles d'autorisation lors de l'association du disque à la VM sous-jacente. Un pirate informatique déjà autorisé à créer des pods dans un espace de noms peut donc accéder au contenu des disques persistants Compute Engine de votre Google Cloud projet.

Pour accéder aux disques persistants Compute Engine et les utiliser, utilisez plutôt PersistentVolumes et PersistentVolumeClaims. Appliquez des règles de sécurité dans votre cluster afin d'empêcher l'utilisation du type de volume gcePersistentDisk.

Pour empêcher l'utilisation du type de volume gcePersistentDisk, appliquez une règle Baseline ou Restricted avec le Contrôleur d'admission PodSecurity. Vous pouvez également définir une contrainte personnalisée dans Policy Controller ou dans le contrôleur d'admission Gatekeeper.

Pour définir une contrainte personnalisée afin de restreindre ce type de volume, procédez comme suit :

1. Installer un contrôleur d'admission basé sur des règles, tel que Policy Controller ou OPA Gatekeeper.

   Policy Controller

   Installez Policy Controller dans votre cluster.

   Policy Controller est une fonctionnalité payante pour les utilisateurs de GKE. Policy Controller est basé sur la bibliothèque Open Source Gatekeeper, mais vous avez également accès à la bibliothèque complète de modèles de contraintes, aux groupes de règles et à l'intégration aux tableaux de bord de la console Google Cloud , pour vous aider à observer et gérer vos clusters. Les groupes de règles constituent des bonnes pratiques avisées, que vous pouvez appliquer à vos clusters, y compris des groupes basés sur des recommandations telles que le benchmark CIS de Kubernetes.

   Gatekeeper

   Installez Gatekeeper dans votre cluster.

   Pour les clusters Autopilot, ouvrez le fichier manifeste Gatekeeper gatekeeper.yaml dans un éditeur de texte. Modifiez le champ rules dans la spécification MutatingWebhookConfiguration pour remplacer les caractères génériques (*) par des groupes d'API et des noms de ressources spécifiques, comme dans l'exemple suivant :

   apiVersion: admissionregistration.k8s.io/v1
   kind: MutatingWebhookConfiguration
   ...
   webhooks:
   - admissionReviewVersions:
     - v1
     - v1beta1
     ...
     rules:
     - apiGroups:
       - core
       - batch
       - apps
       apiVersions:
       - '*'
       operations:
       - CREATE
       - UPDATE
       resources:
       - Pod
       - Deployment
       - Job
       - Volume
       - Container
       - StatefulSet
       - StorageClass
       - Secret
       - ConfigMap
     sideEffects: None
     timeoutSeconds: 1
   

   Appliquez le fichier manifeste gatekeeper.yaml mis à jour à votre cluster Autopilot pour installer Gatekeeper. Cela est nécessaire, car, par mesure de sécurité intégrée, Autopilot interdit les caractères génériques dans les webhooks d'admission avec mutation.

2. Déployez le modèle de contrainte (ConstraintTemplate) de type de volume de la règle de sécurité des pods intégrée :

   kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml
   

3. Enregistrez la contrainte suivante avec une liste de types de volumes autorisés sous le nom constraint.yaml :

   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: k8sPSPVolumeTypes
   metadata:
     name: nogcepersistentdisk
   spec:
     match:
       kinds:
         - apiGroups: [""]
           kinds: ["Pods"]
     parameters:
       volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]
   

   Cette contrainte restreint les volumes à la liste associée au champ spec.parameters.volumes.

4. Déployez la contrainte :

   kubectl apply -f constraint.yaml
   

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 Security Health Analytics.

Examiner les options par défaut sécurisées

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 d'un nœud

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é

Les points de terminaison du serveur de métadonnées Compute Engine v0.1 et v1beta1 sont obsolètes et ont été arrêtés le 30 septembre 2020. Ces points de terminaison n'appliquent pas les en-têtes de requêtes de métadonnées. Pour connaître le calendrier d'arrêt, consultez la page Abandon des points de terminaison du serveur de métadonnées v0.1 et v1beta1.

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 la fédération d'identité de charge de travail pour GKE ou la dissimulation de métadonnées.

Conserver les anciennes méthodes d'authentification client en mode inactif

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 auprès du 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, consultez la page Désactiver l'authentification avec un mot de passe statique.

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é

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 GKE Enterprise 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 acheminés de Cloud Logging vers vos propres systèmes de journalisation.

Conserver l'UI Web de Kubernetes (tableau de bord) en mode inactif

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 consoleGoogle Cloud 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

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.

Par défaut, ABAC est désactivé pour les clusters créés avec GKE version 1.8 ou ultérieure. 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. Le contrôle d'accès RBAC présente des avantages significatifs par rapport à la sécurité.

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

Laissez le contrôleur d'admission DenyServiceExternalIPs activé

Ne désactivez pas le contrôleur d'admission DenyServiceExternalIPs.

Le contrôleur d'admission DenyServiceExternalIPs empêche les services d'utiliser des adresses IP externes et limite une faille de sécurité connue.

Le contrôleur d'admission DenyServiceExternalIPs est activé par défaut sur les nouveaux clusters créés sur GKE 1.21 et versions ultérieures. Pour les clusters qui sont mis à jour vers GKE 1.21 ou versions ultérieures, vous pouvez activer le contrôleur d'admission à l'aide de la commande suivante :

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips

Étape suivante

• Apprenez-en davantage sur la sécurité de GKE dans la présentation des fonctionnalités de sécurité.
• Assurez-vous de bien comprendre le modèle de responsabilité partagée de GKE.
• Découvrez comment appliquer les benchmarks CIS GKE à votre cluster.
• Apprenez-en plus sur le contrôle des accès dans GKE.
• Consultez la présentation du réseau GKE.
• Consultez la présentation de l'architecture de cluster mutualisée de GKE.