Présentation des règles de pare-feu

Les règles de pare-feu de Google Cloud Platform (GCP) vous permettent d'autoriser ou d'interdire le trafic vers et depuis vos instances de machines virtuelles (VM) en fonction d'une configuration que vous spécifiez. Les règles de pare-feu GCP 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. Les règles de pare-feu existent en quelque sorte entre les instances et les autres réseaux, mais également entre les instances au sein du même réseau. Consultez la section Utiliser des règles de pare-feu pour en savoir plus sur la création et l'utilisation de règles de pare-feu.

Règles de pare-feu dans GCP

Lorsque vous créez une règle de pare-feu GCP, vous spécifiez un réseau VPC et un ensemble de composants qui définissent ce que la règle fera. Les composants vous permettent de cibler certains types de trafic en fonction du protocole, des ports, des sources et des destinations du trafic. Pour plus de précisions, consultez la section Composants des règles de pare-feu.

Vous pouvez créer ou modifier des règles de pare-feu GCP via la console Google Cloud Platform, l'outil de ligne de commande gcloud et 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, GCP dispose d'autres règles pouvant affecter le trafic entrant et sortant :

  • GCP n'autorise pas certains protocoles IP, tels que GRE, au sein d'un réseau VPC. Pour plus de précisions, consultez la section Trafic toujours bloqué.

  • GCP autorise toujours la communication entre une instance de machine virtuelle et son serveur de métadonnées correspondant à 169.254.169.254. Pour plus de précisions, 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 default est pré-rempli avec des règles de pare-feu que vous pouvez supprimer ou modifier.

Spécifications

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

  • Les règles de pare-feu ne sont compatibles qu'avec le trafic 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 au trafic tant qu'elle est activée. Vous pouvez désactiver une règle à des fins de dépannage, par exemple.

  • Chaque règle de pare-feu s'applique au trafic entrant (ingress) ou sortant (egress), mais pas aux deux. Pour plus de précisions, consultez la section Sens du trafic.

  • 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éseau VPC ou à l'aide de tunnels Cloud VPN.

  • Les règles de pare-feu GCP sont dites "avec état". Si une connexion est autorisée entre une source et une cible, ou une cible et une destination, l'intégralité du trafic lié dans l'un ou l'autre sens, sera autorisée aussi longtemps que la connexion reste active. En d'autres termes, les règles de pare-feu permettent une communication bidirectionnelle dès lors qu'une session est établie. La connexion est considérée comme active si au moins un paquet est envoyé toutes les 10 minutes. Les règles de pare-feu ne peuvent pas autoriser le trafic dans un sens tout en interdisant le même trafic dans l'autre sens.

  • Les règles de pare-feu GCP 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 suivants.

  • 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 la console Cloud :

  • La règle implicite de sortie autorisée : une règle egress dont l'action est allow, la destination est 0.0.0.0/0 et la priorité la plus faible possible (65535) permet à toute instance d'envoyer du trafic vers n'importe quelle destination, à l'exception du trafic bloqué par GCP. 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 n'interdit le trafic sortant, et si l'instance possède une adresse IP externe ou utilise une instance NAT. Consultez la section Conditions d'accès à Internet pour en savoir plus.

  • La règle implicite d'entrée interdite : une règle ingress dont l'action est deny, la source est 0.0.0.0/0 et la priorité la plus faible possible (65535) protège toutes les instances en bloquant leur trafic entrant. L'accès entrant peut être autorisé par une règle de priorité plus élevée. Notez que le réseau default dispose de règles supplémentaires qui remplacent celle-ci, autorisant certains types de trafic entrant.

Les règles implicites ne peuvent pas être supprimées, mais elles ont les priorités les plus faibles. Les règles que vous créez peuvent les remplacer à condition qu'elles aient des priorités plus élevées (numéros de priorité inférieurs à 65535).

Règles pré-remplies dans le réseau default

Le réseau default est pré-rempli avec des règles de pare-feu autorisant le trafic entrant aux 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.
  • default-allow-ssh
    Autorise des 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 des 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 de Microsoft (Remote Desktop Protocol).
  • 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 le ping.

Trafic toujours bloqué

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

Trafic toujours bloqué Applicable à
Trafic GRE Toutes les sources, toutes les destinations, y compris parmi les instances utilisant des adresses IP internes
Protocoles autres que TCP, UDP, ICMP et IPIP Trafic entre :
• les instances et Internet ;
• les instances si elles sont adressées avec des adresses IP externes ;
• les instances dans lesquelles un équilibreur de charge avec une adresse IP externe est impliqué.
Trafic de sortie sur le port TCP 25 (SMTP) Trafic depuis :
• les instances vers Internet ;
• les instances vers d'autres instances adressées avec une adresse IP externe.

