Renforcer la sécurité d'un cluster

Ce document présente les bonnes pratiques pour améliorer la sécurité de vos environnements Google Kubernetes Engine (GKE). Les spécialistes de la sécurité qui définissent, régissent et mettent en œuvre des règles et des procédures peuvent utiliser ces bonnes pratiques pour protéger les données de leur organisation.

Vous devez déjà connaître les éléments suivants :

Les nouveaux clusters GKE mettent en œuvre par défaut la plupart des bonnes pratiques décrites dans ce document. Les clusters en mode Autopilot ont une posture de sécurité par défaut plus stricte que les clusters en mode Standard.

Pour implémenter et appliquer les bonnes pratiques de ce document dans votre organisation, pensez aux services suivants :

  • Security Command Center : vérifiez automatiquement si vos clusters mettent en œuvre la plupart de ces bonnes pratiques et recherchez d'autres erreurs de configuration courantes.
  • Service de règles d'administration : appliquez des bonnes pratiques spécifiques aux ressources GKE dans une organisation, un dossier ou un projet. Certaines sections de ce document contiennent des liens vers la console Google Cloud pour vous permettre d'appliquer des contraintes gérées à ces recommandations.

Conception de l'environnementGoogle Cloud

Les sections suivantes décrivent les mesures de sécurité à prendre en compte lorsque vous planifiez et concevez vos ressources dans Google Cloud. Les architectes cloud doivent suivre ces recommandations lorsqu'ils planifient et définissent l'architecture Google Cloud .

Bonnes pratiques

Planifier la structure de vos ressources Google Cloud

Recommandé : implémentez le plan de base d'entreprise, qui constitue une base complète pour votre environnement d'entreprise, basée sur nos bonnes pratiques.

L'architecture de vos organisations, dossiers et projets Google Cloud a une incidence sur votre niveau de sécurité. Concevez ces ressources de base de manière à permettre des contrôles de gouvernance et de sécurité à grande échelle dans vos services.

Planifier des environnements mutualisés

Recommandation : implémentez Google Cloud et les bonnes pratiques GKE pour les plates-formes d'entreprise multilocataires.

De nombreux clients GKE gèrent des équipes distribuées, avec des workflows et des responsabilités d'ingénierie distincts. Ces environnements mutualisés doivent disposer d'une infrastructure partagée que tous vos développeurs peuvent utiliser, tout en limitant l'accès aux composants en fonction des rôles et des responsabilités. Le plan d'application d'entreprise s'appuie sur le plan de base d'entreprise pour vous aider à déployer des plates-formes de développement internes dans des environnements mutualisés.

Pour en savoir plus, consultez les documents suivants :

Utiliser des tags pour regrouper les ressources Google Cloud

Recommandation : utilisez des tags pour organiser les ressources GKE afin d'appliquer des règles de manière conditionnelle et d'améliorer la responsabilité de vos équipes.

Les tags sont des métadonnées que vous pouvez associer aux ressources de vos organisations, dossiers et projets pour identifier les dimensions métier dans votre hiérarchie de ressourcesGoogle Cloud . Vous pouvez associer des tags à des clusters et des pools de nœuds GKE, puis les utiliser pour appliquer de manière conditionnelle des règles d'administration, des stratégies IAM ou des règles de pare-feu.

Pour en savoir plus, consultez les documents suivants :

Planifier vos réseaux VPC

Recommandation : implémentez Google Cloud et les bonnes pratiques GKE pour la conception de réseaux VPC.

La conception de votre réseau VPC et les fonctionnalités que vous utilisez ont un impact sur la sécurité de votre réseau. Planifiez vos réseaux en fonction de votre hiérarchie de ressources Google Cloudet de vos objectifs de sécurité. Pour en savoir plus, consultez les documents suivants :

Concevoir un plan de réponse aux incidents

Recommandation : créez et gérez un plan de réponse aux incidents qui répond à vos objectifs de sécurité et de fiabilité.

Des incidents de sécurité peuvent se produire même lorsque vous implémentez tous les contrôles de sécurité possibles. Un plan de réponse aux incidents vous aide à identifier les lacunes potentielles dans vos contrôles de sécurité, à répondre rapidement et efficacement à différents types d'incidents, et à réduire les temps d'arrêt en cas d'indisponibilité. Pour en savoir plus, consultez les documents suivants :

