Topologies de réseaux hybrides et multicloud

Cette présentation constitue la troisième partie d'une série d'articles traitant des déploiements hybrides et multicloud, des modèles d'architecture et des topologies de réseau. Nous évoquerons ici les topologies de réseau courantes que vous pouvez utiliser pour des configurations hybrides et multicloud. L'article décrit les scénarios et les modèles d'architecture auxquels ces topologies sont les plus adaptées, et présente les bonnes pratiques pour leur mise en œuvre à l'aide de Google Cloud.

La série comprend les éléments suivants :

Connecter des environnements informatiques privés à Google Cloud de manière sécurisée et fiable est la clé de tout déploiement hybride ou multicloud réussi. La topologie de réseau que vous choisissez pour une configuration hybride et multicloud doit répondre aux exigences particulières des charges de travail de votre entreprise, ainsi qu'aux modèles d'architecture que vous souhaitez appliquer. Bien que chaque cas nécessite quelques adaptations, certaines topologies courantes peuvent vous aider à élaborer votre plan d'action.

Topologie en miroir

Le concept de topologie en miroir consiste à reproduire à l'identique l'environnement informatique en cloud à partir de l'environnement informatique privé. Cette topologie s'applique principalement aux configurations qui suivent le modèle d'environnement hybride, dans lequel les charges de travail de développement et de test sont exécutées dans un premier environnement, tandis que les charges de travail de préproduction et de production sont exécutées dans un autre environnement.

Les charges de travail de test et de production ne sont pas censées communiquer directement les unes avec les autres. Toutefois, il doit être possible de gérer et de déployer les deux groupes de charges de travail de manière cohérente. Par conséquent, les deux environnements informatiques doivent être connectés de manière à répondre aux exigences suivantes :

  • Les systèmes d'intégration/de déploiement continu (CI/CD) et d'administration permettent de déployer et de gérer les charges de travail sur l'ensemble des environnements informatiques.
  • La surveillance et les autres outils administratifs fonctionnent sur l'ensemble des environnements informatiques.
  • Les charges de travail ne peuvent pas communiquer entre les différents environnements informatiques.

Architecture de référence

Le diagramme suivant montre une architecture de référence qui répond à ces exigences.

Architecture de référence répondant aux exigences précédentes.

  • Sur Google Cloud, vous utilisez deux clouds privés virtuels (VPC) distincts : un VPC partagé pour les charges de travail de développement et de test, et un VPC supplémentaire pour tous les systèmes CI/CD et outils administratifs. Les deux VPC sont appairés afin qu'ils puissent communiquer entre eux au moyen d'adresses IP internes. L'appairage permet aux systèmes CI/CD et administratifs de déployer et de gérer des charges de travail de développement et de test.
  • De plus, vous connectez le VPC CI/CD au réseau exécutant les charges de travail de production dans l'environnement informatique privé. Cette connexion est établie à l'aide de Cloud Interconnect ou de Cloud VPN et vous permet de déployer et de gérer les charges de travail de production.
  • Tous les environnements partagent un espace d'adressage IP RFC 1918 commun, sans chevauchement.
  • Si vous le souhaitez, vous pouvez définir des règles de pare-feu afin d'éviter que les charges de travail de production, de développement et de test ne communiquent entre elles.

Variantes

Comme variante de cette topologie, vous pouvez utiliser des connexions VPC distinctes pour les différentes étapes de développement et de test, toutes appairées à la connexion VPC CI/CD.

Pour les charges de travail basées sur des VM, l'exécution d'agents d'intégration continue dans chaque environnement assurant les tâches de déploiement présente également des avantages. Selon les capacités de votre système CI, l'utilisation d'agents peut vous permettre de mieux verrouiller la communication entre les environnements et d'appliquer un contrôle plus strict sur les systèmes autorisés à communiquer entre eux.

Selon cette variante, la topologie serait semblable à ceci :

Topologie en miroir avec agents.

Lorsque vous exécutez exclusivement des charges de travail Kubernetes, l'appairage des deux VPC n'est pas nécessaire. Le plan de contrôle de Google Kubernetes Engine (GKE) étant public, vous pouvez utiliser la fonctionnalité de réseaux autorisés maîtres et le contrôle des accès basé sur les rôles afin que seuls vos systèmes CI soient autorisés à effectuer des déploiements. Le diagramme suivant illustre cette topologie.

