À propos de l'isolation du réseau dans GKE

Vous pouvez personnaliser l'accès au réseau pour le plan de contrôle et les nœuds de votre cluster Google Kubernetes Engine (GKE) afin d'améliorer la sécurité du réseau pour le cluster et ses charges de travail. Ce document explique les différents types d'isolation que vous pouvez configurer pour votre cluster, les avantages de l'isolation de votre réseau et les limites à prendre en compte avant d'isoler votre cluster.

Pour configurer des niveaux d'isolation spécifiques pour votre cluster, consultez les documents suivants :

Bonne pratique :

Planifiez et concevez la configuration de l'isolation réseau avec les architectes réseau, les ingénieurs réseau et les administrateurs réseau de votre organisation, ou une autre équipe responsable de la définition, de l'implémentation et de la maintenance de l'architecture réseau.

Types d'accès au réseau

Les composants de votre cluster (plan de contrôle, serveur d'API et nœuds, par exemple) envoient et reçoivent du trafic réseau à différentes fins. Vous pouvez personnaliser l'isolation de votre cluster en contrôlant un ou plusieurs des types d'accès réseau suivants :

  • Accès au plan de contrôle depuis des sources externes : personnalisez les utilisateurs autorisés à accéder à votre plan de contrôle pour effectuer des tâches telles que l'exécution de commandes kubectl dans le cluster.
  • Accès aux webhooks externes depuis le serveur d'API : personnalisez la possibilité pour le serveur d'API Kubernetes d'envoyer du trafic directement aux serveurs de webhook externes via le plan de contrôle.
  • Accès aux nœuds depuis des sources externes : personnalisez l'accès de clients externes sur l'Internet public à vos nœuds.

Accès au plan de contrôle à partir de sources externes

Dans cette section, vous allez déterminer qui peut accéder à votre plan de contrôle.

Chaque cluster GKE dispose d'un plan de contrôle qui gère les requêtes de l'API Kubernetes. Le plan de contrôle s'exécute sur une machine virtuelle (VM) située dans un réseau VPC d'un projet géré par Google. Un cluster régional comporte plusieurs instances dupliquées du plan de contrôle, chacune s'exécutant sur sa propre VM. Les principaux, comme les administrateurs de cluster, utilisent un point de terminaison du plan de contrôle pour accéder au cluster et effectuer des tâches telles que l'exécution de commandes kubectl ou le déploiement de charges de travail. Le point de terminaison du plan de contrôle est utilisé par les clients externes pour accéder au cluster. Il n'est pas utilisé pour la communication directe avec les instances de VM Compute Engine qui hébergent les répliques du plan de contrôle. Le plan de contrôle comporte les types de points de terminaison suivants pour accéder au cluster :

Le plan de contrôle comporte deux types de points de terminaison pour l'accès au cluster :

  • Point de terminaison basé sur le DNS
  • Points de terminaison basés sur l'adresse IP
Bonne pratique :

Utilisez uniquement le point de terminaison basé sur le DNS pour accéder à votre plan de contrôle. Vous bénéficierez ainsi d'une configuration simplifiée et d'une couche de sécurité flexible basée sur des règles.

Point de terminaison basé sur le DNS

Le point de terminaison basé sur le DNS fournit un nom DNS ou un nom de domaine complet unique et immuable pour chaque plan de contrôle du cluster. Ce nom DNS peut être utilisé pour accéder à votre plan de contrôle pendant toute sa durée de vie. Le nom DNS est résolu en un point de terminaison accessible depuis n'importe quel réseau accessible par les API Google Cloud , y compris les réseaux sur site ou d'autres réseaux cloud. L'activation du point de terminaison basé sur le DNS élimine le besoin d'un hôte bastion ou de nœuds proxy pour accéder au plan de contrôle à partir d'autres réseaux VPC ou d'emplacements externes.

Pour accéder au point de terminaison du plan de contrôle, vous devez configurer des rôles et des règles IAM, ainsi que des jetons d'authentification. Pour en savoir plus sur les autorisations exactes requises, consultez Personnaliser l'isolation de votre réseau.

En plus des jetons et des stratégies IAM, vous pouvez également configurer les attributs d'accès suivants :

  • Contrôles basés sur les adresses IP ou le réseau avec VPC Service Controls : pour renforcer la sécurité du plan de contrôle de votre cluster GKE, VPC Service Controls ajoute une couche de sécurité d'accès supplémentaire. Il utilise l'accès contextuel basé sur des attributs tels que l'origine du réseau.

    VPC Service Controls n'est pas directement compatible avec les clusters dont le plan de contrôle utilise des adresses IP publiques. Toutefois, les clusters GKE, y compris les clusters privés et publics, sont protégés par VPC Service Controls lorsque vous y accédez à l'aide du point de terminaison basé sur le DNS.

    Vous configurez VPC Service Controls pour protéger le point de terminaison DNS de votre cluster GKE en incluant container.googleapis.com et kubernetesmetadata.googleapis.com dans la liste des services restreints de votre périmètre de service. L'ajout de ces API à votre périmètre de service activera VPC-SC pour toutes les opérations de l'API GKE. Cette configuration permet de s'assurer que les périmètres de sécurité que vous avez définis régissent l'accès au plan de contrôle.

    En utilisant à la fois des règles IAM et VPC Service Controls pour sécuriser l'accès au point de terminaison basé sur DNS, vous créez un modèle de sécurité multicouche pour le plan de contrôle de votre cluster. VPC Service Controls s'intègre aux services Google Cloud compatibles. Il aligne la configuration de sécurité de votre cluster sur les données que vous hébergez dans d'autres services Google Cloud .

  • Private Service Connect ou Cloud NAT : pour accéder au point de terminaison basé sur le DNS à partir de clients qui n'ont pas accès à l'Internet public. Par défaut, le point de terminaison basé sur le DNS est accessible via les API Google Clouddisponibles sur l'Internet public. Pour en savoir plus, consultez la section Point de terminaison basé sur le DNS sur la page "Personnaliser l'isolation de votre réseau".

  • Identifiants d'authentification Kubernetes : pour s'authentifier auprès du point de terminaison basé sur le DNS à l'aide de jetons de support Kubernetes ServiceAccount ou de certificats client X.509. Ces méthodes d'authentification sont désactivées par défaut dans les clusters GKE. Vous pouvez activer ces méthodes lorsque vous configurez le point de terminaison basé sur le DNS pour un cluster.

Points de terminaison basés sur l'adresse IP

Vous pouvez également configurer l'accès au plan de contrôle à l'aide de points de terminaison basés sur l'adresse IP.

Terminologie relative aux clusters et aux adresses IP

  • Google Cloud  adresses IP externes :

    • Les adresses IP externes attribuées à une VM utilisée par un client hébergé surGoogle Cloudappartiennent à Google Cloud . Pour en savoir plus, consultez Où puis-je trouver les plages d'adresses IP Compute Engine ?

    • Adresses IP externes utilisées par les produits Google Cloud tels que Cloud Run ou Cloud Run Functions. Tout client hébergé sur Google Cloud peut instancier ces adresses IP. Google Cloud est propriétaire de ces adresses IP.

  • Adresses IP réservées par Google : adresses IP externes à des fins de gestion des clusters GKE. Ces adresses IP incluent les processus gérés par GKE ainsi que d'autres services Google de production. Ces adresses IP appartiennent à Google.

  • Plages d'adresses IP du cluster GKE : adresses IP internes attribuées au cluster utilisé par GKE pour les nœuds, les pods et les services du cluster.

  • Adresses IP internes : adresses IP du réseau VPC de votre cluster. Ces adresses IP peuvent inclure l'adresse IP de votre cluster, les réseaux sur site, les plages RFC 1918 ou les adresses IP publiques utilisées en mode privé (PUPI) qui incluent des plages non-RFC 1918.

  • Point de terminaison du cluster basé sur une adresse IP externe : adresse IP du point de terminaison externe que GKE attribue au plan de contrôle.

  • Adresse IP externe de la VM du plan de contrôle : adresse IP externe attribuée à chaque instance de VM qui exécute le plan de contrôle et qui n'est utilisée que pour le trafic sortant du serveur d'API.

  • Point de terminaison interne : adresse IP interne que GKE attribue au plan de contrôle.

  • Réseau VPC : réseau virtuel dans lequel vous créez des sous-réseaux avec des plages d'adresses IP spécifiques aux nœuds et aux pods du cluster.

Lorsque vous utilisez des points de terminaison basés sur l'adresse IP, vous avez deux options :

  • Exposez le plan de contrôle sur les points de terminaison externes et internes. Cela signifie que le point de terminaison externe du plan de contrôle est accessible à partir d'une adresse IP externe, et que le point de terminaison interne est accessible à partir du réseau VPC de votre cluster. Les nœuds ne communiquent avec le plan de contrôle que sur le point de terminaison interne.

  • Exposez le plan de contrôle uniquement sur le point de terminaison interne. Cela signifie que les clients sur Internet ne peuvent pas se connecter au cluster et que le plan de contrôle est accessible depuis n'importe quelle adresse IP du réseau VPC de votre cluster. Les nœuds ne communiquent avec le plan de contrôle que sur le point de terminaison interne.

    Il s'agit de l'option la plus sécurisée lorsque vous utilisez des points de terminaison basés sur l'adresse IP, car elle empêche tout accès Internet au plan de contrôle. Il s'agit d'un bon choix si vous avez des charges de travail qui, par exemple, nécessitent un accès contrôlé en raison des réglementations de sécurité et de confidentialité des données.

Dans les deux options précédentes, vous pouvez restreindre les adresses IP qui atteignent les points de terminaison en configurant des réseaux autorisés. Si vous utilisez des points de terminaison basés sur des adresses IP, nous vous recommandons vivement d'ajouter au moins un réseau autorisé. Les réseaux autorisés accordent au plan de contrôle l'accès à un ensemble spécifique d'adresses IPv4 de confiance, et offrent une protection et des avantages supplémentaires en matière de sécurité pour votre cluster GKE.

Bonne pratique:

Activez les réseaux autorisés lorsque vous utilisez des points de terminaison basés sur des adresses IP pour sécuriser votre cluster GKE.

Fonctionnement des réseaux autorisés

Les réseaux autorisés fournissent un pare-feu basé sur l'adresse IP qui contrôle l'accès au plan de contrôle GKE. L'accès au plan de contrôle dépend des adresses IP sources. Lorsque vous activez les réseaux autorisés, vous configurez les adresses IP pour lesquelles vous souhaitez autoriser l'accès au point de terminaison du plan de contrôle du cluster GKE en tant que liste de blocs CIDR.

Le tableau suivant présente :

  • Adresses IP prédéfinies qui peuvent toujours accéder au plan de contrôle GKE, que vous activiez ou non les réseaux autorisés.
  • Adresses IP configurables pouvant accéder au plan de contrôle lorsque vous les ajoutez à la liste d'autorisation en activant les réseaux autorisés.
Points de terminaison du plan de contrôle Adresses IP prédéfinies qui peuvent toujours accéder aux points de terminaison Adresse IP configurable pouvant accéder aux points de terminaison après l'activation des réseaux autorisés
Points de terminaison externes et internes activés
  • Adresses IP réservées par Google
  • Plages d'adresses IP du cluster GKE
  • Adresses IP externes ajoutées à la liste d'autorisation
  • Adresses IP internes ajoutées à la liste d'autorisation
  • Google Cloud  adresses IP externes
Point de terminaison interne uniquement activé
  • Adresses IP réservées par Google
  • Plages d'adresses IP du cluster GKE
  • Adresses IP internes ajoutées à la liste d'autorisation.

Avec un réseau autorisé, vous pouvez également configurer la région à partir de laquelle une adresse IP interne peut atteindre le point de terminaison interne de votre plan de contrôle. Vous pouvez choisir d'autoriser l'accès uniquement à partir du réseau VPC du cluster ou à partir de n'importe quelle région Google Cloud dans un environnement VPC ou sur site.

Limites de l'utilisation de points de terminaison basés sur des adresses IP

  • Si vous développez un sous-réseau utilisé par un cluster avec des réseaux autorisés, vous devez mettre à jour la configuration de réseau autorisé pour inclure la plage d'adresses IP étendue.
  • Si des clients se connectent à partir de réseaux avec des adresses IP dynamiques, comme des employés sur des réseaux domestiques, vous devez mettre à jour fréquemment la liste des réseaux autorisés pour maintenir l'accès au cluster.
  • La désactivation de l'accès au point de terminaison externe du plan de contrôle vous empêche d'interagir à distance avec votre cluster. Si vous devez accéder au cluster à distance, vous devez utiliser un hôte bastion qui transfère le trafic client vers le cluster. En revanche, l'utilisation d'un point de terminaison basé sur le DNS ne nécessite que la configuration des autorisations IAM.
  • Les points de terminaison basés sur des adresses IP ne s'intègrent pas directement à VPC Service Controls. VPC Service Controls fonctionne au niveau du périmètre de service pour contrôler l'accès aux données et leur déplacement dans Google Cloud. Nous vous recommandons d'utiliser à la fois un point de terminaison basé sur le DNS et VPC Service Controls pour une défense robuste de la sécurité.
  • Vous pouvez spécifier jusqu'à 100 plages d'adresses IP autorisées (y compris les adresses IP externes et internes).

Accès aux sources externes depuis le serveur d'API

Le plan de contrôle du cluster GKE exécute des composants du plan de contrôle Kubernetes tels que le serveur d'API, le programmateur et les contrôleurs. Le plan de contrôle s'exécute sur une instance de VM Compute Engine appartenant à GKE dans un projet géré. Les clusters régionaux et Autopilot comportent plusieurs répliques du plan de contrôle, chacune s'exécutant sur sa propre instance de VM.

Par défaut, chacune de ces instances de VM Compute Engine possède une adresse IP externe qui lui est directement attribuée. Cette adresse IP n'est utilisée que pour envoyer des requêtes d'admission depuis le serveur d'API Kubernetes d'une instance vers des serveurs de webhook d'admission qui s'exécutent en dehors du cluster, par exemple dans un autre service cloud ou sur site. Cette adresse IP n'est utilisée que si les webhooks d'admission contactent directement le serveur de webhook à l'aide de l'URL ou de l'adresse IP du serveur.

Pour améliorer la sécurité de votre plan de contrôle, vous pouvez désactiver l'adresse IP externe sur vos instances de VM du plan de contrôle. En cas de piratage, les pirates potentiels ne peuvent pas utiliser ces adresses IP externes pour communiquer. Vous pouvez personnaliser le trafic de sortie du serveur d'API de différentes manières :

  • Aucun trafic sortant (NONE) : désactivez l'adresse IP externe de chaque instance de plan de contrôle et routez le trafic sortant du serveur d'API vers un trou noir. Tout le trafic sortant non critique du serveur d'API vers des destinations externes est bloqué, y compris le trafic vers les services Google Cloud en dehors du cluster. Cette option n'affecte pas le trafic système critique ni le trafic provenant de vos nœuds.
  • Tout le trafic sortant (VIA_CONTROL_PLANE) : conservez l'adresse IP externe de chaque instance de plan de contrôle et laissez le serveur d'API utiliser l'adresse IP pour le trafic sortant. Cette option est celle par défaut dans GKE.

Pour savoir comment personnaliser votre cluster pour l'une de ces options, consultez Restreindre le trafic sortant du serveur d'API.

Configuration de webhook externe

Lorsque vous définissez les restrictions de sortie du plan de contrôle sur NONE, le serveur d'API ne peut pas effectuer d'appels directs vers des adresses IP externes ni vers des noms de domaine complets (FQDN). Le paramètre NONE a les effets suivants sur les webhooks externes :

  • Dans la version 1.35.1-gke.1396000 et ultérieure, GKE empêche la création ou la mise à jour de ValidatingWebhookConfigurations ou de MutatingWebhookConfigurations qui utilisent le champ clientConfig.url.
  • Les configurations de webhook existantes qui utilisent le champ clientConfig.url pour contacter un serveur externe ne fonctionnent plus.

Pour créer et utiliser des serveurs de webhook externes, vous devez effectuer les opérations suivantes :

  1. Mettez à jour vos ValidatingWebhookConfigurations ou MutatingWebhookConfigurations pour utiliser le champ clientConfig.service. Ce champ permet au serveur d'API d'envoyer des requêtes à un point de terminaison de service, tel que my-webhook.default.svc, dans votre cluster. Ces requêtes ne sont pas bloquées, car le trafic se trouve dans le cluster. Pour en savoir plus, consultez la documentation de référence sur le service.

  2. Configurez le service pour acheminer le trafic vers votre serveur de webhook externe. Vous pouvez utiliser l'un des modèles de routage du trafic suivants, en fonction de vos exigences opérationnelles et de sécurité :

    • Pods de proxy : utilisez un déploiement ou un StatefulSet comme backend pour votre service. Configurez les pods pour qu'ils fonctionnent comme des proxys qui redirigent les requêtes d'admission entrantes vers votre serveur de webhook externe. Cette conception vous permet d'effectuer des tâches supplémentaires, comme inspecter et modifier les demandes d'admission.
    • EndpointSlices : créez le service sans sélecteur, puis ajoutez manuellement un EndpointSlice qui mappe le service à l'adresse IP du serveur de webhook externe. Cette conception achemine le trafic sans modifier les requêtes.

Lorsque vous concevez la configuration de votre webhook, tenez compte des facteurs suivants :

  • Authentification et identifiants : réfléchissez à la manière de vous authentifier auprès du serveur de webhook externe. Votre workflow de routage du trafic doit également gérer la manière dont les identifiants (tels que les clés API, les certificats mTLS et les jetons OAuth) sont appliqués aux connexions.
  • Contrôle de la sécurité et du réseau : tenez compte de la surface d'attaque de votre conception de routage et de vos options de sécurité et d'audit. La conception que vous implémentez affecte les contraintes que vous pouvez appliquer au trafic. Par exemple, vous pouvez utiliser NetworkPolicies avec des pods de proxy.
  • Observabilité et fiabilité : réfléchissez à la façon de surveiller les connexions. Par exemple, vous pouvez configurer des pods de proxy pour qu'ils émettent des métriques ou implémenter l'observabilité du réseau pour les EndpointSlices.

Accès aux nœuds à partir de sources externes

Cette section explique comment isoler les nœuds dans un cluster Kubernetes.

Activer les nœuds privés

Empêchez les clients externes d'accéder aux nœuds en ne provisionnant ces nœuds qu'avec des adresses IP internes, ce qui les rend privés. Les charges de travail exécutées sur des nœuds sans adresse IP externe ne peuvent pas accéder à Internet, sauf si NAT est activé sur le réseau du cluster. Vous pouvez modifier ces paramètres à tout moment.

Vous pouvez activer les nœuds privés au niveau d'un cluster individuel, ou au niveau du pool de nœuds (pour les clusters Standard) ou de la charge de travail (pour les clusters Autopilot). L'activation des nœuds privés au niveau du pool de nœuds ou de la charge de travail remplace toute configuration de nœud au niveau du cluster.

Si vous mettez à jour un pool de nœuds public en mode privé, les charges de travail nécessitant un accès en dehors du réseau du cluster peuvent échouer dans les scénarios suivants :

  • Clusters d'un réseau VPC partagé où l'accès privé à Google n'est pas activé. Activez manuellement l'accès privé à Google pour vous assurer que GKE télécharge l'image de nœud attribuée. Pour les clusters qui ne font pas partie d'un réseau VPC partagé, GKE active automatiquement l'accès privé à Google.

  • Les charges de travail qui nécessitent un accès à Internet lorsque Cloud NAT n'est pas activé ou pour lesquelles aucune solution NAT personnalisée n'est pas définie. Pour autoriser le trafic sortant vers Internet, activez Cloud NAT ou une solution NAT personnalisée.

Que vous activiez ou non les nœuds privés, le plan de contrôle communique toujours avec l'ensemble des nœuds uniquement via des adresses IP internes.

Avantages de l'isolation réseau

Voici les avantages de l'isolation réseau :

  • Flexibilité :

    • Les clusters disposent d'une configuration unifiée et flexible. Les clusters avec ou sans points de terminaison externes partagent la même architecture et sont compatibles avec les mêmes fonctionnalités. Vous pouvez sécuriser l'accès en fonction des contrôles et des bonnes pratiques qui répondent à vos besoins. Toutes les communications entre les nœuds de votre cluster et le plan de contrôle utilisent une adresse IP interne.
    • Vous pouvez modifier les paramètres d'accès au plan de contrôle et de configuration des nœuds de cluster à tout moment, sans avoir à recréer le cluster.
    • Vous pouvez choisir d'activer le point de terminaison externe du plan de contrôle si vous devez gérer votre cluster depuis n'importe quel emplacement disposant d'un accès à Internet, ou depuis des réseaux ou des appareils qui ne sont pas directement connectés à votre VPC. Vous pouvez également désactiver le point de terminaison externe pour renforcer la sécurité si vous devez maintenir l'isolation du réseau pour les charges de travail sensibles. Dans les deux cas, vous pouvez utiliser des réseaux autorisés pour limiter l'accès aux plages d'adresses IP de confiance.

  • Sécurité :

    • Les points de terminaison basés sur le DNS avec VPC Service Controls fournissent un modèle de sécurité multicouche qui protège votre cluster contre les réseaux non autorisés et les identités non autorisées accédant au plan de contrôle. VPC Service Controls s'intègre à Cloud Audit Logs pour surveiller l'accès au plan de contrôle.
    • Les nœuds privés et les charges de travail qui y sont exécutées ne sont pas directement accessibles depuis l'Internet public, ce qui réduit considérablement le risque d'attaques externes sur votre cluster.
    • Vous pouvez bloquer l'accès au plan de contrôle depuis des Google Cloud adresses IP externes ou depuis des adresses IP externes afin d'isoler complètement le plan de contrôle du cluster et de réduire l'exposition aux menaces de sécurité potentielles.
    • Vous pouvez désactiver les adresses IP externes de vos instances de VM de plan de contrôle pour empêcher les pirates informatiques de les utiliser.

  • Conformité : si vous travaillez dans un secteur soumis à des réglementations strictes concernant l'accès aux données et leur stockage, les nœuds privés vous aident à respecter la conformité en veillant à ce que les données sensibles restent dans votre réseau privé.

  • Contrôle : les nœuds privés vous permettent de contrôler précisément le flux de trafic entrant et sortant de votre cluster. Vous pouvez configurer des règles de pare-feu et des stratégies réseau pour autoriser uniquement les communications autorisées. Si vous travaillez dans des environnements multicloud, les nœuds privés peuvent vous aider à établir une communication sécurisée et contrôlée entre différents environnements.

  • Coût : en activant les nœuds privés, vous pouvez réduire les coûts pour les nœuds qui n'ont pas besoin d'adresse IP externe pour accéder aux services publics sur Internet.

Étapes suivantes