Google Cloud Sécurité du réseau

Les sections suivantes fournissent des recommandations de sécurité pour vos réseaux VPC. Les architectes et administrateurs réseau doivent appliquer ces recommandations pour réduire la surface d'attaque au niveau du réseau et limiter l'impact d'un accès réseau non souhaité.

Bonnes pratiques

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

Recommandation : lorsque vous créez des règles de pare-feu, utilisez le principe du moindre privilège pour ne fournir un accès qu'à l'objectif requis. Si possible, assurez-vous que vos règles de pare-feu n'entrent pas en conflit avec les règles de pare-feu par défaut de GKE et ne les remplacent pas.

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é. Si vous créez des règles de pare-feu permissives avec une priorité plus élevée qu'une règle de pare-feu par défaut (par exemple, une règle de pare-feu qui autorise tout le trafic entrant pour le débogage), votre cluster présente un risque d'accès inattendu.

Utiliser un VPC partagé pour le trafic entre projets

Recommandé : utilisez un VPC partagé pour permettre aux ressources de plusieurs projets de communiquer entre elles à l'aide d'adresses IP internes.

Les ressources de différents projets de votre organisation peuvent avoir besoin de communiquer entre elles. Par exemple, les services de frontend d'un cluster GKE dans un projet peuvent avoir besoin de communiquer avec des instances Compute Engine de backend dans un autre projet.

Pour en savoir plus, consultez les documents suivants :

Utiliser des réseaux distincts pour isoler les environnements

Recommandation : utilisez des réseaux VPC partagés distincts pour les environnements de préproduction, de test et de production.

Isolez vos environnements de développement les uns des autres pour réduire l'impact et le risque d'accès non autorisés ou de bugs perturbateurs. Pour en savoir plus, consultez Projets hôtes multiples.

Paramètres de sécurité immuables

Les sections suivantes fournissent des recommandations de sécurité que vous ne pouvez configurer que lorsque vous créez des clusters ou des pools de nœuds. Vous ne pouvez pas mettre à jour les clusters ou les pools de nœuds existants pour modifier ces paramètres. Les administrateurs de plate-forme doivent appliquer ces recommandations aux nouveaux clusters et pools de nœuds.

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

Recommandation : utilisez un compte de service IAM personnalisé pour vos clusters et pools de nœuds GKE au lieu 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. Au minimum, ces comptes de service de nœud doivent 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, en tant que compte de service de nœud.

Si vous utilisez le compte de service Compute Engine par défaut pour d'autres fonctions dans votre projet ou votre organisation, il est possible qu'il dispose de plus d'autorisations que nécessaire pour GKE, ce qui peut 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 appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.disallowDefaultComputeServiceAccount. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Utiliser une image de nœud Container-Optimized OS

Recommandation : sauf si vous avez une exigence spécifique pour utiliser Ubuntu ou Windows, utilisez l'image de nœud Container-Optimized OS pour vos nœuds.

Container-Optimized OS est conçu, optimisé et renforcé spécifiquement pour exécuter des conteneurs. Container-Optimized OS est la seule image de nœud compatible avec le mode Autopilot. Il s'agit également de l'image de nœud par défaut pour le mode Standard.

Pour en savoir plus, consultez les documents suivants :

Configuration de la sécurité des nœuds

Les sections suivantes fournissent des recommandations de sécurité pour la configuration des nœuds GKE. Les administrateurs de plate-forme et les ingénieurs en sécurité doivent appliquer ces recommandations pour améliorer l'intégrité de vos nœuds GKE.

Bonnes pratiques

Utiliser des nœuds GKE protégés

Recommandation : activez les nœuds GKE protégés, le démarrage sécurisé et la surveillance de l'intégrité dans tous les clusters et pools de nœuds.

Les nœuds GKE protégés fournissent des vérifications d'identité et d'intégrité vérifiables qui améliorent la sécurité de vos nœuds. Les nœuds GKE protégés et les fonctionnalités telles que la surveillance de l'intégrité des nœuds et le démarrage sécurisé sont toujours activés dans les clusters Autopilot. Dans les clusters standards, procédez comme suit :

  • Ne désactivez pas les nœuds GKE protégés dans vos clusters.
  • Activez le démarrage sécurisé dans tous vos pools de nœuds.
  • Ne désactivez pas la surveillance de l'intégrité dans vos pools de nœuds.