Trafic toujours autorisé

Google 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 :

  • Une priorité numérique utilisée pour déterminer si la règle sera 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.

  • Le sens du trafic : les règles ingress s'appliquent aux connexions entrantes allant des sources spécifiées vers des cibles GCP, et les règles egress s'appliquent au trafic allant des cibles vers des destinations spécifiées.

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

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

  • Une source pour les règles ingress ou une destination pour les règles egress

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

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

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
Soit allow, soit deny. Soit enabled (par défaut), soit disabled. Le paramètre de cible spécifie la destination. Il peut contenir l'un des éléments suivants :
• Toutes les instances du
   réseau VPC
• Instances par
  compte de service
• Instances par tag réseau
Choisissez l'une des options suivantes :
• Plage d'adresses IPv4 ;
  la valeur par défaut est "toutes" (0.0.0.0/0)
• Instances par
  compte de service
• Instances par tag réseau
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
Soit allow, soit deny. Soit enabled (par défaut), soit 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
  compte de service
• Instances par tag réseau
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.

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 ingress 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 ingress 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 ingress de priorité inférieure refusant le protocole TCP 22 pour les mêmes cibles.

  • Une règle ayant une action deny remplace 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 remplacent les règles deny, et inversement.

  • 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. Pour en savoir plus sur la journalisation, consultez la Présentation de la journalisation des règles de pare-feu.

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

  • Une règle ingress depuis des sources 0.0.0.0/0 (n'importe où) applicable à toutes les cibles, à tous les protocoles et à tous les ports, ayant une action deny et une priorité de 1000

  • Une règle ingress depuis des sources 0.0.0.0/0 (n'importe où) applicable à des cibles spécifiques disposant du tag webserver, pour le trafic sur 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é sera inférieure. La première règle interdisant tout le trafic sera donc appliquée.

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

  • Si la priorité de la seconde règle est définie sur un nombre inférieur à 1000, la priorité sera plus élevée, permettant ainsi le trafic sur TCP 80 pour les cibles webserver. En l'absence d'autres règles, la première règle interdit toujours les autres types de trafic vers les cibles webserver et interdit également l'intégralité du trafic, y compris 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 implémenter une bonne pratique de sécurité de moindre privilège.

Sens du trafic

Le sens d'une règle de pare-feu peut être ingress ou egress. Le sens est toujours défini du point de vue de la cible.

  • Le sens ingress décrit le trafic envoyé 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 egress 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, GCP utilise ingress.

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

  • Une règle ingress ayant VM2 comme cible et VM1 comme source

  • Une règle egress ayant VM1 comme cible et VM2 comme destination

Action en cas de correspondance

Le composant d'action d'une règle de pare-feu détermine s'il 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 activé ou désactivé. 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 lors de leur création. Vous pouvez également choisir de créer une règle dans un état désactivé.

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

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 habituellement activée. 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 (ingress), le paramètre de cible désigne les VM de destination, y compris les clusters GKE et les instances de l'environnement flexible d'App Engine. Pour une règle de sortie (egress), la cible désigne les VM, clusters et instances sources. Par conséquent, le paramètre de cible est toujours utilisé pour désigner les VM GCP, mais une cible peut être soit la destination, soit la source du trafic, en fonction du sens de la règle.

Une cible est spécifiée en utilisant exactement l'une des options suivantes :

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

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

  • Instances par compte de service cible : la règle de pare-feu ne s'applique qu'aux VM utilisant un compte de service spécifique.

Quelle que soit la manière dont vous spécifiez une cible, la règle de pare-feu s'applique à ses adresses IP principale et secondaire (alias). Pour les règles d'entrée, les cibles couvrent le trafic envoyé aux adresses IP principale ou secondaire des instances. Pour les règles de sortie, les cibles couvrent le trafic envoyé à partir des adresses IP principale ou secondaire des instances. Consultez la section Filtrer par compte de service ou par tag réseau pour en savoir plus sur les avantages et les limites de chaque méthode.

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 (ingress), le paramètre de cible indique les VM 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 (egress), le paramètre de cible indique les VM 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 exactement 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 GCP.

  • Tags sources : vous pouvez définir l'adresse IP interne principale de l'interface réseau des autres VM au sein du même réseau VPC comme source des paquets, en identifiant ces VM sources par un tag réseau correspondant. Les tags sources s'appliquent uniquement aux autres VM GCP de votre réseau. Consultez la section relative aux quotas et limites de VPC pour connaître le nombre maximal de tags source que vous pouvez appliquer.

  • Comptes de service sources : vous pouvez définir l'adresse IP interne principale de l'interface réseau des autres VM au sein du même réseau VPC comme source des paquets, en identifiant ces VM sources par le compte de service qu'elles utilisent. Les comptes de service sources s'appliquent uniquement aux autres VM GCP de votre réseau.

  • 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 source, aucun tag source et aucun compte de service source n'est défini, GCP définit la source par n'importe quelle adresse IP (0.0.0.0/0).

Destinations

Le paramètre de destination est uniquement applicable 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, GCP 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 (ICMP a 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 GCP utilisent les informations de port pour référencer le port de destination d'un paquet, pas 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 machines virtuelles 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 suivant récapitule les combinaisons de spécifications de protocole et de port valides pour les règles de pare-feu GCP :

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 s'applique uniquement à 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 s'applique uniquement à cette plage de ports.
Combinaisons icmp,tcp:80,tcp:443,udp:67-69 Si vous spécifiez une liste de protocoles ou de protocoles et de ports séparés par des virgules, la règle de pare-feu s'applique à chacun des protocoles et des ports spécifiés. 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éé avant de créer une règle de pare-feu qui lui est liée.

Les règles de pare-feu qui utilisent des comptes de service pour identifier des instances s'appliquent aux instances nouvellement 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 cette dernière. 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 autorisé à la modifier. Les membres IAM dotés du rôle d'administrateur d'instances de 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 des 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 d'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 avoir le rôle d'utilisateur de compte de service au moins pour ce compte, et disposer des autorisations nécessaires pour créer des instances (par exemple, avoir le rôle d'administrateur d'instances de 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).

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

Cibles Sources non valides
Tags cibles Comptes de service sources
Combinaison de plages d'adresses IP sources et de comptes de services sources
Compte de service cible Tags sources
Combinaison de plages d'adresses IP sources et de tags sources

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

  • La modification d'un compte de service pour une instance nécessite l'arrêt et le redémarrage de cette dernière. L'ajout ou la suppression de tags peut être effectué pendant que l'instance est en cours d'exécution.

  • Un seul compte de service cible peut être spécifié par règle de pare-feu. Plusieurs tags cibles peuvent être spécifiés dans une même règle de pare-feu.

  • Un seul compte de service source peut être spécifié par règle de pare-feu d'entrée. Plusieurs tags sources peuvent être spécifiés dans une même règle de pare-feu.

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

Cas d'utilisation

Les cas d'utilisation suivants illustrent le fonctionnement des règles de pare-feu. Notez que 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 toute 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 (ingress) 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 connexions d'entrée pouvant être contrôlées par des règles de pare-feu. 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 ingress (d'entrée) de priorité 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 une telle communication (seule la règle implicite de sortie autorisée est applicable). La VM 1 ayant une External IP (adresse IP externe), cette règle autorise également le trafic TCP entrant provenant d'External host (hôtes externes) sur Internet.

  • La VM 2 ne dispose d'aucune règle de pare-feu d'entrée, la implied deny ingress rule (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 External IP (adresse IP externe), elle est accessible depuis des External host (hôtes externes) sur Internet, mais cette règle implicite d'interdiction bloque également le trafic entrant externe.

  • Une règle ingress (d'entrée) avec une priorité 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 External IP (adresse IP externe), il n'existe pas de chemin d'accès depuis des External host (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 (egress) 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 egress a besoin d'une destination. La destination par défaut est toute 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 quelques exemples de connexions de sortie pouvant être contrôlées par des règles de pare-feu. 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 implied allow egress rule (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 ingress (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 ingress (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 des 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 egress (de sortie) de priorité 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 ingress (d'entrée) appliquées aux autres instances. Même si la VM 2 dispose d'une External IP (adresse IP externe), cette règle de pare-feu bloque son trafic sortant vers des External host (hôtes externes) sur Internet.

  • Une règle egress (de sortie) de priorité 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 ingress (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 egress (de sortie) s'applique uniquement 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 ingress (d'entrée) autorisant ce trafic. Comme elle ne possède pas d'External IP (adresse IP externe), elle n'a aucun moyen d'envoyer du trafic en dehors du réseau VPC.

Étape suivante