Beim Muster Gated Egress und Gated Ingress wird eine Kombination aus Gated Egress und Gated Ingress für Szenarien verwendet, in denen ausgewählte APIs bidirektional zwischen Arbeitslasten verwendet werden müssen. Arbeitslasten können in Google Cloud, in privaten lokalen Umgebungen oder in anderen Cloud-Umgebungen ausgeführt werden. Bei diesem Muster können Sie API-Gateways, Private Service Connect-Endpunkte oder Load Balancer verwenden, um bestimmte APIs bereitzustellen und optional Authentifizierung, Autorisierung und Prüfungen von API-Aufrufen zu ermöglichen.
Der Hauptunterschied zwischen diesem Muster und dem Mesh-Muster besteht darin, dass es für Szenarien verwendet wird, in denen nur eine bidirektionale API-Nutzung oder Kommunikation mit bestimmten IP‑Adressenquellen und ‑zielen erforderlich ist, z. B. für eine Anwendung, die über einen Private Service Connect-Endpunkt veröffentlicht wird. Da die Kommunikation auf die freigegebenen APIs oder bestimmten IP-Adressen beschränkt ist, müssen die Netzwerke in den Umgebungen in Ihrem Design nicht übereinstimmen. Zu den gängigen Anwendungsfällen gehören unter anderem:
- Fusionen und Übernahmen
- Anwendungsintegrationen mit Partnern
- Integrationen zwischen Anwendungen und Diensten einer Organisation mit verschiedenen Organisationseinheiten, die ihre eigenen Anwendungen verwalten und in verschiedenen Umgebungen hosten.
So funktioniert die Kommunikation:
- Von Ihnen in Google Cloud bereitgestellte Arbeitslasten können über interne IP-Adressen mit dem API-Gateway (oder bestimmten Ziel-IP-Adressen) kommunizieren. Andere in der privaten Rechenumgebung bereitgestellte Systeme sind nicht erreichbar.
- Umgekehrt können Arbeitslasten, die in anderen Rechenumgebungen bereitgestellt sind, über interne IP-Adressen mit dem API-Gateway von Google Cloud (oder einer bestimmten veröffentlichten Endpunkt-IP-Adresse) kommunizieren. Andere in Google Cloud bereitgestellte Systeme sind nicht erreichbar.
Architektur
Das folgende Diagramm zeigt eine Referenzarchitektur für das Muster „Gated Egress“ und „Gated Ingress“:
Der Designansatz im vorherigen Diagramm umfasst die folgenden Elemente:
- In Google Cloud stellen Sie Arbeitslasten in einer VPC (oder einer freigegebenen VPC) bereit, ohne sie direkt dem Internet zu präsentieren.
- Das Netzwerk der Google Cloud-Umgebung wird auf andere Rechenumgebungen erweitert. Diese Umgebung kann lokal oder in einer anderen Cloud sein. Verwenden Sie zum Erweitern der Umgebung ein geeignetes Kommunikationsmuster für Hybrid- und Multi-Cloud-Konnektivität, um die Kommunikation zwischen den Umgebungen zu erleichtern, damit interne IP-Adressen verwendet werden können.
- Optional können Sie mit einer Transit-VPC eine Perimeter-Sicherheitsebene außerhalb Ihrer Anwendungs-VPC hinzufügen, indem Sie den Zugriff auf bestimmte Ziel-IP-Adressen zulassen.
- Sie können Cloud Next Generation Firewall oder Network Virtual Appliances (NVAs) mit Next Generation Firewalls (NGFWs) im Transit-VPC verwenden, um Traffic zu prüfen und den Zugriff auf bestimmte APIs aus bestimmten Quellen zuzulassen oder zu verweigern, bevor er Ihre Anwendungs-VPC erreicht.
- Der Zugriff auf APIs sollte über ein API-Gateway oder einen Load Balancer erfolgen, um eine Proxy-Ebene und eine Abstraktion oder Fassade für Ihre Dienst-APIs bereitzustellen.
- Für Anwendungen, die als APIs genutzt werden, können Sie auch Private Service Connect verwenden, um eine interne IP-Adresse für die veröffentlichte Anwendung anzugeben.
- Alle Umgebungen nutzen einen sich nicht überschneidenden IP-Adressbereich nach RFC 1918.
Eine gängige Anwendung dieses Musters besteht darin, Anwendungs-Back-Ends (oder einen Teil der Anwendungs-Back-Ends) in Google Cloud bereitzustellen und andere Back-End- und Frontend-Komponenten in lokalen Umgebungen oder in anderen Clouds zu hosten (gestuftes Hybridmuster oder partitioniertes Multi-Cloud-Muster). Wenn sich Anwendungen weiterentwickeln und in die Cloud migrieren, entstehen häufig Abhängigkeiten und Präferenzen für bestimmte Cloud-Dienste.
Manchmal führen diese Abhängigkeiten und Präferenzen dazu, dass Anwendungen und Back-Ends auf verschiedene Cloud-Anbieter verteilt werden. Außerdem können einige Anwendungen mit einer Kombination aus Ressourcen und Diensten erstellt werden, die auf On-Premises-Umgebungen und mehreren Cloud-Umgebungen verteilt sind.
Bei verteilten Anwendungen können die Funktionen der externen Cloud Load Balancing-Hybrid- und Multi-Cloud-Konnektivität verwendet werden, um Nutzeranfragen zu beenden und an Front- oder Back-Ends in anderen Umgebungen weiterzuleiten. Dieses Routing erfolgt über eine Hybridnetzwerkverbindung, wie im folgenden Diagramm dargestellt. Diese Integration ermöglicht die schrittweise Bereitstellung von Anwendungskomponenten in verschiedenen Umgebungen. Anfragen vom Frontend an Backend-Dienste, die in Google Cloud gehostet werden, kommunizieren sicher über die eingerichtete Hybridnetzwerkverbindung, die von einem internen Load Balancer (ILB im Diagramm) unterstützt wird.
Das Google Cloud-Design im vorherigen Diagramm bietet folgende Vorteile:
- Ermöglicht die bidirektionale Kommunikation zwischen Google Cloud, lokalen und anderen Cloud-Umgebungen mithilfe vordefinierter APIs auf beiden Seiten, die dem Kommunikationsmodell dieses Musters entsprechen.
- Wenn Sie globale Frontends für internetfähige Anwendungen mit verteilten Anwendungskomponenten (Frontends oder Backends) bereitstellen und die folgenden Ziele erreichen möchten, können Sie die erweiterten Load Balancing- und Sicherheitsfunktionen von Google Cloud nutzen, die an Points of Presence (PoPs) bereitgestellt werden:
- Mit serverlosen verwalteten Diensten können Sie den Kapitalaufwand senken und den Betrieb vereinfachen.
- Verbindungen zu Anwendungs-Backends global hinsichtlich Geschwindigkeit und Latenz optimieren.
- Das cloudübergreifende Netzwerk von Google Cloud ermöglicht die Multi-Cloud-Kommunikation zwischen Anwendungskomponenten über optimale private Verbindungen.
- Sie können statische Inhalte mit hoher Nachfrage im Cache speichern und die Anwendungsleistung für Anwendungen mit globalem Cloud Load Balancing verbessern, indem Sie Zugriff auf Cloud CDN gewähren.
- Schützen Sie die globalen Frontends der internetfähigen Anwendungen mit den Funktionen von Google Cloud Armor, die global verteilte Web Application Firewalls (WAFs) und DDoS-Abwehrdienste bereitstellen.
- Optional können Sie Private Service Connect in Ihr Design einbinden. So wird ein privater, detaillierter Zugriff auf Google Cloud-Dienst-APIs oder Ihre veröffentlichten Dienste aus anderen Umgebungen ermöglicht, ohne das öffentliche Internet zu nutzen.
Varianten
Die Architekturmuster für gatewaygesteuerten ausgehenden und eingehenden Traffic können mit anderen Ansätzen kombiniert werden, um verschiedene Designanforderungen zu erfüllen, die dennoch die Kommunikationsanforderungen dieses Musters berücksichtigen. Die Muster bieten folgende Optionen:
- Verteilte API-Gateways
- Bidirektionale API-Kommunikation mit Private Service Connect
- Bidirektionale Kommunikation über Private Service Connect-Endpunkte und ‑Schnittstellen
Verteilte API-Gateways
In Szenarien wie dem, das auf dem Muster partitionierte Multi-Cloud basiert, können Anwendungen (oder Anwendungskomponenten) in verschiedenen Cloudumgebungen erstellt werden, einschließlich einer privaten lokalen Umgebung. In der Regel sollen Clientanfragen direkt an das Anwendungs-Frontend weitergeleitet werden, also an die Umgebung, in der die Anwendung (oder die Frontend-Komponente) gehostet wird. Für diese Art der Kommunikation ist ein lokaler Load Balancer oder ein API-Gateway erforderlich. Für diese Anwendungen und ihre Komponenten sind möglicherweise auch bestimmte Funktionen der API-Plattform erforderlich.
Das folgende Diagramm zeigt, wie Apigee und Apigee Hybrid mit einem lokalisierten API-Gateway in jeder Umgebung auf solche Anforderungen reagieren. Die API-Plattformverwaltung erfolgt zentral in Google Cloud. Dieses Design trägt dazu bei, strenge Zugriffssteuerungsmaßnahmen durchzusetzen, bei denen nur vorab genehmigte IP-Adressen (Ziel- und Ziel-APIs oder Private Service Connect-Endpunkt-IP-Adressen) zwischen Google Cloud und den anderen Umgebungen kommunizieren können.
In der folgenden Liste werden die beiden verschiedenen Kommunikationspfade im vorherigen Diagramm beschrieben, die das Apigee API-Gateway verwenden:
- Clientanfragen erreichen das Frontend der Anwendung direkt in der Umgebung, in der die Anwendung (oder die Frontendkomponente) gehostet wird.
- API-Gateways und Proxys in jeder Umgebung verarbeiten Client- und Anwendungs-API-Anfragen in verschiedene Richtungen über mehrere Umgebungen hinweg.
- Die API-Gateway-Funktion in Google Cloud (Apigee) stellt die Anwendungskomponenten (Frontend oder Backend) bereit, die in Google Cloud gehostet werden.
- Die API-Gateway-Funktionen in einer anderen Umgebung (Hybrid) stellen die Frontend- (oder Backend-)Komponenten der Anwendung bereit, die in dieser Umgebung gehostet werden.
Alternativ können Sie eine Transit-VPC verwenden. Ein Transit-VPC kann Flexibilität bieten, um Bedenken zu trennen und Sicherheitsprüfungen und Hybridkonnektivität in einem separaten VPC-Netzwerk durchzuführen. Aus Sicht der Erreichbarkeit von IP-Adressen erfüllt ein Transit-VPC (an das die Hybridkonnektivität angeschlossen ist) die folgenden Anforderungen, um die End-to-End-Erreichbarkeit aufrechtzuerhalten:
- Die IP-Adressen für Ziel-APIs müssen in den anderen Umgebungen beworben werden, in denen Clients/Anfragen gehostet werden.
- Die IP-Adressen der Hosts, die mit den Ziel-APIs kommunizieren müssen, müssen in der Umgebung bekannt gemacht werden, in der sich die Ziel-API befindet. Dazu gehören beispielsweise die IP-Adressen des API-Anfragers (des Clients). Eine Ausnahme besteht, wenn die Kommunikation über einen Load Balancer, Proxy, Private Service Connect-Endpunkt oder eine NAT-Instanz erfolgt.
Um die Konnektivität mit der Remote-Umgebung zu erweitern, wird in diesem Design Direct VPC-Peering mit Kunden-Routen-Austausch verwendet. Das Design ermöglicht es, bestimmte API-Anfragen, die von Workloads stammen, die in der Google Cloud-Anwendungs-VPC gehostet werden, über die Transit-VPC zu leiten. Alternativ können Sie einen Private Service Connect-Endpunkt im VPC der Anwendung verwenden, der mit einem Load Balancer mit einem Hybrid-Netzwerk-Endpunktgruppen-Back-End im Transit-VPC verknüpft ist. Diese Einrichtung wird im nächsten Abschnitt beschrieben: Bidirektionale API-Kommunikation mit Private Service Connect.
Bidirektionale API-Kommunikation mit Private Service Connect
Manchmal müssen Unternehmen kein API-Gateway (z. B. Apigee) sofort verwenden oder möchten es später hinzufügen. Es kann jedoch geschäftliche Anforderungen geben, die die Kommunikation und Integration zwischen bestimmten Anwendungen in verschiedenen Umgebungen erfordern. Wenn Ihr Unternehmen beispielsweise ein anderes Unternehmen übernommen hat, müssen Sie möglicherweise bestimmte Anwendungen für dieses Unternehmen freigeben. Möglicherweise muss er Apps für Ihr Unternehmen freigeben. Beide Unternehmen haben möglicherweise jeweils eigene Arbeitslasten, die in verschiedenen Umgebungen gehostet werden (Google Cloud, lokal oder in anderen Clouds). Dabei muss eine Überschneidung von IP-Adressen vermieden werden. In solchen Fällen können Sie Private Service Connect verwenden, um eine effektive Kommunikation zu ermöglichen.
Für Anwendungen, die als APIs genutzt werden, können Sie auch Private Service Connect verwenden, um eine private Adresse für die veröffentlichten Anwendungen bereitzustellen. So wird ein sicherer Zugriff innerhalb des privaten Netzwerks über Regionen und über Hybridkonnektivität ermöglicht. Diese Abstraktion ermöglicht die Einbindung von Ressourcen aus verschiedenen Clouds und lokalen Umgebungen über ein Hybrid- und Multi-Cloud-Konnektivitätsmodell. Außerdem ermöglicht es die Zusammenstellung von Anwendungen in Multi-Cloud- und On-Premises-Umgebungen. So lassen sich unterschiedliche Kommunikationsanforderungen erfüllen, z. B. die Einbindung sicherer Anwendungen, bei denen kein API-Gateway verwendet wird oder verwendet werden soll.
Wenn Sie Private Service Connect mit Cloud Load Balancing verwenden, wie im folgenden Diagramm dargestellt, können Sie zwei unterschiedliche Kommunikationspfade nutzen. Jeder Pfad wird aus einer anderen Richtung für einen separaten Verbindungszweck gestartet, idealerweise über API-Aufrufe.
- Alle in diesem Leitfaden beschriebenen Designüberlegungen und Empfehlungen für Private Service Connect gelten für dieses Design.
- Wenn eine zusätzliche Layer-7-Prüfung erforderlich ist, können Sie NVAs in dieses Design (im Transit-VPC) einbinden.
- Dieses Design kann mit oder ohne API-Gateways verwendet werden.
Die beiden im vorherigen Diagramm dargestellten Konnektivitätspfade stellen unabhängige Verbindungen dar und zeigen keine bidirektionale Kommunikation einer einzelnen Verbindung oder eines einzelnen Flusses.
Bidirektionale Kommunikation über Private Service Connect-Endpunkte und ‑Schnittstellen
Wie im Abschnitt zum Gated Ingress-Muster erläutert, besteht eine Möglichkeit zur Aktivierung der Client-Dienstkommunikation darin, einen Dienst in einem Ersteller-VPC über einen Private Service Connect-Endpunkt für ein Nutzer-VPC verfügbar zu machen. Diese Konnektivität kann über eine hybride Konnektivität auf eine lokale Umgebung oder sogar auf eine Umgebung eines anderen Cloud-Anbieters erweitert werden. In einigen Fällen kann für den gehosteten Dienst jedoch auch eine private Kommunikation erforderlich sein.
Für den Zugriff auf einen bestimmten Dienst, z. B. zum Abrufen von Daten aus Datenquellen, die innerhalb oder außerhalb der VPC des Nutzers gehostet werden können, kann diese private Kommunikation zwischen der VPC der Anwendung (Ersteller) und einer Remote-Umgebung wie einer lokalen Umgebung erfolgen.
In einem solchen Szenario ermöglichen Private Service Connect-Schnittstellen einer VM-Instanz eines Diensterstellers den Zugriff auf das Netzwerk eines Nutzers. Dazu wird eine Netzwerkschnittstelle gemeinsam genutzt, während die Rollen von Produzenten und Verbrauchern weiterhin getrennt bleiben. Über diese Netzwerkschnittstelle im Nutzer-VPC kann die Anwendungs-VM auf Nutzerressourcen zugreifen, als wären sie lokal im Ersteller-VPC vorhanden.
Eine Private Service Connect-Schnittstelle ist eine Netzwerkschnittstelle, die mit dem VPC (Nutzernetzwerk) verbunden ist. Es ist möglich, externe Ziele zu erreichen, die über die VPC des Nutzers (Transit-VPC), an die die Private Service Connect-Schnittstelle angehängt ist, erreichbar sind. Daher kann diese Verbindung über eine hybride Konnektivität wie eine On-Premises-Umgebung auf eine externe Umgebung erweitert werden, wie im folgenden Diagramm dargestellt:
Wenn die VPC des Nutzers zu einer externen Organisation oder Entität wie einer Drittanbieterorganisation gehört, können Sie die Kommunikation mit der Private Service Connect-Benutzeroberfläche in der VPC des Nutzers in der Regel nicht schützen. In einem solchen Szenario können Sie Sicherheitsrichtlinien im Gastbetriebssystem der VM mit der Private Service Connect-Schnittstelle definieren. Weitere Informationen finden Sie unter Sicherheit für Private Service Connect-Schnittstellen konfigurieren. Sie können auch einen alternativen Ansatz in Betracht ziehen, wenn er nicht den Sicherheitsanforderungen oder -standards Ihrer Organisation entspricht.
Best Practices
Wenn Clientanfragen aus dem Internet lokal von einem Frontend empfangen werden müssen, das in einer privaten lokalen oder anderen Cloud-Umgebung gehostet wird, sollten Sie Hybrid als API-Gateway-Lösung verwenden.
- Dieser Ansatz erleichtert auch die Migration der Lösung in eine vollständig in Google Cloud gehostete Umgebung, wobei die Konsistenz der API-Plattform (Apigee) beibehalten wird.
Um die Latenz zu minimieren und die Kosten für große Mengen an ausgehenden Datenübertragungen an Ihre anderen Umgebungen zu optimieren, wenn sich diese Umgebungen in langfristigen oder dauerhaften Hybrid- oder Multi-Cloud-Umgebungen befinden, sollten Sie Folgendes beachten:
- Verwenden Sie Cloud Interconnect oder Cross-Cloud Interconnect.
- Wenn Sie Nutzerverbindungen am Ziel-Frontend in der entsprechenden Umgebung beenden möchten, verwenden Sie Hybrid.
Verwenden Sie den Apigee-Adapter für Envoy mit einer Hybridbereitstellung mit Kubernetes, wenn dies für Ihre Anforderungen und die Architektur geeignet ist.
Bevor Sie die Konnektivitäts- und Routingpfade entwerfen, müssen Sie zuerst ermitteln, welche Traffic- oder API-Anfragen an ein lokales oder Remote-API-Gateway weitergeleitet werden müssen, sowie die Quell- und Zielumgebungen.
Verwenden Sie VPC Service Controls, um Google Cloud-Dienste in Ihren Projekten zu schützen und das Risiko einer Daten-Exfiltration zu minimieren. Geben Sie dazu Dienstperimeter auf Projekt- oder VPC-Netzwerkebene an.
- Sie können Dienstperimeter über ein autorisiertes VPN oder Cloud Interconnect auf eine Hybridumgebung ausweiten. Weitere Informationen zu den Vorteilen von Dienstperimetern finden Sie unter VPC Service Controls.
Mithilfe von VPC-Firewallregeln oder Firewallrichtlinien können Sie den Zugriff auf Private Service Connect-Ressourcen über den Private Service Connect-Endpunkt auf Netzwerkebene steuern. Beispielsweise können Firewallregeln für ausgehenden Traffic im VPC der Anwendung (Nutzer) den Zugriff von VM-Instanzen auf die IP-Adresse oder das Subnetz Ihrer Endpunkte einschränken.
Wenn Sie eine Private Service Connect-Schnittstelle verwenden, müssen Sie die Kommunikation mit der Schnittstelle schützen, indem Sie die Sicherheit für die Private Service Connect-Schnittstelle konfigurieren.
Wenn eine Arbeitslast in einem privaten Subnetz Internetzugriff benötigt, verwenden Sie Cloud NAT, um der Arbeitslast keine externe IP-Adresse zuzuweisen und sie nicht dem öffentlichen Internet auszusetzen.
- Verwenden Sie für ausgehenden Webtraffic den Sicheren Web-Proxy. Der Proxy bietet mehrere Vorteile.
Lesen Sie die allgemeinen Best Practices für Hybrid- und Multi-Cloud-Netzwerkmuster.