Pour savoir comment activer ces fonctionnalités, consultez Utiliser des nœuds GKE protégés.

Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.enableShieldedNodes. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

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

Recommandation : désactivez le port en lecture seule 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 en savoir plus, consultez Désactiver le port en lecture seule kubelet dans les clusters GKE.

Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.disableInsecureKubeletReadOnlyPort. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Contrôle des accès

Les sections suivantes fournissent des recommandations pour limiter l'accès non autorisé à votre cluster. Les ingénieurs en sécurité, ainsi que les administrateurs des identités et des comptes, doivent appliquer ces recommandations pour réduire votre surface d'attaque et limiter l'impact des accès non autorisés.

Bonnes pratiques

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

Recommandation : restreignez l'accès à votre plan de contrôle et à vos nœuds depuis Internet pour éviter tout accès non souhaité aux points de terminaison de découverte des API de cluster.

Par défaut, Kubernetes crée des clusters avec un ensemble permissif de rôles de découverte d'API par défaut. Ces rôles par défaut donnent un large accès aux informations sur les API d'un cluster à différents groupes par défaut, tels que system:authenticated. Ces rôles par défaut ne représentent pas un niveau de sécurité significatif pour les clusters GKE. Par exemple, le groupe system:authenticated, qui peut lire des informations sur les API telles que CustomResources, est attribué à tout utilisateur authentifié (y compris toute personne disposant d'un compte Google).

Pour restreindre l'accès aux API de découverte de votre cluster, procédez comme suit :

  • Limitez l'accès au plan de contrôle : utilisez uniquement le point de terminaison basé sur un DNS pour accéder au plan de contrôle. Si vous utilisez des points de terminaison basés sur des adresses IP, limitez l'accès à un ensemble de plages d'adresses connues en configurant des réseaux autorisés.
  • Configurer des nœuds privés : désactivez les adresses IP externes de vos nœuds afin que les clients en dehors de votre réseau ne puissent pas y accéder.

Pour en savoir plus, consultez À propos de l'isolation du réseau.

Si vous n'activez pas ces fonctionnalités d'isolation du réseau, traitez toutes les informations de découverte d'API (en particulier le schéma des CustomResources, les définitions d'APIService et les informations de découverte hébergées par des serveurs d'API d'extension) comme étant divulguées publiquement.

Placer les équipes et les environnements dans des espaces de noms ou des clusters distincts

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. Pour chaque espace de noms ou cluster, attribuez des centres de coûts et des libellés pour renforcer la responsabilisation et permettre le rejet de débit.

Vous pouvez utiliser des autorisations IAM et RBAC avec des espaces de noms pour limiter les interactions des utilisateurs avec les ressources du cluster sur la console Google Cloud . Pour en savoir plus, consultez Activer l'accès et afficher les ressources de cluster par espace de noms.

Utiliser le principe du moindre privilège dans les règles d'accès

Recommandation : n'accordez aux développeurs que l'accès dont ils ont besoin pour déployer et gérer les applications dans leur espace de noms, en particulier dans les environnements de production. Lorsque vous concevez vos stratégies de contrôle des accès, mappez les tâches que vos utilisateurs doivent effectuer dans le cluster et ne leur accordez que les autorisations qui leur permettent d'effectuer ces tâches.

Dans GKE, vous pouvez utiliser IAM et le contrôle des accès basé sur les rôles (RBAC) de Kubernetes pour accorder des autorisations sur les ressources. Ces mécanismes de contrôle des accès fonctionnent ensemble. Pour réduire la complexité de la gestion des accès, procédez comme suit :

  • Pour donner accès à votre projet ou à vos ressources Google Cloud , utilisez les rôles IAM.

  • Pour accorder l'accès aux ressources Kubernetes de votre cluster, comme les espaces de noms, utilisez RBAC.

Pour en savoir plus sur la planification et la conception des stratégies IAM et RBAC, consultez les documents suivants :

Utiliser la fédération d'identité de charge de travail pour GKE afin d'accéder aux API Google Cloud

Recommandation : pour accéder aux ressources Google Cloud à partir de vos charges de travail GKE, utilisez la fédération d'identité de charge de travail pour GKE.

