Règles de pare-feu créées automatiquement

Cette page décrit les règles de pare-feu VPC d'autorisation d'entrée que Google Kubernetes Engine (GKE) crée automatiquement par défaut dans Google Cloud.

Pare-feu applicables et pare-feu de sortie

GKE utilise des règles de pare-feu de cloud privé virtuel (VPC) pour contrôler le trafic entrant et sortant vers vos pods et nœuds. Par défaut, GKE crée et gère automatiquement certaines règles de pare-feu pour autoriser le trafic essentiel, comme la communication entre les nœuds et les pods, et le trafic vers votre plan de contrôle Kubernetes. Bien que GKE crée automatiquement des règles de pare-feu VPC d'autorisation d'entrée pour les services LoadBalancer par défaut, vous pouvez désactiver ce comportement pour gérer manuellement les règles ou les stratégies de pare-feu, ou utiliser des fonctionnalités de pare-feu avancées.

Les règles de pare-feu d'autorisation d'Ingress créées par GKE ne sont pas les seules règles de pare-feu applicables aux nœuds d'un cluster. L'ensemble complet des règles de pare-feu applicables pour l'entrée et la sortie est défini à partir des règles des stratégies de pare-feu hiérarchiques, des stratégies de pare-feu réseau mondiales, des stratégies de pare-feu réseau régionales et d'autres règles de pare-feu VPC.

Bonne pratique:

Planifiez et concevez la configuration de votre cluster, de vos charges de travail et de vos services avec les administrateurs réseau et les ingénieurs de sécurité de votre organisation. Comprenez la politique et l'ordre d'évaluation des règles du pare-feu afin de savoir quelles règles de pare-feu ont la priorité.

GKE ne crée que des règles de pare-feu VPC d'entrée, car il s'appuie sur la règle de pare-feu d'autorisation implicite de sortie de la plus basse priorité.

Si vous avez configuré des règles de pare-feu de refus de sortie sur le réseau VPC de votre cluster, vous devrez peut-être créer des règles d'autorisation de sortie pour autoriser la communication entre les nœuds, les pods et le plan de contrôle du cluster. Par exemple, si vous avez créé une règle de pare-feu de refus de sortie pour tous les protocoles et ports, ainsi que pour toutes les adresses IP de destination, vous devez créer des règles de pare-feu autorisant le trafic sortant en plus des règles d'entrée créées automatiquement par GKE. La connectivité aux points de terminaison du plan de contrôle utilise toujours le port de destination TCP 443, mais la connectivité entre les nœuds et les pods du cluster peut utiliser n'importe quel protocole et port de destination.

Les outils suivants sont utiles pour déterminer quelles règles de pare-feu autorisent ou refusent le trafic:

Règles de pare-feu

Par défaut, GKE crée automatiquement des règles de pare-feu lors de la création des ressources suivantes:

  • Clusters GKE
  • Services GKE
  • Passerelles GKE et HTTPRoutes
  • Ingress GKE

Sauf indication contraire, la priorité de toutes les règles de pare-feu créées automatiquement est de 1 000, qui est la valeur par défaut des règles de pare-feu. Si vous souhaitez mieux contrôler le comportement du pare-feu, vous pouvez créer des règles de pare-feu avec une priorité plus élevée. Les règles de pare-feu de priorité supérieure sont appliquées avant les règles de pare-feu créées automatiquement.

Règles de pare-feu de cluster GKE

GKE crée les règles de pare-feu d'entrée suivantes lors de la création d'un cluster :

Nom Objectif Source Cible (définit la destination) Protocole et ports Priorité
gke-[cluster-name]-[cluster-hash]-master Pour les clusters Autopilot et Standard qui s'appuient sur l' appairage de réseaux VPC pour la connectivité des points de terminaison privés du plan de contrôle. Autorise le plan de contrôle à accéder à Kubelet et metrics-server sur les nœuds du cluster. Plage d'adresses IP du plan de contrôle (/28) Tag du nœud TCP : 443 (metrics-server) et TCP : 10250 (kubelet) 1000
gke-[cluster-name]-[cluster-hash]-vms

