Le modèle miroité consiste à répliquer la conception d'un ou de plusieurs environnements existants dans un ou plusieurs environnements nouveaux. 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 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/le déploiement continus (CI/CD) permettent de déployer et de gérer des charges de travail dans tous les environnements informatiques ou dans des environnements spécifiques.
- La surveillance, la gestion de la configuration et d'autres systèmes d'administration doivent fonctionner dans plusieurs environnements informatiques.
- Les charges de travail ne peuvent pas communiquer directement entre les différents environnements informatiques. Si nécessaire, la communication doit être pré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 diagramme 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 d'administration) sur des VPC distincts à côté. Google Cloud
- Le VPC partagé est utilisé pour les charges de travail de développement et de test. Un VPC supplémentaire est utilisé pour les outils CI/CD et d'administration. Avec les VPC partagés :
- Les applications sont gérées par différentes équipes par environnement et par projet de service.
- Le projet hôte administre et contrôle les communications réseau et les contrôles de sécurité entre les environnements de développement et de test, ainsi qu'en dehors du VPC.
- Le VPC CI/CD est connecté au réseau exécutant les charges de travail de production dans votre environnement IT 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 (IPS) pour implémenter une inspection approfondie des paquets afin de prévenir les menaces sans modifier la conception ni 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 de 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 discutées qui répondent aux exigences de votre entreprise et de vos applications. Pour vous permettre de déployer et de gérer des charges de travail de production, cette connexion offre une connectivité réseau privée 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 de projet hôte VPC partagé. Le déploiement dans le même réseau de projet hôte de VPC partagé permet d'éviter de rendre ces instances directement accessibles depuis Internet.
- Pour le trafic Web sortant, vous pouvez utiliser le proxy Web sécurisé. Le proxy présente plusieurs avantages.
Pour en savoir plus sur les Google Cloud outils et fonctionnalités 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 la communication, le domaine administratif et le contrôle des accès pour différents services qui doivent également être gérés par différentes équipes.
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 des équipes d'exploitation réseau en fonction des structures possibles 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 variation de conception à l'option de conception de la zone de destination "Réseau VPC partagé pour chaque environnement". Toutefois, vous devez tenir compte des exigences de communication du modèle miroité pour définir les communications autorisées entre les différents environnements, y compris les communications 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 couche application
Dans certains cas, les exigences de sécurité peuvent nécessiter de prendre en compte la couche application (couche 7) et l'inspection approfondie des paquets avec des mécanismes de pare-feu avancés qui dépassent les capacités de Cloud NGFW. Pour répondre aux exigences et normes de sécurité de votre organisation, vous pouvez utiliser un dispositif NGFW hébergé dans un dispositif virtuel de réseau (NVA). Plusieurs Google Cloud partenaires de sécurité proposent des options 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 d'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, le NVA sert de couche de sécurité du périmètre. Il sert également de base pour activer l'inspection du trafic en ligne et appliquer des règles de contrôle d'accès strictes.
Pour une stratégie de sécurité multicouche robuste qui inclut des règles de pare-feu VPC et des fonctionnalités de service de prévention des intrusions, incluez une inspection et un contrôle de sécurité supplémentaires pour les flux de trafic est-ouest et nord-sud.
Topologie en étoile
Une autre variante de conception consiste à utiliser des VPC distincts (y compris des VPC partagés) pour le développement et les différentes étapes 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 d'administration et les fonctions dans chaque environnement. Le modèle de communication en hub et 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, l'intégration et la livraison continues (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 indiqué dans 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 du hub pour qu'elle corresponde à vos exigences de connectivité.
Dans le cadre de l'architecture réseau en hub et spoke, voici les principales options de connectivité (entre les spokes et les VPC hub) sur Google Cloud:
- Appairage de réseaux VPC
- VPN
- À l'aide d'un dispositif virtuel de réseau (NVA)
- Avec plusieurs interfaces réseau
- Avec le Network Connectivity Center (NCC)
Pour en savoir plus sur l'option à envisager pour 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 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 en séparant 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 sont nécessaires pour 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 des architectures distribuées zéro confiance. L'architecture distribuée de microservices zéro confiance est compatible avec votre architecture de microservices grâce à l'application des règles de sécurité, à l'authentification et à l'identité de la charge de travail au niveau des microservices. 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 service mesh, les services peuvent valider efficacement les appelants et implémenter des règles de contrôle des 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 pouvant couvrir vos déploiementsGoogle 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, qui est un déploiement léger de la passerelle API Apigee dans un cluster Kubernetes, avec cette architecture. Apigee Adapter for Envoy est un proxy de service et de périphérie Open Source conçu pour les applications cloud first.
Pour en savoir plus sur 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éseauGoogle Cloud
- Configurer un maillage multicloud ou hybride
- Déployez Cloud Service Mesh dans différents environnements et clusters.
Bonnes pratiques concernant les motifs en miroir
- Les systèmes CI/CD requis pour le déploiement ou la reconfiguration des déploiements de production doivent être hautement disponibles, ce qui signifie que tous les composants de l'architecture doivent être conçus pour fournir le niveau de disponibilité système attendu. Pour en savoir plus, consultez la section Fiabilité de l'infrastructureGoogle Cloud .
- Pour éliminer les erreurs de configuration pour des processus répétés tels que les mises à jour de code, l'automatisation est essentielle pour standardiser vos compilations, tests et déploiements.
- L'intégration de NVA centralisées dans cette conception peut nécessiter l'intégration de plusieurs segments avec différents niveaux de contrôle d'accès de sécurité.
- Lorsque vous concevez une solution qui inclut des NVA, il est important de prendre en compte la haute disponibilité (HD) des NVA pour éviter un point de défaillance unique qui pourrait bloquer toute communication. Suivez les conseils de conception et d'implémentation de la haute disponibilité et de la redondance fournis par votre fournisseur de NVA.
- 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 avec 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 en savoir plus, 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 réseau hybride et multicloud.