La fédération d'identité de charge de travail pour GKE est la méthode recommandée pour s'authentifier auprès des APIGoogle Cloud . Vous pouvez accorder des rôles IAM sur différentes ressources aux comptes principaux de votre cluster, tels que des comptes de service ou des pods Kubernetes spécifiques. La fédération d'identité de charge de travail pour GKE protège également les métadonnées sensibles sur vos nœuds et fournit un workflow d'authentification plus sécurisé que les alternatives telles que les fichiers de jetons statiques.

La fédération d'identité de charge de travail pour GKE est toujours activée dans les clusters Autopilot. Dans les clusters Standard, activez la fédération d'identité de charge de travail pour GKE pour tous les clusters et pools de nœuds. Suivez également ces recommandations :

  • Si vous utilisez des bibliothèques clientes Google Cloud dans le code de votre application, ne distribuez pas les identifiants Google Cloud à vos charges de travail. Le code qui utilise des bibliothèques clientes récupère automatiquement les identifiants pour la fédération d'identité de charge de travail pour GKE.
  • Utilisez un espace de noms et un compte de service distincts pour chaque charge de travail nécessitant une identité distincte. Accorder des autorisations IAM à des comptes de service spécifiques.

Pour en savoir plus, consultez S'authentifier auprès des API Google Cloud à partir de charges de travail GKE.

Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.enableWorkloadIdentityFederation. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Utiliser des groupes pour gérer les accès

Recommandation : dans vos règles d'accès, accordez des autorisations à des groupes d'utilisateurs plutôt qu'à des personnes individuelles.

Lorsque vous gérez les utilisateurs dans des groupes, votre système de gestion des identités et vos administrateurs d'identité peuvent contrôler de manière centralisée les identités en modifiant l'appartenance des utilisateurs à différents groupes. Ce type de gestion évite de devoir mettre à jour vos stratégies RBAC ou IAM chaque fois qu'un utilisateur spécifique a besoin d'autorisations mises à jour.

Vous pouvez spécifier des groupes Google Groupes dans vos stratégies IAM ou RBAC. Pour en savoir plus, consultez les documents suivants :

Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.enableGoogleGroupsRBAC. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Limiter l'accès anonyme aux points de terminaison du cluster

Recommandé : empêchez les requêtes anonymes vers tous les points de terminaison du cluster, à l'exception des points de terminaison de vérification de l'état'état, dans tous les clusters Autopilot et Standard.

Par défaut, Kubernetes attribue l'utilisateur system:anonymous et le groupe system:unauthenticated aux requêtes anonymes adressées aux points de terminaison du cluster. Si vos règles RBAC accordent des autorisations supplémentaires à cet utilisateur ou à ce groupe, un utilisateur anonyme peut être en mesure de compromettre la sécurité d'un service ou du cluster lui-même.

Dans GKE version 1.32.2-gke.1234000 et versions ultérieures, vous pouvez limiter l'ensemble des points de terminaison auxquels les requêtes anonymes peuvent accéder aux points de terminaison de vérification de l'état du serveur d'API Kubernetes /healthz, /livez et /readyz. L'accès anonyme à ces points de terminaison de vérification de l'état'état est nécessaire pour vérifier qu'un cluster fonctionne correctement.

Pour limiter l'accès anonyme aux points de terminaison du cluster, spécifiez LIMITED pour l'option --anonymous-authentication-config lorsque vous utilisez la gcloud CLI ou l'API GKE pour créer ou mettre à jour des clusters Standard et Autopilot. Lors de l'authentification, GKE rejette les requêtes anonymes envoyées aux points de terminaison du cluster qui ne sont pas des points de terminaison de vérification de l'état. Les requêtes anonymes n'atteignent pas les points de terminaison, même si vos stratégies RBAC accordent l'accès aux utilisateurs et groupes anonymes. Les requêtes refusées renvoient un état HTTP 401.

Pour appliquer cette recommandation dans votre organisation, votre dossier ou votre projet à l'aide d'une règle d'administration, créez une contrainte personnalisée avec la condition resource.anonymousAuthenticationConfig.mode. Pour en savoir plus et obtenir un exemple de contrainte, consultez Limiter les actions sur les ressources GKE à l'aide de règles d'administration personnalisées.

Ne comptez pas uniquement sur cette fonctionnalité pour sécuriser votre cluster. Implémentez des mesures de sécurité supplémentaires, comme les suivantes :

Sécurité réseau GKE