Topologie en miroir.

Bonnes pratiques

  • Veillez à ce que tous les systèmes CI/CD requis pour le déploiement ou la reconfiguration des déploiements de production assurent une haute disponibilité. En outre, songez à utiliser un réseau privé virtuel (VPN) redondant ou des liens d'interconnexion pour augmenter la disponibilité.
  • Configurez les instances de VM dans le VPC de développement et de test afin de disposer d'adresses IP publiques permettant à ces instances d'accéder directement à Internet. Sinon, déployez Cloud NAT dans le même VPC pour gérer le trafic de sortie.
  • Pour utiliser les réseaux publics, utilisez l'accès privé à Google afin d'éviter la communication entre les charges de travail VPC et les API Google.
  • Tenez compte également des bonnes pratiques générales en matière de topologies de réseaux hybrides et multicloud.

Topologie maillée

Le concept de topologie maillée consiste à établir un réseau plat couvrant plusieurs environnements informatiques, dans lequel tous les systèmes peuvent communiquer entre eux. Cette topologie s'applique principalement aux configurations hiérarchisées, partitionnées ou d'utilisation intensive, et nécessite de connecter les environnements informatiques de manière à répondre aux exigences suivantes :

  • Les charges de travail peuvent communiquer entre elles au-delà des limites de leur environnement via UDP ou TCP en utilisant des adresses IP privées RFC 1918.

  • L'application de règles de pare-feu permet de filtrer avec précision les flux de trafic internes et entre les différents environnements informatiques.

Architecture de référence

Le diagramme suivant montre une architecture de référence qui répond à ces exigences.

Architecture de référence maillée.

  • Du côté de Google Cloud, vous déployez les charges de travail dans un seul VPC partagé.

  • Vous utilisez Cloud Interconnect ou Cloud VPN pour connecter le VPC au réseau dans l'environnement informatique privé. Cette configuration permet d'établir la communication entre les environnements à l'aide d'adresses IP privées.

  • Vous utilisez Cloud Router pour échanger les informations de routage de façon dynamique entre les environnements.

  • Tous les environnements partagent un espace d'adressage IP RFC 1918 commun, sans chevauchement.

Variantes

Vous pouvez mettre en place des mécanismes avancés de pare-feu et d'inspection des paquets qui dépassent les capacités des règles de pare-feu de Google Cloud. Pour ce faire, étendez la topologie de manière à faire transiter tout le trafic interenvironnement par un dispositif de pare-feu, comme illustré par le diagramme suivant.

Topologie maillée étendue.

  • Vous établissez la liaison VPN ou d'interconnexion entre un VPC de transit dédié et le VLAN dans l'environnement informatique privé.

  • Vous établissez la connexion entre le VPC de transit et le VPC d'application à l'aide de VM exécutant le dispositif de pare-feu. Vous configurez ces VM pour le transfert IP. Les VM utilisent plusieurs interfaces réseau : l'une connectée au VPC de transit et l'autre au VPC de l'application.

  • Le dispositif de pare-feu peut également servir de passerelle NAT pour les instances de VM déployées dans le VPC de l'application. Cette passerelle permet à ces instances d'accéder à Internet sans passer par des adresses IP publiques.

Bonnes pratiques

Sortie contrôlée

Le concept de topologie de sortie contrôlée consiste à exposer une sélection d'API d'un environnement informatique privé aux charges de travail déployées dans Google Cloud, sans les exposer à l'Internet public. L'utilisation d'une passerelle API servant de façade aux charges de travail existantes permet de contrôler cette exposition. Vous déployez la passerelle dans un réseau de périmètre (DMZ) et les charges de travail dans un réseau dédié de plus haute sécurité, au sein de l'environnement informatique privé.

La topologie de sortie contrôlée s'applique principalement aux configurations hiérarchisées et nécessite d'établir les liaisons entre les environnements informatiques de manière à répondre aux exigences suivantes :

  • Les charges de travail déployées dans Google Cloud communiquent avec la passerelle API au moyen d'adresses IP privées. Les autres systèmes dans l'environnement informatique privé ne sont pas accessibles à partir de Google Cloud.

  • La communication entre l'environnement informatique privé et les charges de travail déployées dans Google Cloud n'est pas autorisée.