Utilisé pour la communication au sein du cluster requise par le modèle de mise en réseau Kubernetes. Permet au logiciel s'exécutant sur les nœuds d'envoyer des paquets, avec des sources correspondant aux adresses IP des nœuds, vers l'adresse IP du pod de destination et les adresses IP des nœuds du cluster. Par exemple, le trafic autorisé par cette règle inclut les éléments suivants :

  • Paquets envoyés depuis des daemons système, tels que le kubelet, aux destinations d'adresses IP de nœud et de pod du cluster.
  • Paquets envoyés depuis un logiciel s'exécutant dans des pods avec hostNetwork:true aux adresses IP de nœud et de pod du cluster.
Plage d'adresses IP du nœud ou sur-ensemble de cette plage :
  • Pour les réseaux VPC en mode automatique, GKE utilise le CIDR 10.128.0.0/9, car cette plage inclut toutes les plages d'adresses IPv4 principales actuelles et futures du sous-réseau pour les sous-réseaux créés automatiquement.
  • Pour les réseaux VPC en mode personnalisé, GKE utilise la plage d'adresses IPv4 principale du sous-réseau du cluster.
GKE ne met pas à jour la plage IPv4 source de cette règle de pare-feu si vous étendez la plage IPv4 principale du sous-réseau du cluster. Vous devez créer la règle de pare-feu d'entrée nécessaire manuellement si vous étendez la plage IPv4 principale du sous-réseau du cluster. 		Tag du nœud TCP : 1-65535, UDP : 1-65535, ICMP 1000
gke-[cluster-name]-[cluster-hash]-all Autorise le trafic entre tous les pods d'un cluster, selon les exigences du modèle de mise en réseau Kubernetes.

CIDR des pods

Pour les clusters comprenant un CIDR multipods non contigu activé, tous les blocs CIDR des pods sont utilisés par le cluster.

Tag du nœud TCP, UDP, SCTP, ICMP, ESP, AH 1000
gke-[cluster-hash]-ipv6-all Pour les clusters de réseaux à double pile uniquement. Autorise le trafic entre les nœuds et les pods d'un cluster.

Plage d'adresses IP identique allouée dans subnetIpv6CidrBlock.

Tag du nœud TCP, UDP, SCTP, ICMP pour IPv6, ESP, AH 1000
gke-[cluster-name]-[cluster-hash]-inkubelet Autorise l'accès au port 10255 (port Kubelet en lecture seule) depuis les CIDR de pods internes et les CIDR de nœuds dans les nouveaux clusters GKE exécutant la version 1.23.6 ou ultérieure. Les clusters exécutant des versions ultérieures à la version 1.26.4-gke.500 utilisent le port authentifié Kubelet (10250) à la place. N'ajoutez pas de règles de pare-feu bloquant le port 10250 au sein du cluster.

CIDR de pods internes et CIDR de nœuds.

Tag du nœud TCP : 10255 999
gke-[cluster-name]-[cluster-hash]-exkubelet Refuse l'accès public au port 10255 dans les nouveaux clusters GKE exécutant la version 1.23.6 ou ultérieure.

0.0.0.0/0

Tag du nœud TCP : 10255 1000

Règles de pare-feu de service GKE

GKE crée les règles de pare-feu d'entrée suivantes lors de la création d'un service. Vous pouvez empêcher la création de certaines de ces règles de pare-feu en gérant la création de règles de pare-feu VPC.

Nom Objectif Source Cible (définit la destination) Protocole et ports
k8s-fw-[loadbalancer-hash] Autorise le trafic entrant à accéder à un service. La source provient de spec.loadBalancerSourceRanges. La valeur par défaut est 0.0.0.0/0 si spec.loadBalancerSourceRanges est omis.

