Le modèle en miroir est basé sur la réplication de la conception d'un ou de plusieurs environnements existants dans un ou plusieurs nouveaux environnements. Par conséquent, ce modèle s'applique principalement aux architectures qui suivent le modèle d'environnement hybride. Dans ce modèle, vous exécutez vos charges de travail de développement et de test dans un environnement tandis que vous exécutez vos charges de travail de préproduction et de production dans un autre.
Le modèle en miroir suppose que 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.
Si vous utilisez ce modèle, connectez les deux environnements informatiques de manière à répondre aux exigences suivantes :
- L'intégration continue/le déploiement continu (CI/CD) permettent de déployer et de gérer des charges de travail dans tous les environnements informatiques ou spécifiques.
- La surveillance, la gestion de la configuration et d'autres systèmes administratifs doivent fonctionner dans tous les environnements informatiques.
- Les charges de travail ne peuvent pas communiquer directement entre les différents environnements informatiques. Si nécessaire, la communication doit être ultraprécise et contrôlée.
Architecture
Le schéma d'architecture suivant illustre une architecture de référence de haut niveau de ce modèle compatible avec l'intégration et la diffusion continues, la surveillance, la gestion de la configuration, d'autres systèmes administratifs et la communication des charges de travail:
La description de l'architecture du schéma précédent est la suivante :
- Les charges de travail sont distribuées en fonction des environnements fonctionnels (développement, test, CI/CD et outils administratifs) sur des VPC distincts du côté de Google Cloud.
- Le VPC partagé est utilisé pour le développement et les tests de charges de travail. Un VPC supplémentaire est utilisé pour les outils CI/CD et administratifs. Avec des VPC partagés :
- Les applications sont gérées par différentes équipes pour chaque environnement et par projet de service.
- Le projet hôte administre et contrôle les contrôles de sécurité et de communication réseau entre les environnements de développement et de test, ainsi que vers l'extérieur du VPC.
- Le VPC CI/CD est connecté au réseau exécutant les charges de travail de production dans votre environnement informatique privé.
- Les règles de pare-feu n'autorisent que le trafic autorisé.
- Vous pouvez également utiliser Cloud Next Generation Firewall Enterprise avec un service de prévention des intrusions pour mettre en œuvre une inspection approfondie des paquets à des fins de prévention des menaces sans modifier la conception ou le routage. Cloud Next Generation Firewall Enterprise consiste à créer des points de terminaison de pare-feu zonaux gérés par Google, qui utilisent la technologie d'interception des paquets afin d'inspecter de manière transparente les charges de travail à la recherche des signatures de menaces configurées. Il protège également les charges de travail contre les menaces.
- Permet la communication entre les VPC appairés à l'aide d'adresses IP internes.
- L'appairage dans ce modèle 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.
- Tenez compte de ces bonnes pratiques générales.
Vous établissez cette connexion CI/CD à l'aide de l'une des options de connectivité réseau hybride et multicloud décrites qui répondent aux exigences de votre entreprise et de vos applications. Pour vous permettre de déployer et de gérer les charges de travail de production, cette connexion fournit une joignabilité du réseau privé entre les différents environnements informatiques. Tous les environnements doivent disposer d'un espace d'adressage IP RFC 1918 sans chevauchement.
Si les instances des environnements de développement et de test nécessitent un accès Internet, envisagez les options suivantes:
- Vous pouvez déployer Cloud NAT dans le même réseau du projet hôte du VPC partagé. Le déploiement dans le même réseau du projet hôte VPC partagé permet d'éviter que ces instances soient directement accessibles depuis Internet.
- Pour le trafic Web sortant, vous pouvez utiliser le proxy Web sécurisé. Le proxy offre plusieurs avantages.
Pour en savoir plus sur les outils et les fonctionnalités Google Cloud qui vous aident à créer, tester et déployer dans Google Cloud et dans des environnements hybrides et multicloud, consultez le blog DevOps et CI/CD sur Google Cloud expliqué.
Variantes
Pour répondre aux différentes exigences de conception, tout en tenant compte de toutes les exigences en termes de communication, le modèle d'architecture en miroir offre ces options, décrites dans les sections suivantes:
- VPC partagé par environnement
- Pare-feu centralisé de la couche application
- Topologie hub-and-spoke
- Architecture distribuée zéro confiance pour les microservices
VPC partagé par environnement
L'option de conception de VPC partagé par environnement permet de séparer les applications ou les services dans les environnements, y compris les outils CI/CD et d'administration qui peuvent être nécessaires pour répondre à certaines exigences de sécurité organisationnelles. Ces exigences limitent les communications, le domaine administratif et le contrôle des accès pour les différents services, qui doivent également être gérés par des équipes différentes.
Cette conception permet la séparation en assurant un isolement au niveau du réseau et du projet entre les différents environnements, ce qui permet une communication plus précise et le contrôle d'accès Identity and Access Management (IAM).
Du point de vue de la gestion et des opérations, cette conception offre la flexibilité nécessaire pour gérer les applications et les charges de travail créées par différentes équipes par environnement et par projet de service. Le réseau VPC et ses fonctionnalités de sécurité peuvent être provisionnés et gérés par les équipes d'exploitation réseau en fonction des structures suivantes :
- Une seule équipe gère tous les projets hôtes dans tous les environnements.
- Différentes équipes gèrent les projets hôtes dans leurs environnements respectifs.
Les décisions concernant la gestion des projets hôtes doivent être basées sur la structure de l'équipe, les opérations de sécurité et les exigences d'accès de chaque équipe. Vous pouvez appliquer cette variante de conception au réseau VPC partagé pour chaque option de conception de zone de destination d'environnement. Cependant, vous devez tenir compte des exigences de communication du modèle en miroir pour définir les communications autorisées entre les différents environnements, y compris la communication sur le réseau hybride.
Vous pouvez également provisionner un réseau VPC partagé pour chaque environnement principal, comme illustré dans le schéma suivant :
Pare-feu centralisé de la couche d'application
Dans certains cas, les exigences de sécurité peuvent nécessiter la prise en compte de la couche d'application (couche 7) et de l'inspection approfondie des paquets avec des mécanismes de pare-feu avancés qui dépassent les capacités de Cloud Next Generation Firewall. Pour répondre aux exigences et aux normes de sécurité de votre organisation, vous pouvez utiliser un pare-feu nouvelle génération hébergé dans un appareil virtuel de réseau (NVA). Plusieurs partenaires de sécurité Google Cloud proposent des options bien adaptées à cette tâche.
Comme illustré dans le schéma suivant, vous pouvez placer le NVA dans le chemin réseau entre le cloud privé virtuel et l'environnement informatique privé à l'aide de plusieurs interfaces réseau.
Cette conception peut également être utilisée avec plusieurs VPC partagés, comme illustré dans le schéma suivant.
Dans cette conception, la NVA sert de couche de sécurité périmétrique. Elle sert également de base pour activer l'inspection intégrée du trafic et appliquer des règles strictes de contrôle des accès.
Pour mettre en place une stratégie de sécurité multicouche robuste, incluant des règles de pare-feu VPC et des fonctionnalités de service de prévention des intrusions, intégrez une inspection et un contrôle de sécurité supplémentaires du trafic pour les flux de trafic est-ouest et nord-sud.
Topologie hub-and-spoke
Une autre variante de conception consiste à utiliser des VPC distincts (y compris des VPC partagés) pour vos étapes de développement et de test. Dans cette variante, comme illustré dans le schéma suivant, tous les environnements d'étape se connectent au VPC CI/CD et administratif dans une architecture hub-and-spoke. Utilisez cette option si vous devez séparer les domaines administratifs et les fonctions de chaque environnement. Le modèle de communication hub-and-spoke peut vous aider à répondre aux exigences suivantes :
- Les applications doivent accéder à un ensemble commun de services, tels que la surveillance, les outils de gestion de la configuration, les pipelines CI/CD ou l'authentification.
- Un ensemble commun de règles de sécurité doit être appliqué de manière centralisée au trafic entrant et sortant via le hub.
Pour en savoir plus sur les options de conception hub-and-spoke, consultez les pages Topologie hub-and-spoke avec serveurs centralisés et Topologie hub-and-spoke sans configuration centralisée des appareils mobiles.
Comme le montre le schéma précédent, la communication inter-VPC et la connectivité hybride passent toutes par le VPC hub. Dans le cadre de ce modèle, vous pouvez contrôler et limiter la communication au niveau du VPC hub pour répondre à vos besoins en connectivité.
Dans le cadre de l'architecture réseau hub-and-spoke, les options de connectivité principales (entre les spokes et les VPC hub) sont les suivantes sur Google Cloud:
- Appairage de réseaux VPC
- VPN
- Utiliser un dispositif virtuel de réseau (NVA)
- Avec plusieurs interfaces réseau
- Avec Network Connectivity Center (NCC)
Pour en savoir plus sur l'option à envisager dans votre conception, consultez la page Architecture de réseau hub et spoke. Un facteur déterminant dans la sélection d'un VPN via un appairage VPC entre les spokes et le VPC hub réside dans la nécessité de la transitivité du trafic. La transitivité du trafic signifie que le trafic provenant d'un spoke peut atteindre d'autres spokes via le hub.
Architecture distribuée zéro confiance pour les microservices
Les architectures hybrides et multicloud peuvent nécessiter plusieurs clusters pour atteindre leurs objectifs techniques et commerciaux, y compris la séparation de l'environnement de production des environnements de développement et de test. Par conséquent, les contrôles de sécurité du périmètre réseau sont importants, en particulier lorsqu'ils doivent respecter certaines exigences de sécurité.
Il ne suffit pas de répondre aux exigences de sécurité des architectures de microservices distribuées cloud-first actuelles. Vous devez également envisager d'utiliser des architectures distribuées zéro confiance. L'architecture distribuée de microservices zéro confiance prend en charge votre architecture de microservices grâce à l'application des règles de sécurité au niveau des microservices, à l'authentification et à l'identité de charge de travail. La confiance est basée sur l'identité et appliquée pour chaque service.
En utilisant une architecture de proxy distribuée, telle qu'un maillage de services, les services peuvent valider efficacement les appelants et implémenter des règles de contrôle d'accès précises pour chaque requête, ce qui permet de créer un environnement de microservices plus sécurisé et évolutif. Cloud Service Mesh vous permet de disposer d'un maillage commun couvrant vos déploiements Google Cloud et sur site. Le réseau maillé utilise des règles d'autorisation pour sécuriser les communications de service à service.
Vous pouvez également intégrer Apigee Adapter for Envoy, un déploiement léger de passerelle API Apigee dans un cluster Kubernetes, avec cette architecture. Apigee Adapter for Envoy est un edge en open source et un proxy de service conçu pour les applications cloud-first.
Pour plus d'informations à ce sujet, consultez les articles suivants:
- Architecture distribuée zéro confiance
- Environnement hybride GKE Enterprise
- Se connecter à Google
- Connecter un cluster GKE Enterprise sur site à un réseau Google Cloud
- Configurer un maillage multicloud ou hybride
- Déployez Cloud Service Mesh dans plusieurs environnements et clusters.
Bonnes pratiques concernant les modèles en miroir
Les systèmes CI/CD requis pour déployer ou reconfigurer des déploiements de production doivent assurer une haute disponibilité, ce qui signifie que tous les composants de l'architecture doivent être conçus pour fournir le niveau de disponibilité du système attendu. Pour plus d'informations, examinez la fiabilité de l'infrastructure Google Cloud.
Pour éliminer les erreurs de configuration pour les processus répétés tels que les mises à jour de code, l'automatisation est essentielle pour standardiser vos builds, tests et déploiements. Pour savoir comment utiliser divers contrôles et garde-fous lors de l'automatisation, consultez la section Automatiser vos déploiements.
L'intégration de NVA centralisées dans cette conception peut nécessiter l'incorporation de plusieurs segments avec des niveaux de contrôle d'accès de sécurité différents. Pour en savoir plus, consultez la page Dispositifs réseau centralisés sur Google Cloud.
Lors de la conception d'une solution incluant des NVA, il est important de prendre en compte leur haute disponibilité afin d'éviter un point de défaillance unique susceptible de bloquer toutes les communications. Suivez les conseils de votre fournisseur de NVA pour la conception et la mise en œuvre de la haute disponibilité et de la redondance. Pour en savoir plus, consultez la section Options d'architecture des dispositifs réseau centralisés sur Google Cloud afin d'obtenir une haute disponibilité entre les appliances virtuels.
En n'exportant pas les routes IP sur site via l'appairage VPC ou le VPN vers le VPC de développement et de test, vous pouvez limiter la joignabilité du réseau des environnements de développement et de test à l'environnement sur site. Pour en savoir plus, consultez la section Échange de routes personnalisées pour l'appairage de réseaux VPC.
Pour les charges de travail avec adressage IP privé pouvant nécessiter l'accès aux API de Google, vous pouvez exposer les API Google à l'aide d'un point de terminaison Private Service Connect au sein d'un réseau VPC. Pour plus d'informations, consultez la section Entrée contrôlée de cette série.
Consultez les bonnes pratiques générales pour les modèles d'architecture de réseau hybride et multicloud.