Présentation des règles de pare-feu VPC

Les règles de pare-feu de cloud privé virtuel (VPC) s'appliquent à un projet et à un réseau donnés. Si vous souhaitez appliquer des règles de pare-feu à plusieurs réseaux VPC dans une organisation, consultez la section Règles de pare-feu. Le reste de cette page ne couvre que les règles de pare-feu VPC.

Les règles de pare-feu VPC vous permettent d'autoriser ou de refuser les connexions vers ou depuis vos instances de machines virtuelles (VM) en fonction d'une configuration spécifiée. Les règles de pare-feu VPC activées sont toujours appliquées, protégeant vos instances quels que soient leur configuration et leur système d'exploitation, même si elles n'ont pas encore démarré.

Chaque réseau privé virtuel (VPC) fonctionne comme un pare-feu distribué. Alors que les règles de pare-feu sont définies au niveau du réseau, les connexions sont autorisées ou interdites pour chaque instance. Vous pouvez considérer que les règles de pare-feu VPC existent non seulement entre vos instances et les autres réseaux, mais également entre les instances individuelles d'un même réseau.

Pour obtenir plus d'informations sur les pare-feu, consultez la page Pare-feu (informatique).

Règles de pare-feu dans Google Cloud

Lorsque vous créez une règle de pare-feu VPC, vous spécifiez un réseau VPC et un ensemble de composants définissant son rôle. Les composants vous permettent de cibler certains types de trafic en fonction du protocole, des ports de destination, des sources et des destinations. Pour en savoir plus, consultez la section Composants des règles de pare-feu.

Vous pouvez créer ou modifier des règles de pare-feu VPC à l'aide de Google Cloud Console, de l'outil de ligne de commande gcloud et de l'API REST. Lorsque vous créez ou modifiez une règle de pare-feu, vous pouvez spécifier les instances auxquelles elle doit être appliquée à l'aide du composant cible de la règle.

Outre les règles de pare-feu que vous créez, Google Cloud dispose d'autres règles pouvant affecter les connexions entrantes (entrée) et sortantes (sortie) :

  • Google Cloud n'autorise pas certains protocoles IP, tels que le trafic de sortie sur le port TCP 25, au sein d'un réseau VPC. Pour en savoir plus, consultez la section Trafic toujours bloqué.

  • Google Cloud autorise toujours la communication entre une instance de VM et le serveur de métadonnées correspondant à l'adresse 169.254.169.254. Pour en savoir plus, consultez la section Trafic toujours autorisé.

  • Chaque réseau comporte deux règles de pare-feu implicites qui autorisent les connexions sortantes et bloquent les connexions entrantes. Les règles de pare-feu que vous créez peuvent remplacer ces règles implicites.

  • Le réseau par défaut est prérempli avec des règles de pare-feu que vous pouvez supprimer ou modifier.

Spécifications