Architecture de référence

Le diagramme suivant illustre une architecture de référence répondant à ces exigences :

Topologie de sortie contrôlée.

  • Du côté de Google Cloud, vous déployez les charges de travail dans un VPC partagé.

  • Vous utilisez Cloud Interconnect ou Cloud VPN pour connecter le VPC à unréseau de périmètre dans l'environnement informatique privé, ce qui permet d'appeler la passerelle API.

  • À l'aide de règles de pare-feu, vous interdisez les connexions entrantes au VPC.

  • Vous pouvez également utiliser Cloud Router pour échanger les informations de routage de façon dynamique entre les environnements.

  • Tous les environnements partagent un espace d'adressage IP RFC 1918 commun, sans chevauchement.

Variantes

Pour accéder à Internet, les instances de VM que vous déployez dans le VPC de l'application doivent disposer d'adresses IP externes. Pour éviter de devoir définir ces adresses externes, vous pouvez déployer Cloud NAT dans le même réseau VPC, comme le montre le schéma suivant.

Variantes de topologie de sortie contrôlée.

Bonnes pratiques

Entrée contrôlée

Le concept de topologie d'entrée contrôlée consiste à exposer une sélection d'API de charges de travail déployées dans Google Cloud à l'environnement informatique privé, sans les exposer à l'Internet public. Cette topologie est la contrepartie du scénario de sortie contrôlée et convient parfaitement aux configurations hybrides de périphérie.

Pour exposer les API sélectionnées, vous utilisez une passerelle API accessible à l'environnement informatique privé en procédant comme suit :

  • Les charges de travail déployées dans l'environnement informatique privé peuvent communiquer avec la passerelle API en utilisant des adresses IP privées. Les autres systèmes déployés dans Google Cloud ne sont pas accessibles.

  • La communication entre Google Cloud et l'environnement informatique privé n'est pas autorisée.

Architecture de référence

Le diagramme suivant montre une architecture de référence répondant à ces exigences.

Topologie d'entrée contrôlée.

  • Du côté de Google Cloud, vous déployez les charges de travail dans un VPC d'application.

  • Vous établissez une connexion Cloud Interconnect ou Cloud VPN entre un VPC de transit dédié et l'environnement informatique privé.

  • Vous établissez la connexion entre le VPC de transit et le VPC d'application en utilisant des VM qui exécutent la passerelle API. Ces VM utilisent deux interfaces réseau, l'une connectée au VPC de transit et l'autre au VPC de l'application. Pour équilibrer le trafic vers plusieurs instances de passerelle API, vous devez configurer un équilibreur de charge interne dans le VPC de transit.

  • Vous déployez Cloud NAT dans le VPC de l'application pour permettre aux charges de travail d'accéder à Internet. Cette passerelle évite de devoir attribuer aux instances de VM des adresses IP externes, ce qui est déconseillé dans les systèmes déployés derrière une passerelle API.

  • Vous pouvez éventuellement utiliser Cloud Router pour échanger les informations de routage de façon dynamique entre les environnements.

  • Tous les environnements partagent un espace d'adressage IP RFC 1918 commun, sans chevauchement.

Bonnes pratiques

Entrée et sortie contrôlées

La combinaison d'entrées et de sorties contrôlées permet l'utilisation bidirectionnelle d'une sélection d'API entre des charges de travail qui s'exécutent dans Google Cloud et dans un environnement informatique privé. Des deux côtés, vous utilisez des passerelles API pour exposer les API sélectionnées et éventuellement authentifier, autoriser et auditer les appels.

La communication des API fonctionne de la façon suivante :

  • Les charges de travail déployées dans Google Cloud communiquent avec la passerelle API au moyen d'adresses IP privées. Les autres systèmes déployés dans l'environnement informatique privé ne sont pas accessibles.

  • À l'inverse, les charges de travail que vous déployez dans l'environnement informatique privé peuvent communiquer avec la passerelle API côté Google Cloud au moyen d'adresses IP privées. Les autres systèmes déployés dans Google Cloud ne sont pas accessibles.

Architecture de référence

Le diagramme suivant montre une architecture de référence appliquant une topologie d'entrée et de sortie contrôlées.