Pour en savoir plus, consultez la section Règles de pare-feu et liste d'autorisation d'adresses IP sources.

 Adresse IP virtuelle LoadBalancer TCP et UDP sur les ports spécifiés dans le fichier manifeste du service.
k8s-[cluster-id]-node-http-hc Autorise les vérifications de l'état d'un service d'équilibreur de charge réseau passthrough externe lorsque externalTrafficPolicy est défini sur Cluster.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Adresse IP virtuelle LoadBalancer TCP : 10256
k8s-[loadbalancer-hash]-http-hc Autorise les vérifications de l'état d'un service d'équilibreur de charge réseau passthrough externe lorsque externalTrafficPolicy est défini sur Local.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Tag du nœud Port TCP défini par spec.healthCheckNodePort. Si aucune valeur n'est spécifiée, le plan de contrôle Kubernetes attribue un port de vérification de l'état à partir de la plage de ports du nœud.

Pour en savoir plus, consultez la section Port de vérification de l'état.
k8s-[cluster-id]-node-hc Autorise les vérifications de l'état d'un service d'équilibreur de charge réseau passthrough interne lorsque externalTrafficPolicy est défini sur Cluster.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Tag du nœud TCP : 10256
[loadbalancer-hash]-hc Autorise les vérifications de l'état d'un service d'équilibreur de charge réseau passthrough interne lorsque externalTrafficPolicy est défini sur Local.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Tag du nœud Port TCP défini par spec.healthCheckNodePort. Si aucune valeur n'est spécifiée, le plan de contrôle Kubernetes attribue un port de vérification de l'état à partir de la plage de ports du nœud.

