Le modèle mirrored (en miroir) repose 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/le déploiement continu (CI/CD) permet de déployer et de gérer les charges de travail dans tous les environnements informatiques ou dans des environnements spécifiques.
- La surveillance, la gestion de la configuration et les 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 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:
L'architecture du diagramme précédent est décrite comme suit :
- Les charges de travail sont distribuées en fonction des environnements fonctionnels (développement, test, CI/CD et outils administratifs) dans des VPC distincts sur le 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 administratifs. 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 informatique privé.
- Les règles de pare-feu n'autorisent que le trafic autorisé.
- Vous pouvez également utiliser Cloud Firewall nouvelle génération Enterprise avec le service de prévention des intrusions (IPS) pour implémenter l'inspection approfondie des paquets pour la prévention des menaces sans modifier la conception ni le routage. Cloud Next Generation Firewall Enterprise fonctionne en créant 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 en utilisant l'une des options de connectivité réseau hybride et multicloud 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 accessibilité au réseau privé entre les différents environnements de calcul. 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 Secure Web Proxy. Le proxy présente 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 trust 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. La mise en réseau VPC et ses fonctionnalités de sécurité peuvent être provisionnées et gérées par les équipes d'opérations réseau en fonction des structures possibles suivantes :
- Une é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 à 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 en miroir 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 la couche application
Dans certains scénarios, les exigences de sécurité peuvent nécessiter l'examen de la couche 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 dispositif NGFW hébergé dans un dispositif virtuel de réseau (NVA). Plusieurs partenaires de sécurité Google Cloudproposent des options adaptées à cette tâche.
Comme illustré dans le schéma suivant, vous pouvez placer l'appliance virtuelle réseau dans le chemin réseau entre le cloud privé virtuel et l'environnement de calcul 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é du périmètre. Il sert également de base pour activer l'inspection du trafic en ligne et appliquer des règles strictes de contrôle des accès.
Pour 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, incluez une inspection du trafic 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 possible consiste à utiliser des VPC distincts (y compris des VPC partagés) pour votre développement et vos 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 administratifs et les fonctions dans chaque environnement. Le modèle de communication en étoile 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, CI/CD ou l'authentification.
- Un ensemble commun de règles de sécurité doit être appliqué au trafic entrant et sortant de manière centralisée 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 entre les VPC et la connectivité hybride passent toutes par le VPC hub. Dans ce modèle, vous pouvez contrôler et restreindre la communication au niveau du VPC du hub pour l'adapter à vos exigences de connectivité.
Dans l'architecture réseau en étoile, les principales options de connectivité (entre les VPC spokes et hub) sur Google Cloudsont les suivantes :
- 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 savoir quelle option envisager dans votre conception, consultez 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. Les contrôles de sécurité du périmètre réseau sont donc importants, en particulier lorsqu'ils sont nécessaires pour répondre à certaines exigences de sécurité.
Il ne suffit pas de répondre aux exigences de sécurité des architectures de microservices distribuées actuelles axées sur le cloud. Vous devez également tenir compte des architectures distribuées zéro confiance. L'architecture distribuée zéro confiance des microservices est compatible avec votre architecture de microservices grâce à l'application des règles de sécurité, à l'authentification et à l'identité de 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 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 offre la flexibilité nécessaire pour disposer d'un maillage commun couvrant vos déploiementsGoogle Cloud et sur site. Le maillage utilise des règles d'autorisation pour sécuriser les communications de service à service.
Vous pouvez également intégrer Apigee Adapter for Envoy à cette architecture. Il s'agit d'un déploiement de passerelle API Apigee léger dans un cluster Kubernetes. Apigee Adapter for Envoy est un proxy de service et de périphérie Open Source conçu pour les applications cloud.
Pour en savoir plus sur ce sujet, consultez les articles suivants :
- Architecture distribuée zéro confiance
- Environnement hybride Google Kubernetes Engine (GKE)
- Se connecter à Google
- Connectez un cluster 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 déployer ou reconfigurer les déploiements de production doivent être disponibilité élevée, 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 en savoir plus, consultez Fiabilité de l'infrastructureGoogle 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 compilations, vos tests et vos déploiements.
- L'intégration de NVA centralisées dans cette conception peut nécessiter l'incorporation de plusieurs segments avec différents niveaux de contrôles d'accès à la 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 consignes de conception et d'implémentation de la haute disponibilité et de la redondance fournies par votre fournisseur 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 É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 Ingress contrôlé dans cette série.
- Consultez les bonnes pratiques générales pour les modèles d'architecture réseau hybride et multicloud.