Le modèle Entrée et sortie contrôlées combine l'entrée et la sortie contrôlées pour les scénarios qui exigent une utilisation bidirectionnelle d'API sélectionnées entre les charges de travail. Les charges de travail peuvent s'exécuter dans Google Cloud, dans des environnements privés sur site ou dans d'autres environnements cloud. Dans ce modèle, vous pouvez utiliser des passerelles API, des points de terminaison Private Service Connect ou des équilibreurs de charge pour exposer des API spécifiques et éventuellement fournir une authentification, une autorisation et des audits des appels d'API.
La principale différence entre ce modèle et le modèle en réseau maillé réside dans son application à des scénarios qui ne nécessitent que l'utilisation d'API bidirectionnelle ou la communication avec des sources et des destinations d'adresses IP spécifiques (par exemple, une application publiée via un point de terminaison Private Service Connect). Étant donné que la communication est limitée aux API exposées ou aux adresses IP spécifiques, les réseaux des environnements n'ont pas besoin d'être alignés dans votre conception. Voici quelques exemples courants de scénarios applicables (liste non exhaustive) :
- Fusions et acquisitions
- Intégrations d'applications avec des partenaires
- Intégrations entre les applications et les services d'une organisation avec différentes unités organisationnelles qui gèrent leurs propres applications et les hébergent dans différents environnements.
La communication fonctionne comme suit:
- Les charges de travail que vous déployez dans Google Cloud peuvent communiquer avec la passerelle API (ou des adresses IP de destination spécifiques) à l'aide d'adresses IP internes. 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 d'autres environnements informatiques peuvent communiquer avec la passerelle API côté Google Cloud(ou une adresse IP de point de terminaison publiée spécifique) à l'aide d'adresses IP internes. Les autres systèmes déployés dans Google Cloud ne sont pas accessibles.
Architecture
Le schéma suivant montre une architecture de référence pour le modèle d'entrée et de sortie contrôlées:
L'approche de conception du diagramme précédent comprend les éléments suivants:
- Du côté de Google Cloud , vous déployez des charges de travail dans un VPC (ou VPC partagé) sans les exposer directement à Internet.
- Le réseau de l'environnement Google Cloud s'étend à d'autres environnements informatiques. Cet environnement peut être sur site ou dans un autre cloud. Pour étendre l'environnement, utilisez un modèle de communication de connectivité hybride et multicloud approprié pour faciliter la communication entre les environnements afin qu'ils puissent utiliser des adresses IP internes.
- Vous pouvez éventuellement utiliser un VPC de transit pour ajouter une couche de sécurité de périmètre en dehors du VPC de votre application en activant l'accès à des adresses IP cibles spécifiques.
- Vous pouvez utiliser Cloud Next Generation Firewall ou des appliances réseau virtuels (NVA) avec des pare-feu de nouvelle génération (NGFW) au niveau du VPC de transit pour inspecter le trafic et autoriser ou interdire l'accès à certaines API à partir de sources spécifiques avant d'atteindre votre VPC d'application.
- Les API doivent être accessibles via une passerelle API ou un équilibreur de charge pour fournir une couche proxy, ainsi qu'une abstraction ou une façade pour vos API de service.
- Pour les applications consommées en tant qu'API, vous pouvez également utiliser Private Service Connect pour fournir une adresse IP interne à l'application publiée.
- Tous les environnements utilisent un espace d'adressage IP RFC 1918 sans chevauchement.
Une application courante de ce modèle consiste à déployer des backends d'application (ou un sous-ensemble de backends d'application) dans Google Cloud , tout en hébergeant d'autres composants backend et frontend dans des environnements sur site ou dans d'autres clouds (modèle hybride à niveaux ou modèle multicloud partitionné). À mesure que les applications évoluent et migrent vers le cloud, des dépendances et des préférences pour des services cloud spécifiques émergent souvent.
Parfois, ces dépendances et préférences entraînent la distribution d'applications et de backends sur différents fournisseurs cloud. De plus, certaines applications peuvent être créées avec une combinaison de ressources et de services distribués dans des environnements sur site et plusieurs environnements cloud.
Pour les applications distribuées, les fonctionnalités de la connectivité hybride et multicloud Cloud Load Balancing externe peuvent être utilisées pour mettre fin aux requêtes des utilisateurs et les acheminer vers des frontends ou des backends dans d'autres environnements. Ce routage s'effectue via une connexion réseau hybride, comme illustré dans le schéma suivant. Cette intégration permet de distribuer progressivement les composants d'application dans différents environnements. Les requêtes du frontend vers les services backend hébergés dans Google Cloud communiquent de manière sécurisée via la connexion réseau hybride établie, facilitée par un équilibreur de charge interne (ILB dans le diagramme).
La conception Google Cloud du diagramme précédent vous aide à:
- Facilite la communication bidirectionnelle entre Google Cloud, sur site et d'autres environnements cloud à l'aide d'API prédéfinies des deux côtés, qui correspondent au modèle de communication de ce modèle.
- Pour fournir des interfaces utilisateur globales pour les applications exposées sur Internet avec des composants d'application distribués (interfaces utilisateur ou backends) et pour atteindre les objectifs suivants, vous pouvez utiliser les fonctionnalités avancées d'équilibrage de charge et de sécurité de Google Cloud distribués dans des points de présence (PoP):
- Réduisez vos dépenses d'investissement et simplifiez vos opérations grâce aux services gérés sans serveur.
- Optimisez les connexions aux backends d'application de manière globale pour améliorer la vitesse et la latence.
- Le réseau multicloudGoogle Cloudpermet la communication multicloud entre les composants d'application via des connexions privées optimales.
- Mettez en cache le contenu statique à forte demande et améliorez les performances des applications qui utilisent Cloud Load Balancing global en leur donnant accès à Cloud CDN.
- Sécurisez les frontends globaux des applications exposées sur Internet à l'aide des fonctionnalités de Google Cloud Armor qui fournissent des services de pare-feu d'application Web (WAF) et d'atténuation des attaques DDoS distribués à l'échelle mondiale.
- Vous pouvez également intégrer Private Service Connect à votre conception. Vous bénéficiez ainsi d'un accès privé et précis aux API de service Google Cloud ou à vos services publiés à partir d'autres environnements, sans passer par l'Internet public.
Variantes
Les modèles d'architecture sortie contrôlée et entrée contrôlée peuvent être combinés à d'autres approches pour répondre à différentes exigences de conception, tout en tenant compte des exigences de communication de ce modèle. Les modèles proposent les options suivantes:
- Passerelles API distribuées
- Communication bidirectionnelle des API à l'aide de Private Service Connect
- Communication bidirectionnelle à l'aide de points de terminaison et d'interfaces Private Service Connect
Passerelles API distribuées
Dans des scénarios comme celui basé sur le modèle multicloud partitionné, les applications (ou composants d'application) peuvent être créées dans différents environnements cloud, y compris un environnement privé sur site. L'exigence courante consiste à acheminer les requêtes client vers l'interface de l'application directement vers l'environnement dans lequel l'application (ou le composant de frontend) est hébergée. Ce type de communication nécessite un équilibreur de charge local ou une passerelle d'API. Ces applications et leurs composants peuvent également nécessiter des fonctionnalités de plate-forme d'API spécifiques pour l'intégration.
Le diagramme suivant montre comment Apigee et Apigee Hybrid sont conçus pour répondre à ces exigences avec une passerelle API localisée dans chaque environnement. La gestion de la plate-forme d'API est centralisée dans Google Cloud. Cette conception permet de mettre en œuvre des mesures de contrôle des accès strictes, où seules les adresses IP préapprouvées (API de destination et de cible ou adresses IP de point de terminaison Private Service Connect) peuvent communiquer entre Google Cloud et les autres environnements.
La liste suivante décrit les deux chemins de communication distincts du diagramme précédent qui utilisent la passerelle API Apigee:
- Les requêtes client arrivent directement dans l'environnement qui héberge l'application (ou le composant d'interface) à l'interface de l'application.
- Les passerelles API et les proxys de chaque environnement gèrent les requêtes d'API client et d'application dans différentes directions dans plusieurs environnements.
- La fonctionnalité API Gateway de Google Cloud(Apigee) expose les composants de l'application (frontend ou backend) hébergés dans Google Cloud.
- La fonctionnalité de passerelle API dans un autre environnement (hybride) expose les composants de l'interface de l'application (ou du backend) hébergés dans cet environnement.
Vous pouvez également envisager d'utiliser un VPC de transit. Un VPC de transit peut offrir la flexibilité nécessaire pour séparer les problèmes et effectuer une inspection de sécurité et une connectivité hybride dans un réseau VPC distinct. Du point de vue de la joignabilité des adresses IP, un VPC de transit (où la connectivité hybride est associée) facilite les exigences suivantes pour maintenir la joignabilité de bout en bout:
- Les adresses IP des API cibles doivent être annoncées aux autres environnements où les clients/demandeurs sont hébergés.
- Les adresses IP des hôtes qui doivent communiquer avec les API cibles doivent être annoncées à l'environnement dans lequel se trouve l'API cible (par exemple, les adresses IP de l'appelant de l'API, le client). L'exception se produit lorsque la communication se produit via un équilibreur de charge, un proxy, un point de terminaison Private Service Connect ou une instance NAT.
Pour étendre la connectivité à l'environnement distant, cette conception utilise l'appairage VPC direct avec la fonctionnalité d'échange de routes client. La conception permet de router les requêtes API spécifiques provenant de charges de travail hébergées dans le VPC d'application Google Cloud via le VPC de transit. Vous pouvez également utiliser un point de terminaison Private Service Connect dans le VPC de l'application associé à un équilibreur de charge avec un backend de groupe de points de terminaison réseau hybride dans le VPC de transit. Cette configuration est décrite dans la section suivante: Communication bidirectionnelle des API à l'aide de Private Service Connect.
Communication bidirectionnelle des API à l'aide de Private Service Connect
Il peut arriver que les entreprises n'aient pas besoin d'utiliser immédiatement une passerelle API (comme Apigee) ou qu'elles souhaitent l'ajouter plus tard. Toutefois, des exigences métier peuvent être nécessaires pour permettre la communication et l'intégration entre certaines applications dans différents environnements. Par exemple, si votre entreprise a racheté une autre entreprise, vous devrez peut-être exposer certaines applications à cette entreprise. Il se peut qu'elle ait besoin d'exposer des applications à votre entreprise. Les deux entreprises peuvent chacune disposer de leurs propres charges de travail hébergées dans différents environnements (Google Cloud, sur site ou dans d'autres clouds) et doivent éviter les chevauchements d'adresses IP. Dans ce cas, vous pouvez utiliser Private Service Connect pour faciliter une communication efficace.
Pour les applications consommées en tant qu'API, vous pouvez également utiliser Private Service Connect pour fournir une adresse privée aux applications publiées, ce qui permet d'accéder de manière sécurisée au réseau privé dans les régions et via une connectivité hybride. Cette abstraction facilite l'intégration des ressources de divers clouds et environnements sur site via un modèle de connectivité hybride et multicloud. Elle permet également d'assembler des applications dans des environnements multicloud et sur site. Cela peut répondre à différentes exigences de communication, comme l'intégration d'applications sécurisées où une passerelle API n'est pas utilisée ou n'est pas prévue.
En utilisant Private Service Connect avec Cloud Load Balancing, comme illustré dans le schéma suivant, vous pouvez obtenir deux parcours de communication distincts. Chaque chemin est lancé à partir d'une direction différente pour un objectif de connectivité distinct, idéalement via des appels d'API.
- Toutes les considérations et recommandations de conception de Private Service Connect abordées dans ce guide s'appliquent à cette conception.
- Si une inspection de couche 7 supplémentaire est requise, vous pouvez intégrer des NVA à cette conception (au niveau du VPC de transit).
- Cette conception peut être utilisée avec ou sans passerelles API.
Les deux chemins de connectivité représentés dans le schéma précédent représentent des connexions indépendantes et n'illustrent pas la communication bidirectionnelle d'une seule connexion ou d'un seul flux.
Communication bidirectionnelle à l'aide de points de terminaison et d'interfaces Private Service Connect
Comme indiqué dans le modèle d'entrée contrôlée, l'une des options permettant d'activer la communication client-service consiste à utiliser un point de terminaison Private Service Connect pour exposer un service dans un VPC producteur à un VPC consommateur. Cette connectivité peut être étendue à un environnement sur site ou même à un autre environnement de fournisseur cloud via une connectivité hybride. Toutefois, dans certains cas, le service hébergé peut également nécessiter une communication privée.
Pour accéder à un service donné, comme récupérer des données à partir de sources de données pouvant être hébergées dans le VPC client ou en dehors de celui-ci, cette communication privée peut s'établir entre le VPC de l'application (producteur) et un environnement distant, tel qu'un environnement sur site.
Dans ce cas, les interfaces Private Service Connect permettent à une instance de VM de producteur de services d'accéder au réseau d'un client. Pour ce faire, il partage une interface réseau, tout en maintenant la séparation des rôles de producteur et de consommateur. Avec cette interface réseau dans le VPC consommateur, la VM de l'application peut accéder aux ressources du consommateur comme si elles résidaient localement dans le VPC producteur.
Une interface Private Service Connect est une interface réseau associée au VPC consommateur (de transit). Il est possible d'atteindre des destinations externes accessibles depuis le VPC client (de transit) auquel l'interface Private Service Connect est associée. Par conséquent, cette connexion peut être étendue à un environnement externe via une connectivité hybride, telle qu'un environnement sur site, comme illustré dans le schéma suivant:
Si le VPC consommateur est une organisation ou une entité externe, comme une organisation tierce, vous ne pourrez généralement pas sécuriser la communication avec l'interface Private Service Connect dans le VPC consommateur. Dans ce cas, vous pouvez définir des règles de sécurité dans l'OS invité de la VM d'interface Private Service Connect. Pour en savoir plus, consultez la section Configurer la sécurité pour les interfaces Private Service Connect. Vous pouvez également envisager une autre approche si elle ne respecte pas les normes ou la conformité de sécurité de votre organisation.
Bonnes pratiques
Dans les cas où les requêtes client provenant d'Internet doivent être reçues localement par une interface d'application hébergée dans un environnement cloud privé sur site ou autre environnement cloud, envisagez d'utiliser Hybrid comme solution de passerelle API.
- Cette approche facilite également la migration de la solution vers un environnement entièrement hébergé par Google Cloud, tout en préservant la cohérence de la plate-forme d'API (Apigee).
Pour minimiser la latence et optimiser les coûts des transferts de données sortants volumineux vers vos autres environnements lorsque ces environnements sont configurés en mode hybride ou multicloud à long terme ou de manière permanente, tenez compte des points suivants:
- Utilisez Cloud Interconnect ou interconnexion cross-cloud.
- Pour interrompre les connexions utilisateur au frontend ciblé dans l'environnement approprié, utilisez Hybrid.
Le cas échéant, utilisez Apigee Adapter for Envoy avec un déploiement hybride avec Kubernetes.
Avant de concevoir les chemins de connectivité et de routage, vous devez d'abord identifier le trafic ou les requêtes d'API à diriger vers une passerelle API locale ou distante, ainsi que les environnements source et de destination.
Utilisez VPC Service Controls pour protéger les services Google Cloud dans vos projets et limiter le risque d'exfiltration de données en spécifiant des périmètres de service au niveau du projet ou du réseau VPC.
- Vous pouvez étendre les périmètres de service à un environnement hybride via un VPN ou Cloud Interconnect autorisé. Pour en savoir plus sur les avantages des périmètres de service, consultez la page Présentation de VPC Service Controls.
Utilisez des règles de pare-feu de cloud privé virtuel (VPC) ou des stratégies de pare-feu pour contrôler l'accès au niveau du réseau aux ressources Private Service Connect via le point de terminaison Private Service Connect. Par exemple, les règles de pare-feu sortantes au niveau du VPC de l'application (client) peuvent restreindre l'accès des instances de VM à l'adresse IP ou au sous-réseau de vos points de terminaison.
Lorsque vous utilisez une interface Private Service Connect, vous devez protéger la communication avec l'interface en configurant la sécurité pour l'interface Private Service Connect.
Si une charge de travail dans un sous-réseau privé nécessite un accès à Internet, utilisez Cloud NAT pour éviter d'attribuer une adresse IP externe à la charge de travail et de l'exposer à l'Internet public.
- Pour le trafic Web sortant, utilisez le proxy Web sécurisé. Le proxy présente plusieurs avantages.
Consultez les bonnes pratiques générales pour les modèles de réseautage hybride et multicloud.