Les sections suivantes fournissent des recommandations pour améliorer la sécurité réseau dans vos clusters. Les administrateurs réseau et les ingénieurs en sécurité doivent appliquer ces recommandations pour protéger les charges de travail et l'infrastructure contre les accès externes ou internes non souhaités.

Bonnes pratiques

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

Recommandation : activez le point de terminaison basé sur DNS pour l'accès au plan de contrôle et désactivez tous les points de terminaison du plan de contrôle basés sur une adresse IP.

Par défaut, les entités externes, telles que les clients sur Internet, peuvent accéder à votre plan de contrôle. Vous pouvez limiter l'accès à votre plan de contrôle en configurant l'isolation réseau.

Pour isoler votre plan de contrôle, effectuez l'une des opérations suivantes :

  • Utiliser uniquement le point de terminaison basé sur le DNS (recommandé) : activez le point de terminaison basé sur le DNS pour le plan de contrôle, et désactivez les points de terminaison internes et externes basés sur l'adresse IP. Tous les accès au plan de contrôle doivent utiliser le point de terminaison basé sur un DNS. Vous pouvez utiliser VPC Service Controls pour contrôler qui peut accéder au point de terminaison basé sur le DNS.

    Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.enableControlPlaneDNSOnlyAccess. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

    Accéder aux détails de la règle

  • Désactivez le point de terminaison externe basé sur l'adresse IP : supprimez l'adresse IP externe du plan de contrôle. Les clients qui ne se trouvent pas sur votre réseau VPC ne peuvent pas utiliser l'adresse IP externe pour accéder au plan de contrôle.

    Cette option est idéale si vous utilisez des technologies telles que Cloud Interconnect et Cloud VPN pour connecter le réseau de votre entreprise à votre réseau VPC.

  • Utiliser des réseaux autorisés avec le point de terminaison basé sur une adresse IP externe : limitez l'accès au point de terminaison basé sur une adresse IP externe à une plage d'adresses IP sources de confiance uniquement.

    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 accèdent à vos clusters via l'Internet public.

Dans la plupart des cas, n'utilisez que le point de terminaison basé sur le DNS pour accéder au plan de contrôle. Si vous devez activer le point de terminaison basé sur l'adresse IP, utilisez des réseaux autorisés pour limiter l'accès au plan de contrôle aux entités suivantes :

  • les plages d'adresses IP que vous spécifiez.
  • Nœuds GKE dans le même réseau VPC que le cluster.
  • Adresses IP réservées par Google à des fins de gestion des clusters.

Isoler vos nœuds d'Internet

Par défaut, tous les nœuds GKE disposent d'une adresse IP externe à laquelle les clients sur Internet peuvent accéder. Pour supprimer cette adresse IP externe, activez les nœuds privés.

Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.enablePrivateNodes. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Limiter le trafic réseau entre les pods

Recommandation : contrôlez le trafic réseau entre pods à l'aide de NetworkPolicies, d'un maillage de services ou des deux.

Par défaut, chaque pod de votre cluster peut communiquer avec tous les autres pods. Lorsque vous limitez l'accès réseau entre les services, il est beaucoup plus difficile pour les pirates informatiques de se déplacer latéralement dans votre cluster. Vos services bénéficient également d'une certaine protection contre les incidents de déni de service accidentels ou intentionnels. Selon vos besoins, utilisez l'une des méthodes suivantes ou les deux pour restreindre le trafic de pod à pod :

Protection des données sensibles

Les sections suivantes fournissent des recommandations pour chiffrer les données et protéger les informations sensibles telles que les identifiants. Les ingénieurs en sécurité et les administrateurs de plate-forme doivent appliquer ces recommandations pour réduire le risque d'accès non autorisé aux données critiques.

Bonnes pratiques

Chiffrer les données de charge de travail utilisées

Utilisez le chiffrement de la mémoire basé sur le matériel pour protéger les données utilisées par vos charges de travail à l'aide de nœuds Confidential GKE Node. Vous pouvez choisir une technologie de informatique confidentielle en fonction de vos besoins. Pour en savoir plus, consultez Chiffrer les données de charge de travail utilisées avec des nœuds de type Confidential GKE Node.

Stocker des secrets en dehors de votre cluster

Recommandé : utilisez un gestionnaire de secrets externe tel que Secret Manager pour stocker les données sensibles, telles que les clés API, en dehors de votre cluster.

