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 à une organisation, consultez la section Stratégies 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, 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 n'acceptent que les connexions IPv4. 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 ne pouvez utiliser qu'une adresse IPv4 ou un bloc IPv4 au format CIDR.

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

    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 a deux règles de pare-feu implicites. Ces règles existent, mais ne sont pas affichées dans Cloud Console :

  • Règle implicite de sortie 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. 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.

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 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 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é Applicable à
Une partie du trafic GRE (bêta) • Trafic dans les tunnels Cloud VPN
• Trafic sur les rattachements Cloud Interconnect (VLAN)
• Trafic pour les règles de transfert (équilibrage de charge ou transfert de protocole)

GRE est autorisé au sein d'un réseau VPC
Protocoles autres que TCP, UDP, ICMP, AH, ESP, SCTP et GRE vers des adresses IP externes de ressources Google Cloud Le type de ressource limite davantage le protocole. Par exemple, l'équilibrage de charge TCP/UDP réseau n'accepte que TCP et UDP. En outre, une règle de transfert pour le transfert de protocole ne traite qu'un seul protocole. Consultez la documentation sur le transfert de protocole pour obtenir la liste des protocoles acceptés.
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

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 :

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.

  • L'état 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.

  • Une source pour les règles d'entrée ou une destination pour les règles de sortie.

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

Résumé des composants

Règle d'entrée (entrante)
Priorité Action Application Cible (définit la destination) Source 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 dont la valeur par défaut est "toutes" (0.0.0.0/0)
  • Instances par tag réseau
  • Instances par compte de service
Spécifiez un protocole, ou un protocole et un port.

Si aucun protocole n'est défini, la règle s'applique à tous les protocoles.
Règle de sortie (sortante)
Priorité Action Application Cible (définit la source) Destination 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
Tout réseau ou une plage spécifique d'adresses IPv4 ; la valeur par défaut est "toutes" (0.0.0.0/0). Spécifiez un protocole, ou un protocole et un port.

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

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 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 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 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 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 destinés à 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 (c'est-à-dire n'importe quelle source) applicable à toutes les cibles, tous les protocoles et tous les ports, ayant une action deny et une priorité de 1000

  • Une règle d'entrée depuis les sources 0.0.0.0/0 (c'est-à-dire n'importe quelle source) applicable à des cibles spécifiques disposant du tag webserver, pour le trafic sur le port TCP 80, ayant 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.

Cible

Pour une règle d'entrée (entrante), le paramètre de cible désigne les instances de VM de destination, y compris les clusters GKE et les instances de l'environnement flexible App Engine. Pour une règle de sortie (sortante), la cible désigne les instances sources. Par conséquent, le paramètre de cible est toujours utilisé pour désigner 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.

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

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

  • 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

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

Source ou destination

Vous spécifiez une source ou une destination, mais pas les deux, selon le sens du pare-feu que vous créez :

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

Sources

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 d'adresses IP sources : vous pouvez spécifier des plages d'adresses IP comme sources pour les paquets. Les plages peuvent comprendre des adresses à l'intérieur et à l'extérieur de votre réseau VPC. Les plages d'adresses IP sources peuvent être utilisées pour définir des sources à la fois à l'intérieur et à l'extérieur de Google Cloud.

  • 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 IP (0.0.0.0/0).

Sources et adresses IP

Lorsque vous spécifiez une source à l'aide de l'une des méthodes suivantes, Google Cloud considère cette source comme l'adresse IP interne principale de l'interface réseau de la VM dans le réseau VPC :

  • Tags sources
  • Comptes de service sources
  • Spécification de source incluant des tags sources ou des comptes de service sources

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 d'une VM, ajoutez-les à une liste de plages sources pour une règle d'entrée. Vous pouvez utiliser des plages sources et des tags sources ensemble, et vous pouvez utiliser des plages sources et des comptes de service sources ensemble.

Destinations

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 IP (0.0.0.0/0).

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. Vous pouvez spécifier un protocole, ou une combinaison de protocoles et de leurs ports. 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.

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 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, mais ce ne sont pas des ports).

Vous pouvez spécifier un protocole en utilisant son nom (tcp, udp, icmp, esp, ah, sctp, ipip) ou son numéro de protocole IP décimal.

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 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.
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, la règle de pare-feu ne s'applique qu'à ce port.
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 ne s'applique qu'à cette plage de ports.
Combinaisons icmp,tcp:80
tcp:443
udp:67-69
Vous pouvez spécifier différentes combinaisons de protocoles et de ports 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 tout membre IAM (Identity and Access Management) autorisé à modifier l'instance. Les membres IAM dotés du rôle Administrateur d'instances Compute Engine pour un projet disposent de cette autorisation. Les membres IAM autorisés à 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 membres IAM. Pour qu'un membre IAM démarre une instance à l'aide d'un compte de service, ce membre 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, avec une valeur par défaut de 0.0.0.0/0
  • 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 des tags réseau

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 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 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 IP (0.0.0.0/0), mais vous pouvez créer une destination plus spécifique en utilisant une plage d'adresses IPv4 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