Topologie d'entrée et de sortie contrôlées.

  • Du côté de Google Cloud, vous déployez des charges de travail dans un VPC partagé sans les exposer à Internet.

  • Vous établissez une connexion Cloud Interconnect ou Cloud VPN entre un VPC de transit dédié et l'environnement informatique privé.

  • Vous établissez la connexion entre le VPC de transit et le VPC d'application en utilisant des VM qui exécutent la passerelle API. Ces VM utilisent deux interfaces réseau, l'une connectée au VPC de transit et l'autre au VPC de l'application. Pour équilibrer le trafic vers plusieurs instances de passerelle API, vous devez configurer un équilibreur de charge interne dans le VPC de transit.

  • Vous utilisez également Cloud NAT, qui permet aux charges de travail d'accéder à Internet et de communiquer avec la passerelle API exécutée dans l'environnement informatique privé.

  • Vous pouvez éventuellement utiliser Cloud Router pour échanger les informations de routage de façon dynamique entre les environnements.

  • Tous les environnements partagent un espace d'adressage IP RFC 1918 commun, sans chevauchement.

Bonnes pratiques

Topologie de transfert

Le concept de topologie de transfert consiste à utiliser des services de stockage fournis par Google Cloud pour connecter un environnement informatique privé à des projets dans Google Cloud. Cette topologie s'applique principalement aux configurations qui suivent le modèle analytique, selon lequel :

  • Les charges de travail qui s'exécutent dans un environnement informatique privé importent les données dans des emplacements de stockage partagés. En fonction des cas d'utilisation, les importations s'effectuent de façon groupée ou par petits messages.

  • Les charges de travail hébergées par Google Cloud consomment ensuite les données provenant de ces emplacements et les traitent par flux ou par lots.

Architecture de référence

Le diagramme suivant illustre une architecture de référence appliquant une topologie de transfert.

Architecture de référence appliquant la topologie de transfert.

  • Du côté de Google Cloud, vous déployez les charges de travail dans un VPC d'application. Ces charges de travail peuvent inclure des applications de traitement de données, d'analyse et d'interface analytique.

  • Pour une exposition sécurisée des applications d'interface aux utilisateurs d'entreprise, vous pouvez employer Identity-Aware Proxy.

  • Vous utilisez un ensemble de buckets Cloud Storage ou de files d'attente Pub/Sub pour importer les données à partir de l'environnement informatique privé et les rendre accessibles aux charges de travail déployées dans Google Cloud pour traitement ultérieur. Les stratégies IAM vous permettent de limiter l'accès aux charges de travail validées.

  • En raison de l'absence de connectivité réseau privée entre les environnements, les espaces d'adressage IP RFC 1918 sont autorisés à se chevaucher.

Bonnes pratiques

Bonnes pratiques pour les topologies de réseaux hybrides et multicloud

  • Du côté de Google Cloud, profitez des avantages des VPC partagés. Ceux-ci peuvent être utilisés dans plusieurs projets Google Cloud, ce qui évite de devoir gérer plusieurs VPC individuellement. Les VPC partagés permettent également de centraliser la gestion de la configuration de l'appairage, des sous-réseaux, des règles de pare-feu et des autorisations.

  • Concernant les règles de pare-feu, préférez le filtrage basé sur compte de service au filtrage basé sur tag réseau.

  • Évitez d'utiliser des VPC pour isoler les charges de travail les unes des autres. Faites plutôt appel aux sous-réseaux et aux règles de pare-feu. Si vous utilisez GKE, pensez aux règles de réseau pour compléter cette approche.

  • Cloud VPN assure le chiffrement du trafic entre les environnements, ce qui n'est pas le cas de Cloud Interconnect. Pour aider à sécuriser la communication entre les charges de travail, privilégiez l'utilisation du protocole TLS (Transport Layer Security).

  • Adoptez nos bonnes pratiques pour créer des VPN haut débit.

  • Prévoyez suffisamment d'espace d'adresses à partir de votre espace d'adressage IP RFC 1918 existant pour accueillir tous les systèmes hébergés sur le cloud.

  • Si vous utilisez GKE, pensez à utiliser des clusters privés et tenez compte des exigences de taille du réseau.

  • Permettez aux instances de VM qui s'exécutent dans Google Cloud et qui n'ont pas d'adresse IP externe attribuée d'accéder aux services Google à l'aide de l'accès privé à Google.

Étape suivante