Dans Kubernetes, vous pouvez stocker des données sensibles dans des secrets de votre cluster. Vous pouvez utiliser des secrets pour fournir des données confidentielles aux applications sans les inclure dans le code de l'application. Toutefois, le stockage de ces données dans votre cluster présente des risques, tels que les suivants :

  • Toute personne pouvant créer des pods dans un espace de noms peut lire les données de n'importe quel secret dans cet espace de noms.
  • Toute personne disposant d'un accès RBAC ou IAM en lecture à tous les objets de l'API Kubernetes peut lire les secrets.

En raison de ces risques, ne créez des secrets dans votre cluster que lorsque vous ne pouvez pas fournir ces données à vos charges de travail d'une autre manière. Nous vous recommandons les méthodes suivantes, par ordre de préférence, pour stocker vos données sensibles et y accéder :

  • Bibliothèques clientes Secret Manager : accédez aux secrets de manière programmatique à partir du code de votre application en utilisant l'API Secret Manager avec la fédération d'identité de charge de travail pour GKE. Pour en savoir plus, consultez Accéder aux secrets stockés en dehors des clusters GKE à l'aide de bibliothèques clientes.
  • Données Secret Manager en tant que volumes installés : fournissez des données sensibles à vos pods en tant que volumes installés à l'aide du module complémentaire Secret Manager pour GKE. Cette méthode est utile si vous ne pouvez pas modifier le code de votre application pour utiliser les bibliothèques clientes Secret Manager. Pour en savoir plus, consultez Utiliser le module complémentaire Secret Manager avec Google Kubernetes Engine.

  • Outils tiers de gestion des secrets : les outils tiers tels que HashiCorp Vault offrent des fonctionnalités de gestion des secrets pour les charges de travail Kubernetes. Ces outils nécessitent une configuration initiale plus importante que Secret Manager, mais constituent une option plus sécurisée que la création de secrets dans le cluster. Pour configurer un outil tiers de gestion des secrets, consultez la documentation du fournisseur. Tenez également compte des recommandations suivantes :

    • Si l'outil tiers s'exécute dans un cluster, utilisez un cluster différent de celui qui exécute vos charges de travail.
    • Utilisez Cloud Storage ou Spanner pour stocker les données de l'outil.
    • Utilisez un équilibreur de charge réseau passthrough interne pour exposer l'outil de gestion des secrets tiers aux pods qui s'exécutent dans votre réseau VPC.

  • Utiliser des secrets Kubernetes (non recommandé) : si aucune des options précédentes ne convient à votre cas d'utilisation, vous pouvez stocker les données en tant que secrets Kubernetes. Google Cloud chiffre les données au niveau du 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. Vous pouvez également chiffrer ces secrets au niveau de la couche d'application à l'aide d'une clé que vous gérez. Pour en savoir plus, consultez Chiffrer les secrets au niveau de la couche d'application.

Sécurité des charges de travail

Les sections suivantes fournissent des recommandations pour améliorer la sécurité de votre cluster contre les problèmes de charge de travail. Les ingénieurs en sécurité et les administrateurs de plate-forme doivent appliquer ces recommandations pour améliorer la protection de l'infrastructure GKE contre les charges de travail.

Bonnes pratiques

Isoler les charges de travail à l'aide de GKE Sandbox

Recommandation : utilisez GKE Sandbox 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. Comme décrit dans les bulletins de sécurité GKE, ce type d'attaque permet à un pirate informatique d'accéder à la VM hôte du conteneur. Le pirate informatique peut utiliser cet accès à l'hôte pour accéder à d'autres conteneurs sur la même VM. GKE Sandbox peut vous aider à limiter l'impact de ces attaques.

Utilisez GKE Sandbox dans les scénarios suivants :

  • Vous avez des charges de travail qui exécutent du code non approuvé.
  • Vous souhaitez limiter l'impact si un pirate informatique compromet un conteneur dans la charge de travail.

Pour en savoir plus, consultez Renforcer l'isolation d'une charge de travail avec GKE Sandbox.

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

Recommandation : utilisez des contrôleurs d'admission pour empêcher les charges de travail de se modifier elles-mêmes ou pour empêcher la modification d'attributs de charge de travail risqués tels que les comptes de service.

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, l'automodification 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 dans un espace de noms se modifie pour s'exécuter en tant que compte de service plus privilégié dans le même espace de noms.