Pour en savoir plus, consultez la section Port de vérification de l'état.
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] Autorise le trafic entrant à accéder à un Service lorsque l'un des éléments suivants est activé :
  • Sous-paramètre GKE.
  • Équilibreur de charge réseau passthrough externe basé sur un service de backend.
  • Vous pouvez désactiver la création automatique de ces règles de pare-feu VPC. Pour en savoir plus, consultez la section Gérer la création automatique de règles de pare-feu.
    		•  La source provient de spec.loadBalancerSourceRanges. La valeur par défaut est 0.0.0.0/0 si spec.loadBalancerSourceRanges est omis.

    Pour en savoir plus, consultez la section Règles de pare-feu et liste d'autorisation d'adresses IP sources.

    		 Adresse IP virtuelle LoadBalancer TCP et UDP sur les ports spécifiés dans le fichier manifeste du service.
    k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw Autorise les vérifications d'état du Service lorsque externalTrafficPolicy est défini sur Local et que l'un des éléments suivants est activé :
  • Sous-paramètre GKE.
  • Équilibreur de charge réseau passthrough externe basé sur un service de backend.
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 Adresse IP virtuelle LoadBalancer Port TCP défini par spec.healthCheckNodePort. Si aucune valeur n'est spécifiée, le plan de contrôle Kubernetes attribue un port de vérification de l'état à partir de la plage de ports du nœud.

    Pour en savoir plus, consultez la section Port de vérification de l'état.
    k8s2-[cluster-id]-l4-shared-hc-fw Autorise les vérifications d'état du Service lorsque externalTrafficPolicy est défini sur Cluster et que l'un des éléments suivants est activé :
  • Sous-paramètre GKE.
  • Équilibreur de charge réseau passthrough externe basé sur un service de backend.
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 Tag du nœud TCP : 10256
    gke-[cluster-name]-[cluster-hash]-mcsd Autorise le plan de contrôle à accéder au kubelet ainsi qu'à metrics-server sur les nœuds de cluster pour les services multiclusters. Cette règle a une priorité de 900. Adresses IP de vérification d'état Tag du nœud TCP, UDP, SCTP, ICMP, ESP, AH

    Règles de pare-feu de passerelle GKE

    GKE crée les règles de pare-feu de passerelle suivantes lors de la création de ressources Gateway et HTTPRoute :

    Nom Objectif Source Cible (définit la destination) Protocole et ports
    • gkegw1-l7-[network]-[region/global]
    • gkemcg1-l7-[network]-[region/global]

    Autorise les vérifications d'état d'un groupe de points de terminaison du réseau (NEG).

    Le contrôleur Gateway crée cette règle lors de la création de la première ressource Gateway. Le contrôleur Gateway peut mettre à jour cette règle si d'autres ressources Gateway sont créées.

    		Tag du nœud TCP : tous les ports cibles de conteneurs (pour les NEG)

    Règles de pare-feu d'Ingress GKE

    GKE crée les règles de pare-feu d'entrée suivantes lors de la création d'une ressource Ingress :

    Nom Objectif Source Cible (définit la destination) Protocole et ports
    k8s-fw-l7-[random-hash]

    Autorise les vérifications d'état d'un service NodePort ou d'un groupe de points de terminaison du réseau (NEG).

    Le contrôleur Ingress crée cette règle lors de la création de la première ressource Ingress. Le contrôleur Ingress peut mettre à jour cette règle si d'autres ressources Ingress sont créées.

    		Pour GKE v1.17.13-gke.2600 ou version ultérieure :
    • 130.211.0.0/22
    • 35.191.0.0/16
    • Plages de sous-réseaux proxy réservés définies par l'utilisateur (pour les équilibreurs de charge d'application internes)
    		 Tag du nœud TCP : 30000-32767, TCP : 80 (pour les équilibreurs de charge d'application internes), TCP : tous les ports cibles de conteneurs (pour les NEG)

    Gérer la création de règles de pare-feu VPC

    Par défaut, GKE crée automatiquement des règles de pare-feu VPC d'autorisation d'entrée pour tous les services LoadBalancer. Si vous souhaitez gérer vous-même les règles de pare-feu pour les services LoadBalancer, vous devez désactiver la création automatique de règles de pare-feu VPC.

    La désactivation de la création automatique de règles de pare-feu VPC pour les services LoadBalancer ne s'applique qu'aux éléments suivants:

    Pour savoir comment désactiver les règles de pare-feu, consultez la section Règles de pare-feu gérées par l'utilisateur pour les services LoadBalancer GKE.

    VPC partagé

    Si vous utilisez des services Ingress ou LoadBalancer, et que vous disposez d'un cluster situé dans un VPC partagé utilisant un réseau VPC partagé, le compte de service GKE du projet de service ne peut pas créer ni mettre à jour des règles de pare-feu autorisant les entrées dans le projet hôte. Vous pouvez accorder au compte de service GKE dans un projet de service les autorisations nécessaires pour créer et gérer les ressources de pare-feu. Pour en savoir plus, consultez la section VPC partagé.

    Règle de pare-feu requise pour le sous-réseau étendu

    Si vous étendez la plage IPv4 principale du sous-réseau du cluster, GKE ne met pas automatiquement à jour la plage source de la règle de pare-feu gke-[cluster-name]-[cluster-hash]-vms. Étant donné que les nœuds du cluster peuvent recevoir des adresses IPv4 de la partie développée de la plage IPv4 principale du sous-réseau, vous devez créer une règle de pare-feu manuellement pour autoriser la communication entre les nœuds du cluster.

    La règle de pare-feu d'entrée que vous devez créer doit autoriser les paquets TCP et ICMP depuis la plage source IPv4 du sous-réseau principal étendu, et cette règle doit s'appliquer au moins à tous les nœuds du cluster.

    Pour créer une règle de pare-feu d'entrée qui ne s'applique qu'aux nœuds du cluster, définissez la cible de la règle de pare-feu sur le même tag cible que celui utilisé par la règle de pare-feu gke-[cluster-name]-[cluster-hash]-vms créée automatiquement par votre cluster.

    Étapes suivantes