Les règles de pare-feu VPC présentent les caractéristiques suivantes :

  • Chaque règle de pare-feu s'applique soit aux connexions entrantes (entrée), soit aux connexions sortantes (sortie), mais pas aux deux. Pour en savoir plus, consultez la section Sens du trafic.

  • Les règles de pare-feu sont compatibles avec les connexions IPv4. Les connexions IPv6 sont également acceptées dans les réseaux VPC pour lesquels IPv6 est activé. Lorsque vous spécifiez une source pour une règle d'entrée ou une destination pour une règle de sortie par adresse, vous pouvez spécifier des blocs ou des adresses IPv4 ou IPv6 au format CIDR.

  • Chaque règle de pare-feu peut contenir des plages IPv4 ou IPv6, mais pas les deux.

  • L'action de chaque règle de pare-feu est soit allow, soit deny. La règle s'applique aux connexions tant qu'elle est activée. Par exemple, vous pouvez désactiver une règle à des fins de dépannage.

  • Lorsque vous créez une règle de pare-feu, vous devez sélectionner un réseau VPC. Alors que la règle est appliquée au niveau de l'instance, sa configuration est associée à un réseau VPC. Cela signifie que vous ne pouvez pas partager les règles de pare-feu entre les réseaux VPC, y compris les réseaux connectés via l'appairage de réseaux VPC ou à l'aide de tunnels Cloud VPN.

  • Les règles de pare-feu VPC sont dites avec état.

    • Lorsqu'une connexion est autorisée via le pare-feu dans un sens, le trafic retour correspondant à cette connexion est également autorisé. Vous ne pouvez pas configurer une règle de pare-feu pour refuser le trafic de réponse associé.
    • Le trafic retour doit correspondre aux cinq tuples (adresse IP source, adresse IP de destination, port source, port de destination et protocole) du trafic de requête accepté, mais avec les adresses et les ports sources et de destination inversés.
    • Google Cloud associe les paquets entrants aux paquets sortants correspondants à l'aide d'une table de suivi des connexions.
    • Google Cloud met en œuvre le suivi des connexions, que le protocole soit compatible ou non avec les connexions. Si une connexion est autorisée entre une source et une cible (pour une règle d'entrée), ou une cible et une destination (pour une règle de sortie), l'intégralité du trafic de réponse est autorisée aussi longtemps que l'état de suivi des connexions du pare-feu reste actif. L'état de suivi d'une règle de pare-feu est considéré comme actif si au moins un paquet est envoyé toutes les 10 minutes.
    • Le trafic de réponse ICMP (tel que "ICMP TYPE 3, DESTINATION UNREACHABLE") généré en réponse à une connexion TCP/UDP autorisée est autorisé via le pare-feu. Ce comportement est conforme à la norme RFC 792.
  • Les règles de pare-feu VPC ne rassemblent pas les paquets TCP fragmentés. Par conséquent, une règle de pare-feu applicable au protocole TCP ne peut s'appliquer qu'au premier fragment, car celui-ci contient l'en-tête TCP. Les règles de pare-feu applicables au protocole TCP ne s'appliquent pas aux fragments TCP ultérieurs.

  • Le nombre maximal de connexions suivies dans la table des règles de pare-feu dépend du nombre de connexions avec état compatibles avec le type de machine de l'instance. Si le nombre maximal de connexions suivies est dépassé, le suivi est arrêté pour les connexions dont l'intervalle d'inactivité est le plus long pour permettre le suivi des nouvelles connexions.

    Type de machine de l'instance Nombre maximal de connexions avec état
    Types de machines à cœur partagé 130 000
    Instances avec 1 à 8 processeurs virtuels 130 000 connexions par processeur virtuel
    Instances avec plus de 8 processeurs virtuels 1 040 000 (130 000 × 8) connexions au total

Règles implicites

Chaque réseau VPC possède deux règles de pare-feu IPv4 implicites. Si IPv6 est activé dans un réseau VPC, ce réseau a également deux règles de pare-feu IPv6 implicites. Ces règles ne sont pas affichées dans Cloud Console.

Les règles de pare-feu implicites sont présentes dans tous les réseaux VPC, que leur mode soit automatique ou personnalisé et quelle que soit la façon dont ils sont créés. Le réseaupar défaut possède les mêmes règles implicites.

  • Règle implicite de sortie IPv4 autorisée. Une règle de sortie dont l'action est allow et la destination, 0.0.0.0/0, et dont la priorité est la plus faible possible (65535), permet à une instance d'envoyer du trafic vers n'importe quelle destination, à l'exception du trafic bloqué par Google Cloud. L'accès sortant peut être limité par une règle de pare-feu de priorité supérieure. L'accès à Internet est autorisé si aucune autre règle de pare-feu ne refuse le trafic sortant, et si l'instance possède une adresse IP externe ou utilise une instance Cloud NAT. Pour en savoir plus, consultez la section Conditions d'accès à Internet.

  • Règle implicite d'entrée interdite IPv4. Une règle d'entrée dont l'action est deny, dont la source est 0.0.0.0/0 et dont la priorité est la plus faible possible (65535), protège toutes les instances en bloquant leurs connexions entrantes. L'accès entrant peut être autorisé par une règle de priorité plus élevée. Le réseau par défaut dispose de règles supplémentaires qui remplacent celle-ci, autorisant certains types de connexions entrantes.

Si IPv6 est activé, le réseau VPC possède également ces deux règles implicites :

  • Règle implicite de sortie IPv6 autorisée. Une règle de sortie dont l'action est allow et la destination, ::/0, et dont la priorité est la plus faible possible (65535), permet à une instance d'envoyer du trafic vers n'importe quelle destination, à l'exception du trafic bloqué par Google Cloud. L'accès sortant peut être limité par une règle de pare-feu de priorité supérieure. L'accès à Internet est autorisé si aucune autre règle de pare-feu ne refuse le trafic sortant et si l'instance possède une adresse IP externe.

  • Règle implicite d'entrée interdite IPv6. Une règle d'entrée dont l'action est deny, dont la source est ::/0 et dont la priorité est la plus faible possible (65535), protège toutes les instances en bloquant leurs connexions entrantes. L'accès entrant peut être autorisé par une règle de priorité plus élevée.

Les règles implicites ne peuvent pas être supprimées, mais elles ont les priorités les plus faibles. Vous pouvez créer des règles qui les remplacent à condition qu'elles aient des priorités plus élevées (numéros de priorité inférieurs à 65535). Les règles deny sont prioritaires sur les règles allow ayant la même priorité. Une règle d'entrée allow ayant une priorité de 65535 ne prend donc jamais effet.

Règles préremplies dans le réseau par défaut

Le réseau par défaut est prérempli avec des règles de pare-feu autorisant les connexions entrantes vers les instances. Ces règles peuvent être supprimées ou modifiées si nécessaire :

  • default-allow-internal
    Autorise les connexions d'entrée pour tous les protocoles et ports entre les instances du réseau. Cette règle a la deuxième priorité la plus basse (65534), et elle autorise effectivement les connexions entrantes vers les instances de VM depuis d'autres instances du même réseau. Cette règle autorise le trafic dans 10.128.0.0/9 (de 10.128.0.1 à 10.255.255.254), une plage couvrant tous les sous-réseaux du réseau.
  • default-allow-ssh
    Autorise les connexions d'entrée sur le port de destination TCP 22 depuis toutes les sources vers toutes les instances du réseau. Cette règle a une priorité de 65534.
  • default-allow-rdp
    Autorise les connexions d'entrée sur le port de destination TCP 3389 depuis toutes les sources vers toutes les instances du réseau. Cette règle a une priorité de 65534, et elle permet la connexion à des instances exécutant le protocole RDP (Remote Desktop Protocol) de Microsoft.
  • default-allow-icmp
    Autorise le trafic d'entrée ICMP depuis toutes les sources vers toutes les instances du réseau. Cette règle a une priorité de 65534, et elle active des outils comme ping.

Trafic toujours bloqué

Google Cloud bloque toujours le trafic décrit dans le tableau ci-dessous. Vos règles de pare-feu ne peuvent pas être utilisées pour autoriser ce trafic.

Trafic toujours bloqué Détails
Protocoles autres que TCP, UDP, ICMP, IPIP, AH, ESP, SCTP et GRE vers des adresses IP externes de ressources Google Cloud Le type de ressource peut également limiter le protocole. Les règles de transfert pour le transfert de protocole ou l'équilibrage de charge transmettent le trafic pour le protocole et le port configurés uniquement.
Trafic de sortie vers le port de destination TCP 25 (SMTP) Trafic depuis :
• des instances vers des adresses IP externes sur Internet
• des instances vers des adresses IP externes d'instances
Paquets UDP IPv4 vers le port de destination 68 (réponses DHCPv4) et paquets UDP IPv6 vers le port de destination 546 (réponses DHCPv6) Trafic provenant d'adresses IP sources autres que le serveur de métadonnées (169.254.169.254)

Trafic toujours autorisé

Google Cloud exécute un serveur de métadonnées local avec chaque instance à l'adresse 169.254.169.254. Ce serveur est essentiel au fonctionnement de l'instance. Il faut donc qu'elle puisse y accéder quelles que soient les règles de pare-feu que vous configurez. Le serveur de métadonnées fournit à l'instance les services de base suivants :

Règles de pare-feu GKE

Google Kubernetes Engine crée automatiquement des règles de pare-feu lors de la création des ressources suivantes :

  • Clusters GKE
  • Services GKE
  • Ingress GKE

Pour plus d'informations, consultez la page Règles de pare-feu créées automatiquement.

Composants des règles de pare-feu

Chaque règle de pare-feu comprend les composants de configuration suivants :

  • Le sens de connexion : les règles d'entrée s'appliquent aux connexions entrantes provenant de sources spécifiées vers des cibles Google Cloud, et les règles de sortie s'appliquent aux connexions allant des cibles vers des destinations spécifiées.

  • Une priorité numérique permettant de déterminer si la règle est appliquée. Seule la règle ayant la priorité la plus élevée (numéro de priorité le plus petit) et dont les autres composants correspondent au trafic est appliquée ; les règles en conflit dont les priorités sont inférieures sont ignorées.

  • Une action en cas de correspondance, allow ou deny, qui détermine si la règle autorise ou bloque les connexions.

  • Le statut d'application de la règle de pare-feu : il est possible d'activer et de désactiver les règles de pare-feu sans les supprimer.

  • Une cible qui définit les instances (y compris les clusters GKE et les instances de l'environnement flexible App Engine) auxquelles la règle s'applique.

  • Un filtre de source pour les règles d'entrée ou un filtre de destination pour les règles de sortie.

  • Le protocole (tel que TCP, UDP ou ICMP) et le port de destination.

  • Une option booléenne logs qui consigne dans Cloud Logging les connexions correspondant à la règle.

Résumé des composants

Règle d'entrée (entrante)
Priorité Action Application Cible (définit la destination) Source filter (Filtre source) Protocols and ports (Protocoles et ports)
Entier de 0 à 65535 inclus ; 1000 par défaut
allow ou deny enabled (par défaut) ou disabled Le paramètre de cible spécifie la destination. Il peut contenir l'un des éléments suivants : Choisissez l'une des options suivantes :
  • Plage d'adresses IPv4
  • Plage d'adresses IPv6
  • Plage d'adresses IPv4 et d'instances par tag réseau
  • Plage d'adresses IPv4 et d'instances par compte de service
  • Plage d'adresses IPv6 et d'instances par tag réseau
  • Plage d'adresses IPv6 et d'instances par compte de service
Si aucune source n'est spécifiée, une plage IPv4 de 0.0.0.0/0 est utilisée.

Spécifiez un protocole, ou un protocole et un port de destination.

Si aucun protocole n'est défini, la règle s'applique à tous les protocoles et ports de destination.

Règle de sortie (sortante)
Priorité Action Application Cible (définit la source) Filtre de destination Protocols and ports (Protocoles et ports)
Entier de 0 à 65535 inclus ; 1000 par défaut
allow ou deny enabled (par défaut) ou disabled Le paramètre de cible spécifie la source. Il peut contenir l'un des éléments suivants :
  • Toutes les instances du réseau VPC
  • Instances par tag réseau
  • Instances par compte de service
Voici les différents types de visibilité :
  • Plage d'adresses IPv4
  • Plage d'adresses IPv6
Si aucune destination n'est spécifiée, une plage IPv4 de 0.0.0.0/0 est utilisée.
Spécifiez un protocole, ou un protocole et un port de destination.

Si aucun protocole n'est défini, la règle s'applique à tous les protocoles et ports de destination.

Sens du trafic

Le sens d'une règle de pare-feu peut être entrant ou sortant. Le sens est toujours défini du point de vue de la VM à laquelle la règle de pare-feu s'applique (la cible).

  • Le sens entrant décrit les connexions envoyées depuis une source vers une cible. Les règles d'entrée s'appliquent aux paquets pour les nouvelles sessions où la destination du paquet est la cible.

  • Le sens sortant décrit le trafic envoyé depuis une cible vers une destination. Les règles de sortie s'appliquent aux paquets pour les nouvelles sessions où la source du paquet est la cible.

  • Si vous ne spécifiez aucun sens, Google Cloud utilise le sens entrant.

Prenons l'exemple d'une connexion entre deux VM du même réseau. Le trafic de la VM1 vers la VM2 peut être contrôlé à l'aide de l'une de ces règles de pare-feu :

  • Une règle d'entrée ayant la VM2 comme cible et la VM1 comme source

  • Une règle de sortie ayant la VM1 comme cible et la VM2 comme destination

Priorité

La priorité de la règle de pare-feu est un entier compris entre 0 et 65535 inclus. Des entiers plus petits indiquent des priorités plus élevées. Si vous ne spécifiez pas de priorité lors de la création d'une règle, une priorité de 1000 lui est attribuée.

La priorité relative d'une règle de pare-feu détermine si elle est applicable lorsqu'elle est évaluée par rapport à d'autres. La logique d'évaluation fonctionne comme suit :

  • La règle applicable à une cible pour un type de trafic donné, et qui a la priorité la plus élevée, est prioritaire. La spécificité de la cible n'a pas d'importance. Par exemple, une règle d'entrée ayant une priorité plus élevée pour certains ports de destination et protocoles, et destinée à toutes les cibles est prioritaire sur une règle définie de la même manière pour les mêmes ports de destination et protocoles, mais destinée à des cibles spécifiques.

  • La règle de priorité la plus élevée applicable à une définition de protocole et de port donnée est prioritaire, même lorsque la définition du protocole et du port de destination est plus générale. Par exemple, une règle d'entrée de priorité plus élevée autorisant le trafic pour tous les protocoles et ports de destination sur des cibles données est prioritaire sur une règle d'entrée de priorité inférieure refusant le port TCP 22 pour les mêmes cibles.

  • Une règle ayant une action deny est prioritaire sur une règle ayant une action allow seulement si les deux règles ont la même priorité. En utilisant des priorités relatives, il est possible de créer des règles allow qui sont prioritaires sur des règles deny, et des règles deny qui sont prioritaires sur des règles allow.

  • Les règles ayant la même priorité et la même action ont le même résultat. Cependant, la règle utilisée lors de l'évaluation est indéterminée. Normalement, la règle utilisée n'a pas d'importance, sauf lorsque vous activez la journalisation des règles de pare-feu. Si vous souhaitez que vos journaux affichent les règles de pare-feu en cours d'évaluation dans un ordre cohérent et bien défini, attribuez-leur des priorités uniques.

Prenons l'exemple suivant où deux règles de pare-feu existent :

  • Une règle d'entrée depuis les sources 0.0.0.0/0 (toute adresse IPv4) applicable à toutes les cibles, tous les protocoles et tous les ports de destination, ayant une action deny et une priorité de 1000.

  • Une règle d'entrée depuis les sources 0.0.0.0/0 (toute adresse IPv4) applicable à des cibles spécifiques avec le tag webserver, pour le trafic sur TCP 80, avec une action allow.

La priorité de la seconde règle détermine si le trafic TCP sur le port 80 est autorisé pour les cibles webserver :

  • Si la priorité de la seconde règle est définie sur un nombre supérieur à 1000, sa priorité est inférieure. La première règle refusant tout le trafic est donc appliquée.

  • Si la priorité de la seconde règle est définie sur 1000, les deux règles ont des priorités identiques. La première règle refusant tout le trafic est donc appliquée.

  • Si la priorité de la seconde règle est définie sur un nombre inférieur à 1000, sa priorité est supérieure, autorisant ainsi le trafic sur le port TCP 80 pour les cibles webserver. En l'absence d'autres règles, la première règle refuse toujours les autres types de trafic vers les cibles webserver et refuse également l'intégralité du trafic, y compris sur le port TCP 80, vers les instances ne disposant pas du tag webserver.

L'exemple précédent montre comment vous pouvez utiliser des priorités pour créer des règles allow sélectives et des règles deny globales pour mettre en œuvre une bonne pratique de sécurité de moindre privilège.

Action en cas de correspondance

Le composant d'action d'une règle de pare-feu détermine si elle autorise ou bloque le trafic, en tenant compte des autres composants de la règle :

  • Une action allow autorise les connexions correspondant aux autres composants spécifiés.

  • Une action deny bloque les connexions correspondant aux autres composants spécifiés.

Application

Vous pouvez décider si une règle de pare-feu est appliquée ou non en définissant son état sur enabled ou disabled. Désactiver une règle est utile pour le dépannage ou pour accorder un accès temporaire aux instances. Il est beaucoup plus facile de désactiver une règle, effectuer un test et réactiver la règle, que de supprimer et recréer la règle.

Sauf indication contraire, toutes les règles de pare-feu sont activées (enabled) lors de leur création. Vous pouvez également choisir de créer une règle dans un état disabled.

L'état d'application des règles de pare-feu peut être modifié de enabled à disabled, et inversement, en modifiant la règle.

Lorsque vous modifiez l'état d'application d'une règle de pare-feu, la modification ne s'applique qu'aux nouvelles connexions. Les connexions existantes ne sont pas affectées par le changement d'état d'application.

Pensez à désactiver une règle de pare-feu dans des situations telles que celles-ci :

  • Pour le dépannage : si vous ne savez pas si une règle de pare-feu bloque ou autorise le trafic, désactivez-la temporairement pour déterminer si le trafic est autorisé ou bloqué. Cette manœuvre est utile pour résoudre les problèmes liés à l'effet d'une règle fonctionnant conjointement avec d'autres.
  • Pour la maintenance : désactiver des règles de pare-feu peut simplifier la maintenance périodique. Supposons que vous ayez une règle de pare-feu qui bloque l'accès SSH aux cibles (par exemple, les instances par tag cible), et que cette règle soit activée (enabled). Lorsque vous devez effectuer une opération de maintenance, vous pouvez désactiver la règle. Lorsque vous avez terminé, réactivez-la.

Source, destination, cible

Vous spécifiez une source ou une destination, mais pas les deux, selon le sens de la règle de pare-feu que vous créez. La signification du paramètre cible varie en fonction du sens de la règle de pare-feu.

  • Pour les règles d'entrée (entrantes), le paramètre de cible indique les instances de destination du trafic. Vous ne pouvez pas utiliser le paramètre de destination. Vous spécifiez la source en utilisant le paramètre de source.

  • Pour les règles de sortie (sortantes), le paramètre de cible indique les instances sources du trafic. Vous ne pouvez pas utiliser le paramètre de source. Vous spécifiez la destination en utilisant le paramètre de destination.

Les instances incluent également les clusters GKE et les instances de l'environnement flexible App Engine.

Paramètre de cible

Le paramètre de cible identifie toujours les instances Google Cloud, mais une cible peut être soit la destination, soit la source du trafic, en fonction du sens de la règle, comme décrit dans la section Source, destination et cible

Pour spécifier une cible, utilisez l'une des options suivantes :

  • Toutes les instances du réseau : la règle de pare-feu s'applique à toutes les instances du réseau.

  • Instances par tags cibles : la règle de pare-feu ne s'applique qu'aux instances disposant d'un tag réseau correspondant.

  • Instances par comptes de service cibles : la règle de pare-feu ne s'applique qu'aux instances utilisant un compte de service spécifique. Pour connaître le nombre maximal de comptes de service cibles que vous pouvez appliquer par règle de pare-feu, consultez la page Quotas de ressources des VPC.

Pour en savoir plus sur les avantages et les limites des tags cibles et des comptes de service cibles, consultez la section Filtrer par compte de service ou par tag réseau.

Cibles et adresses IP pour les règles d'entrée

La cible d'une règle de pare-feu d'entrée s'applique à tout le trafic arrivant sur l'interface réseau (carte d'interface réseau) d'une instance du réseau VPC, quelle que soit la façon dont la cible est specifiée. Une règle de pare-feu d'entrée s'applique aux paquets dont les destinations correspondent à l'une des adresses IP suivantes :

  • L'adresse IP interne principale attribuée à l'interface réseau de l'instance du réseau VPC

  • Toutes les plages d'adresses IP d'alias configurées sur l'interface réseau de l'instance du réseau VPC

  • L'adresse IP externe associée à l'interface réseau de l'instance du réseau VPC

  • Si IPv6 est configuré sur le sous-réseau, toute adresse IPv6 attribuée à la VM

  • L'adresse IP interne ou externe associée à une règle de transfert, pour l'équilibrage de charge ou le transfert de protocole, si l'instance est un backend pour l'équilibreur de charge ou une instance cible pour le transfert de protocole

Cibles et adresses IP pour les règles de sortie

La cible d'une règle de pare-feu de sortie s'applique à tout le trafic quittant l'interface réseau (carte d'interface réseau) d'une instance du réseau VPC, quelle que soit la façon dont la cible est spécifiée.

  • Par défaut, le transfert IP est désactivé. Une règle de pare-feu de sortie s'applique aux paquets dont les sources correspondent à l'un des éléments suivants :

    • L'adresse IP interne principale de la carte d'interface réseau d'une instance

    • Toutes les plages d'adresses IP d'alias configurées sur la carte d'interface réseau d'une instance

    • Si IPv6 est configuré sur le sous-réseau, l'une des adresses IPv6 attribuées à la VM

    • L'adresse IP interne ou externe associée à une règle de transfert, pour l'équilibrage de charge ou le transfert de protocole, si l'instance est un backend pour l'équilibreur de charge ou une instance cible pour le transfert de protocole

  • Lorsque le transfert IP est activé, la VM est autorisée à envoyer des paquets avec n'importe quelle source.

Paramètre de source

Le paramètre de source ne s'applique qu'aux règles d'entrée. Il doit s'agir de l'un des éléments suivants :

  • Plages IPv4 sources ou plages IPv6 sources : vous pouvez spécifier des plages d'adresses IP comme sources pour les paquets. Les plages peuvent être des adresses IPv4 ou IPv6, mais pas les deux. Les plages peuvent comprendre des adresses à l'intérieur et à l'extérieur de votre réseau VPC.

  • Tags sources : vous pouvez définir l'adresse IP interne principale de l'interface réseau des instances de VM au sein du même réseau VPC comme source des paquets, en identifiant ces instances sources par un tag réseau correspondant. Les tags sources s'appliquent exclusivement au trafic envoyé depuis l'interface réseau d'une autre instance applicable de votre réseau VPC. Les tags sources ne peuvent pas contrôler les paquets dont les sources sont des adresses IP externes, même si ces adresses appartiennent à des instances. Pour connaître le nombre maximal de tags sources que vous pouvez appliquer par règle de pare-feu, consultez la page Quotas de ressources des VPC.

  • Comptes de service sources : vous pouvez définir l'adresse IP interne principale de l'interface réseau des instances au sein du même réseau VPC comme source des paquets, en identifiant ces instances sources par les comptes de service qu'elles utilisent. Les comptes de service sources s'appliquent exclusivement au trafic envoyé depuis l'interface réseau d'une autre instance applicable de votre réseau VPC. Les comptes de service sources ne peuvent pas contrôler les paquets dont les sources sont des adresses IP externes, même si ces adresses appartiennent à des instances. Pour connaître le nombre maximal de comptes de service sources que vous pouvez appliquer par règle de pare-feu, consultez la page Quotas de ressources des VPC.

  • Vous pouvez utiliser une combinaison de plages d'adresses IP sources et de tags sources.

  • Vous pouvez utiliser une combinaison de plages d'adresses IP sources et de comptes de service sources.

  • Si aucune plage d'adresses IP sources, aucun tag source et aucun compte de service source n'est défini, Google Cloud définit la source comme étant n'importe quelle adresse IPv4 (0.0.0.0/0). Les sources IPv6 ne sont pas incluses.

Sources et adresses IP

Lorsque le paramètre de source d'une règle de pare-feu d'entrée inclut un tag source ou le compte de service source, Google Cloud identifie les VM correspondant au tag ou au compte de service, et inclut les adresses IP suivantes de ces VM dans l'ensemble de sources effectivement utilisé pour la règle de pare-feu.

  • L'adresse IPv4 interne principale de la carte d'interface réseau de la VM dans le réseau VPC

  • Toutes les adresses IPv6 attribuées à la carte d'interface réseau de la VM dans le réseau VPC

Les plages d'adresses IP d'alias de cette carte d'interface réseau et les adresses IP des règles de transfert associées ne sont pas incluses lorsque vous utilisez des tags sources ou des comptes de service sources. Si vous devez inclure les plages d'adresses IP d'alias de l'interface réseau d'une VM, ajoutez les plages d'alias à l'aide d'une plage d'adresses IPv4 source.

Si la règle de pare-feu utilise une combinaison de plages d'adresses IP sources et de tags sources ou une combinaison de plages d'adresses IP sources et de comptes de service sources, l'ensemble de sources effectivement utilisé contient les adresses IP identifiées par le tag ou le compte de service, plus les adresses IP spécifiées dans les plages d'adresses IP sources.

Paramètre de destination

Le paramètre de destination ne s'applique qu'aux règles de sortie. Le paramètre de destination n'accepte que les plages d'adresses IP. Les plages peuvent comprendre des adresses à l'intérieur et à l'extérieur de votre réseau VPC.

Si vous ne spécifiez pas de plage de destination, Google Cloud définit la destination comme étant toutes les adresses IPv4 (0.0.0.0/0). Les destinations IPv6 ne sont pas incluses.

Protocoles et ports

Vous pouvez réduire le champ d'application d'une règle de pare-feu en spécifiant des protocoles, ou des protocoles et des ports de destination. Vous pouvez spécifier un protocole, ou une combinaison de protocoles et de leurs ports de destination. Si vous ne spécifiez ni protocoles, ni ports, la règle de pare-feu est applicable pour l'ensemble du trafic sur n'importe quel protocole et n'importe quel port de destination. Vous ne pouvez spécifier que des ports de destination. Les règles basées sur les ports sources ne sont pas acceptées.

Il est nécessaire de spécifier un protocole pour rendre une règle de pare-feu spécifique. Si le protocole est compatible avec les ports, vous pouvez éventuellement spécifier un numéro de port de destination ou une plage de ports. Cependant, tous les protocoles ne sont pas compatibles avec les ports. Par exemple, des ports existent pour TCP et UDP, mais pas pour ICMP (ce protocole regroupe différents types ICMP, qui ne sont pas des ports et ne peuvent donc pas être spécifiés dans une règle de pare-feu).

Vous pouvez utiliser les noms de protocoles suivants dans les règles de pare-feu : tcp, udp, icmp (pour IPv4 ICMP), esp, ah, sctp et ipip. Pour tous les autres protocoles, utilisez les numéros de protocole IANA.

De nombreux protocoles ont les mêmes nom et numéro dans IPv4 et IPv6, ce qui n'est pas le cas de certains protocoles comme ICMP.

Le protocole IPv6 Hop-by-Hop n'est pas compatible avec les règles de pare-feu.

Les règles de pare-feu Google Cloud utilisent les informations de port pour référencer le port de destination d'un paquet, et non son port source :

  • Pour les règles de pare-feu d'entrée (entrantes), les ports de destination sont les ports des systèmes identifiés par le paramètre de cible de la règle (pour les règles d'entrée, le paramètre de cible spécifie les VM de destination pour le trafic).

  • Pour les règles de pare-feu de sortie (sortantes), les ports de destination représentent les ports des systèmes identifiés par le paramètre de destination de la règle.

Le tableau ci-dessous récapitule les combinaisons de spécifications de protocole et de port de destination valides pour les règles de pare-feu Google Cloud.

Spécification Exemple Explication
Aucun protocole et aucun port  : Si vous ne spécifiez pas de protocole, la règle de pare-feu s'applique à tous les protocoles et à leurs ports de destination.
Protocole tcp Si vous spécifiez un protocole sans aucune information de port, la règle de pare-feu s'applique à ce protocole et à tous ses ports.
Protocole et port unique tcp:80 Si vous spécifiez un protocole et un seul port de destination, la règle de pare-feu s'applique à ce port de destination pour le protocole.
Protocole et plage de ports tcp:20-22 Si vous spécifiez un protocole et une plage de ports, la règle de pare-feu s'applique à cette plage de ports pour le protocole.
Combinaisons icmp,tcp:80
tcp:443
udp:67-69
Vous pouvez spécifier différentes combinaisons de protocoles et de ports de destination auxquelles la règle de pare-feu s'applique. Pour plus d'informations, consultez la section Créer des règles de pare-feu.

Filtrer la source et la cible par compte de service

Vous pouvez utiliser des comptes de service pour créer des règles de pare-feu de nature plus spécifique :

  • Pour les règles d'entrée et de sortie, vous pouvez utiliser des comptes de service pour spécifier des cibles.

  • Pour les règles d'entrée, vous pouvez spécifier la source des paquets entrants comme étant l'adresse IP interne principale de toute VM du réseau dans lequel la VM utilise un compte de service particulier.

Le compte de service doit être créé dans le même projet que la règle de pare-feu et avant la création d'une règle de pare-feu qui lui est associée. Bien que le système ne vous empêche pas de créer une règle qui utilise un compte de service d'un autre projet, la règle n'est pas appliquée si le compte de service n'existe pas dans le projet de la règle de pare-feu.

Les règles de pare-feu qui utilisent des comptes de service pour identifier des instances s'appliquent aux instances créées et associées au compte de service, et aux instances existantes si vous modifiez leur compte de service. Si vous modifiez le compte de service associé à une instance, vous devez arrêter et redémarrer celle-ci. Vous pouvez associer des comptes de service à des instances individuelles et à des modèles d'instance utilisés par des groupes d'instances gérés.

Filtrer par compte de service ou par tag réseau

Cette section met en évidence les points clés à prendre en compte pour décider si vous devez utiliser des comptes de service ou des tags réseau pour définir des cibles et des sources (pour les règles d'entrée).

Si vous avez besoin d'un contrôle strict sur la manière dont les règles de pare-feu sont appliquées aux VM, utilisez les comptes de service cibles et sources au lieu des tags cibles et sources :

  • Un tag réseau est un attribut arbitraire. Un ou plusieurs tags réseau peuvent être associés à une instance par toute entité principale IAM (Identity and Access Management) autorisé à modifier l'instance. Les entités principales IAM dotées du rôle Administrateur d'instances Compute Engine pour un projet disposent de cette autorisation. Les entités principales IAM autorisées à modifier une instance peuvent changer ses tags réseau, ce qui peut modifier l'ensemble de règles de pare-feu applicables à cette instance.

  • Un compte de service représente une identité associée à une instance. Un seul compte de service peut être associé à une instance. Vous contrôlez l'accès au compte de service en contrôlant l'attribution du rôle Utilisateur du compte de service aux autres entités principales IAM. Pour qu'une entité principale IAM démarre une instance à l'aide d'un compte de service, elle doit détenir le rôle "Utilisateur du compte de service" au moins pour ce compte, et disposer des autorisations nécessaires pour créer des instances (par exemple, détenir le rôle "Administrateur d'instances Compute Engine" pour le projet).

Vous ne pouvez pas combiner et faire correspondre des comptes de service et des tags réseau dans une règle de pare-feu :

  • Vous ne pouvez pas utiliser à la fois les comptes de service cibles et les tags cibles dans une même règle de pare-feu (entrée ou sortie).

  • Si vous spécifiez des cibles par tag cible ou par compte de service cible, les sources suivantes ne sont pas valides pour les règles de pare-feu d'entrée.

    Cibles Sources non valides
    Tags cibles Comptes de service sources

    Combinaison de plages d'adresses IP sources et de comptes de service sources
    Compte de service cible Tags sources

    Combinaison de plages d'adresses IP sources et de tags sources

Les considérations opérationnelles concernant les comptes de service et les tags réseau sont les suivantes :

  • La modification d'un compte de service pour une instance nécessite que celle-ci soit arrêtée et redémarrée. L'ajout ou la suppression de tags peut être effectué pendant que l'instance est en cours d'exécution.

  • Vous pouvez spécifier un nombre maximal de comptes de service cibles, de comptes de service sources, de tags réseau cibles et de tags réseau sources pour les règles de pare-feu. Pour en savoir plus, consultez la page Quotas de ressources des VPC.

  • Si vous identifiez des instances par tag réseau, la règle de pare-feu s'applique sur l'adresse IP interne principale de l'instance.

  • Les règles de pare-feu du compte de service s'appliquent au nœud GKE, et non au pod GKE.

Cas d'utilisation

Les cas d'utilisation suivants illustrent le fonctionnement des règles de pare-feu. Dans ces exemples, toutes les règles de pare-feu sont activées.

Cas d'entrée

Les règles de pare-feu d'entrée contrôlent les connexions entrantes d'une source vers les instances cibles de votre réseau VPC. La source d'une règle d'entrée peut être définie par l'un des éléments suivants :

  • Une plage d'adresses IPv4 ou IPv6 ; la valeur par défaut est n'importe quelle adresse IPv4 (0.0.0.0/0)
  • Les autres instances de votre réseau VPC identifiées par des tags réseau
  • Les autres instances de votre réseau VPC identifiées par un compte de service
  • Les autres instances de votre réseau VPC identifiées par une plage d'adresses IPv4 ou IPv6 et par un tag réseau
  • Autres instances de votre réseau VPC identifiées par une plage d'adresses IPv4 ou IPv6 et par compte de service

La source par défaut est n'importe quelle adresse IP (0.0.0.0/0). Si vous souhaitez contrôler les connexions entrantes pour les sources extérieures à votre réseau VPC, y compris d'autres sources sur Internet, utilisez une plage d'adresses IPv4 au format CIDR.

Les règles d'entrée ayant une action allow autorisent le trafic entrant en fonction des autres composants de la règle. Outre la spécification de la source et de la cible pour la règle, vous pouvez limiter l'application de la règle à certains protocoles et ports de destination. De même, les règles d'entrée ayant une action deny peuvent être utilisées pour protéger les instances en bloquant le trafic entrant en fonction des composants de la règle de pare-feu.

Exemples d'entrée

Le schéma suivant illustre des exemples de règles de pare-feu pouvant contrôler des connexions d'entrée. Les exemples utilisent le paramètre de cible dans les attributions de règles pour appliquer des règles à des instances spécifiques.

Exemple de règles de pare-feu d'entrée (cliquez pour agrandir)
Exemple de règles de pare-feu d'entrée (cliquez pour agrandir)
  • Une règle d'entrée ayant une priorité de 1000 est applicable à la VM 1. Cette règle autorise le trafic TCP entrant depuis n'importe quelle source (0.0.0.0/0). Le trafic TCP provenant d'autres instances du réseau VPC est autorisé, en tenant compte des règles de sortie applicables sur ces autres instances. La VM 4 est capable de communiquer avec la VM 1 via TCP, car la VM 4 n'a pas de règle de sortie bloquant de telles communications (seule la règle implicite de sortie autorisée est applicable). La VM 1 ayant une adresse IP externe, cette règle autorise également le trafic TCP entrant depuis des hôtes externes sur Internet et depuis la VM 2 via des adresses IP externes.

  • La VM 2 ne dispose d'aucune règle de pare-feu d'entrée. La règle implicite d'entrée interdite bloque donc l'intégralité du trafic entrant. Les connexions provenant d'autres instances du réseau sont bloquées, indépendamment des règles de sortie mises en place pour les autres instances. Comme la VM 2 possède une adresse IP externe, elle est accessible depuis des hôtes externes sur Internet, mais cette règle implicite d'entrée interdite bloque également le trafic entrant externe.

  • Une règle d'entrée ayant une priorité de 1000 est applicable à la VM 3. Cette règle autorise le trafic TCP provenant d'instances du réseau ayant le tag réseau client, comme la VM 4. Le trafic TCP de la VM 4 vers la VM 3 est autorisé, car la VM 4 ne dispose pas de règle de sortie bloquant de telles communications (seule la règle implicite de sortie autorisée est applicable). La VM 3 ne disposant pas d'une adresse IP externe, il n'existe pas de chemin d'accès depuis des hôtes externes sur Internet.

Cas de sortie

Les règles de pare-feu de sortie contrôlent les connexions sortantes des instances cibles vers votre réseau VPC. Les règles de sortie ayant une action allow autorisent le trafic des instances en fonction des autres composants de la règle. Par exemple, vous pouvez autoriser le trafic sortant vers des destinations spécifiques, telles qu'une plage d'adresses IPv4, sur les protocoles et les ports de destination que vous spécifiez. De même, les règles de sortie ayant une action deny bloquent le trafic en fonction des autres composants de la règle.

Chaque règle de sortie a besoin d'une destination. La destination par défaut est n'importe quelle adresse IPv4 (0.0.0.0/0), mais vous pouvez créer une destination plus spécifique en utilisant une plage d'adresses IPv4 ou IPv6 au format CIDR. Lorsque vous spécifiez une plage d'adresses IPv4, vous pouvez contrôler le trafic vers les instances de votre réseau et vers des destinations en dehors de votre réseau, y compris les destinations sur Internet.

Exemples de sortie

Le schéma suivant illustre des exemples de règles de pare-feu pouvant contrôler des connexions de sortie. Les exemples utilisent le paramètre de cible dans les attributions de règles pour appliquer des règles à des instances spécifiques.

Exemple de règles de pare-feu de sortie (cliquez pour agrandir)
Exemple de règles de pare-feu de sortie (cliquez pour agrandir)
  • Aucune règle de pare-feu de sortie n'a été spécifiée pour la VM 1. Par conséquent, la règle implicite de sortie autorisée lui permet d'envoyer le trafic vers n'importe quelle destination. Les connexions à d'autres instances du réseau VPC sont autorisées, en tenant compte des règles d'entrée applicables à ces autres instances. La VM 1 est autorisée à envoyer du trafic vers la VM 4, car la VM 4 dispose d'une règle d'entrée autorisant le trafic entrant provenant de toute plage d'adresses IP. La VM 1 dispose d'une External IP (adresse IP externe). Elle est donc en mesure d'envoyer du trafic vers External host (hôtes externes) sur Internet. Les réponses entrantes au trafic envoyé par la VM 1 sont autorisées, car les règles de pare-feu sont "avec état".

  • Une règle de sortie ayant une priorité de 1000 est applicable à la VM 2. Cette règle refuse tout trafic sortant vers toutes les destinations (0.0.0.0/0). Le trafic sortant vers les autres instances du réseau VPC est bloqué, quelles que soient les règles d'entrée appliquées aux autres instances. Même si la VM 2 dispose d'une adresse IP externe, cette règle de pare-feu bloque son trafic sortant vers des hôtes externes sur Internet.

  • Une règle de sortie ayant une priorité de 1000 est applicable à la VM 3. Cette règle bloque le trafic TCP sortant vers toute destination dans la plage d'adresses IP 192.168.1.0/24. Même si les règles d'entrée pour la VM 4 autorisent l'intégralité du trafic entrant, la VM 3 ne peut pas envoyer de trafic TCP vers la VM 4. Cependant, la VM 3 est libre d'envoyer du trafic UDP à la VM 4, car la règle de sortie ne s'applique qu'au protocole TCP.

    En outre, la VM 3 peut envoyer tout type de trafic vers d'autres instances du réseau VPC en dehors de la plage d'adresses IP 192.168.1.0/24, à condition que ces autres instances disposent de règles d'entrée autorisant ce trafic. Comme elle ne possède pas d'adresse IP externe, elle n'a aucun moyen d'envoyer du trafic en dehors du réseau VPC.

Étape suivante

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de VPC en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Profiter d'un essai gratuit de VPC