Sauf si cela est nécessaire, n'autorisez pas les pods à se modifier eux-mêmes. Si certains pods doivent s'auto-modifier, utilisez Policy Controller pour limiter ce que les charges de travail peuvent modifier. Par exemple, vous pouvez utiliser le modèle de contrainte NoUpdateServiceAccount pour empêcher les pods de modifier leur compte de service. Lorsque vous créez une stratégie, excluez tous les composants de gestion de cluster de vos contraintes, comme dans l'exemple suivant :

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

Application des règles

Les sections suivantes fournissent des recommandations pour utiliser des règles afin d'appliquer des contraintes de sécurité sur plusieurs ressources. Les administrateurs d'identité et de compte, ainsi que les ingénieurs en sécurité, doivent appliquer ces recommandations pour assurer la conformité des clusters et des charges de travail avec les exigences de sécurité de l'organisation.

Bonnes pratiques

Appliquer des règles dans la hiérarchie des ressources Google Cloud

Recommandation : Pour appliquer des pratiques de sécurité dans votre organisation, votre dossier ou votre projet, utilisez le service de règles d'administration.

Les règles d'administration vous permettent de définir des contraintes de manière centralisée et de les appliquer à différents niveaux de votre hiérarchie des ressources. Divers produits Google Cloud publient des contraintes gérées qui vous permettent d'appliquer les recommandations de bonnes pratiques pour ce produit. Par exemple, GKE publie des contraintes gérées pour de nombreuses bonnes pratiques décrites dans ce document.

Pour savoir comment activer les règles d'administration, consultez Créer et gérer des règles d'administration.

Appliquer des règles lors de l'admission des charges de travail

Recommandation : utilisez un contrôleur d'admission tel que Policy Controller ou le contrôleur d'admission PodSecurity pour examiner les requêtes API entrantes et appliquer des règles à ces requêtes.

Les contrôleurs d'admission interceptent les requêtes authentifiées et autorisées adressées à l'API Kubernetes pour effectuer des tâches de validation ou de mutation avant d'autoriser la persistance d'une ressource dans l'API.

Vous pouvez utiliser les méthodes suivantes pour le contrôle des admissions dans les clusters GKE :

Gestion des clusters

Les sections suivantes fournissent des recommandations pour gérer vos clusters au fil du temps, comme la mise à niveau, la surveillance et la configuration des journaux. Les ingénieurs en sécurité, les administrateurs de plate-forme et les SRE doivent utiliser ces recommandations pour maintenir la stratégie de sécurité de la plate-forme GKE.

Bonnes pratiques

Mettre à niveau régulièrement votre infrastructure GKE

Recommandé : maintenez votre version GKE à jour pour accéder aux nouvelles fonctionnalités de sécurité et appliquer les correctifs de sécurité. Utilisez des versions disponibles, des mises à niveau automatiques accélérées des correctifs et des mises à niveau automatiques des nœuds.

Kubernetes et GKE publient fréquemment de nouvelles versions de correctifs qui incluent des améliorations de sécurité et des correctifs de failles. Pour tous les clusters, GKE met automatiquement à niveau le plan de contrôle vers des versions mineures et des versions de correctifs plus stables.

Pour vous assurer que votre cluster GKE exécute une version à jour, procédez comme suit :

  • Enregistrez vos clusters dans une version disponible. Les clusters Autopilot sont toujours enregistrés dans une version disponible.
  • Pour les clusters qui se trouvent dans un version disponible, activez les mises à niveau automatiques accélérées des correctifs afin d'obtenir les versions de correctifs de sécurité dès qu'elles sont disponibles dans votre canal de publication.
  • Pour les clusters standards qui ne sont pas dans un version disponible, activez les mises à niveau automatiques des nœuds. 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 GKE depuis le 11 novembre 2019.
  • Si vous utilisez des règles de maintenance, utilisez un intervalle de maintenance pour permettre à GKE de mettre à niveau automatiquement vos nœuds au moins une fois par mois.
  • Pour les pools de nœuds qui n'utilisent pas la mise à niveau automatique des nœuds, mettez-les à niveau au moins une fois par mois selon votre propre calendrier.
  • Consultez les bulletins de sécurité GKE et les notes de version GKE pour en savoir plus sur les correctifs de sécurité.

Activer les notifications concernant les bulletins de sécurité

Recommandé : configurez les notifications pour les nouveaux bulletins de sécurité qui affectent votre cluster.

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 recevoir des notifications dans Cloud Logging.

Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.enableSecurityBulletinNotifications. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Configurer la collecte de journaux

Recommandation : 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 sur l'ensemble de vos clusters. Ne désactivez pas la collecte de journaux dans vos clusters standards.

Les clusters GKE envoient des journaux spécifiques à Google Cloud Observability. Vous pouvez éventuellement configurer la collecte d'autres types de journaux. En plus des journaux système et de charge de travail, tous les clusters GKE envoient les journaux d'audit suivants à Logging :

  • Les journaux d'audit Kubernetes : enregistrement chronologique des appels passé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.
  • Journaux d'audit GKE : enregistrement des activités d'administration et d'accès pour l'API GKE.

Pour en savoir plus, consultez les documents suivants :

Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.enableCloudLogging. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Surveiller vos ressources pour détecter les problèmes de sécurité

Utilisez le tableau de bord de la posture de sécurité GKE et Security Command Center pour surveiller vos clusters et vos charges de travail afin de détecter d'éventuels problèmes. Vous pouvez utiliser ces services pour rechercher les failles, les menaces et les bulletins de sécurité actifs qui affectent votre infrastructure GKE.

Configurations de sécurité par défaut

Les sections suivantes décrivent les options qui sont configurées par défaut dans les nouveaux clusters pour atténuer des problèmes de sécurité spécifiques, comme les failles ou les risques. Les ingénieurs en sécurité et les administrateurs de plate-forme doivent vérifier que les clusters existants utilisent ces paramètres.

Bonnes pratiques

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

Recommandation : désactivez les anciennes méthodes d'authentification du serveur API, comme les certificats statiques et les mots de passe.

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 X.509. gcloud CLI utilise des jetons OAuth pour authentifier les utilisateurs pour GKE.

Les anciennes méthodes d'authentification, comme les mots de passe statiques, sont désactivées, car elles augmentent la surface d'attaque pour les compromissions de clusters. Dans les clusters Autopilot, vous ne pouvez pas activer ni utiliser ces méthodes d'authentification.

Utilisez l'une des méthodes suivantes pour vous authentifier auprès du serveur d'API Kubernetes :

  • Utilisateurs : utilisez gcloud CLI pour permettre à GKE d'authentifier les utilisateurs, de générer des jetons d'accès OAuth pour le cluster et de maintenir à jour ces jetons.
  • Applications : utilisez la fédération d'identité de charge de travail pour permettre aux applications dansGoogle Cloud ou dans d'autres environnements de s'authentifier auprès de votre cluster.

Pour en savoir plus sur l'authentification et sur la désactivation des anciennes méthodes d'authentification, consultez S'authentifier auprès du serveur d'API Kubernetes.

Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.disableLegacyClientCertificateIssuance. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Conserver ABAC en mode inactif

Recommandation : utilisez IAM et RBAC pour contrôler l'accès dans GKE. N'activez pas le contrôle des accès basé sur les attributs (ABAC).

ABAC est une ancienne méthode d'autorisation qui est désactivée par défaut dans tous les clusters GKE et qui ne peut pas être activée dans les clusters Autopilot.

Pour appliquer cette recommandation dans votre organisation, utilisez la contrainte de règle d'administration gérée constraints/container.managed.disableABAC. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Laisser le contrôleur d'admission DenyServiceExternalIPs activé

Recommandation : ne désactivez pas le contrôleur d'admission DenyServiceExternalIPs.

Ce contrôleur d'admission empêche les services d'utiliser des adresses IP externes et limite GCP-2020-015. Ce contrôleur d'admission est activé par défaut dans les clusters créés sur GKE 1.21 et versions ultérieures. Pour les clusters qui ont été créés à l'origine sur une version antérieure de GKE, activez le contrôleur d'admission :

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
Pour appliquer cette recommandation dans votre organisation, utilisez la constraints/container.managed.denyServiceExternalIPs contrainte de règle d'administration gérée. Pour examiner cette contrainte gérée dans la console Google Cloud , accédez à la page Détails de la règle.

Accéder aux détails de la règle

Étapes suivantes