Die Architektur des Musters für gatewaygesteuerten eingehenden Traffic basiert darauf, dass ausgewählte APIs von Arbeitslasten, die in Google Cloud ausgeführt werden, in der privaten Rechenumgebung zur Verfügung gestellt werden, ohne dass diese über das öffentliche Internet zugänglich sind. Dieses Muster ist das Gegenstück zum Muster für gatewaygesteuerten ausgehenden Traffic und eignet sich gut für Edge-Hybridszenarien, mehrstufige Hybridszenarien und partitionierte Multi-Cloud-Szenarien.
Wie beim Muster Gated Egress können Sie diese eingeschränkte Bereitstellung durch ein API-Gateway oder einen Load Balancer ermöglichen, der als Fassade für vorhandene Arbeitslasten oder Dienste dient. Dadurch ist sie für private Rechenumgebungen, lokale Umgebungen oder andere Cloud-Umgebungen zugänglich, wie unten beschrieben:
- In der privaten Rechenumgebung oder anderen Cloud-Umgebungen bereitgestellte Arbeitslasten können über interne IP-Adressen mit dem API-Gateway oder Load Balancer kommunizieren. Andere inGoogle Cloud bereitgestellte Systeme sind nicht erreichbar.
- Die Kommunikation von Google Cloud mit der privaten Rechenumgebung oder anderen Cloud-Umgebungen ist nicht zulässig. Der Traffic wird nur aus der privaten Umgebung oder anderen Cloud-Umgebungen zu den APIs in Google Cloudinitiiert.
Architektur
Das folgende Diagramm zeigt eine Referenzarchitektur, die die Anforderungen des Musters für gatewaygesteuerten eingehenden Traffic erfüllt.
Die Beschreibung der Architektur im vorherigen Diagramm lautet so:
- Auf der Google Cloud Seite stellen Sie Arbeitslasten in einer Anwendungs-VPC (oder mehreren VPCs) bereit.
- Das Netzwerk der Google Cloud -Umgebung wird auf andere Rechenumgebungen (lokal oder in einer anderen Cloud) erweitert. Dazu wird Hybrid- oder Multicloud-Netzwerkkonnektivität verwendet, um die Kommunikation zwischen den Umgebungen zu ermöglichen.
- Optional können Sie eine Transit-VPC verwenden, um Folgendes zu erreichen:
- Zusätzliche Perimeter-Sicherheitsebenen bereitstellen, um den Zugriff auf bestimmte APIs außerhalb der VPC Ihrer Anwendung zu ermöglichen.
- Leiten Sie Traffic an die IP-Adressen der APIs weiter. Sie können VPC-Firewallregeln erstellen, um zu verhindern, dass einige Quellen über einen Endpunkt auf bestimmte APIs zugreifen.
- Prüfen Sie den Layer-7-Traffic in der Transit-VPC durch die Integration einer virtuellen Netzwerk-Appliance (Network Virtual Appliance, NVA).
- Greifen Sie über ein API-Gateway oder einen Load Balancer (Proxy- oder Application Load Balancer) auf APIs zu, um eine Proxy-Ebene und eine Abstraktions- oder Fassadenebene für Ihre Dienst-APIs bereitzustellen. Wenn Sie Traffic auf mehrere API-Gateway-Instanzen verteilen müssen, können Sie einen internen Passthrough-Network-Load-Balancer verwenden.
- Sie können über einen Load Balancer über Private Service Connect eine Anwendung oder einen Dienst verfügbar machen und so über einen Private Service Connect-Endpunkt eingeschränkten und detaillierten Zugriff auf einen veröffentlichten Dienst ermöglichen.
- Alle Umgebungen sollten einen sich nicht überschneidenden IP-Adressbereich nach RFC 1918 verwenden.
Das folgende Diagramm veranschaulicht das Design dieses Musters mit Apigee als API-Plattform.
Im obigen Diagramm bietet die Verwendung von Apigee als API-Plattform die folgenden Funktionen und Möglichkeiten, um das Muster Gated Ingress zu ermöglichen:
- Gateway- oder Proxyfunktionen
- Sicherheitsfunktionen
- Ratenbegrenzung
- Analytics
Im Design:
- Die Nordbound-Netzwerkverbindung (für Traffic aus anderen Umgebungen) wird über einen Private Service Connect-Endpunkt in Ihrer Anwendungs-VPC geleitet, der der Apigee-VPC zugeordnet ist.
- In der Anwendungs-VPC wird ein interner Load Balancer verwendet, um die Anwendungs-APIs über einen Private Service Connect-Endpunkt verfügbar zu machen, der in der Apigee-VPC präsentiert wird. Weitere Informationen finden Sie unter Architektur mit deaktiviertem VPC-Peering.
Konfigurieren Sie Firewallregeln und Trafficfilterung in der Anwendungs-VPC. So wird ein detaillierter und kontrollierter Zugriff ermöglicht. Außerdem wird verhindert, dass Systeme Ihre Anwendungen direkt erreichen, ohne den Private Service Connect-Endpunkt und das API-Gateway zu durchlaufen.
Außerdem können Sie die Ankündigung des internen IP-Adress-Subnetzes des Backend-Workloads in der Anwendungs-VPC auf das lokale Netzwerk beschränken, um eine direkte Erreichbarkeit ohne Durchlaufen des Private Service Connect-Endpunkts und des API-Gateways zu vermeiden.
Bestimmte Sicherheitsanforderungen erfordern möglicherweise eine Perimeter-Sicherheitsprüfung außerhalb der Anwendungs-VPC, einschließlich des Traffics für Hybridverbindungen. In solchen Fällen können Sie eine Transit-VPC einbinden, um zusätzliche Sicherheitsebenen zu implementieren. Diese Schichten, wie NVAs mit Firewalls der nächsten Generation (NGFWs) mit mehreren Netzwerkschnittstellen oder Cloud Next Generation Firewall Enterprise mit Intrusion Prevention Service (IPS), führen Deep Packet Inspection außerhalb Ihrer Anwendungs-VPC durch, wie im folgenden Diagramm dargestellt:
Wie im obigen Diagramm dargestellt:
- Die Northbound-Netzwerkverbindung (für Traffic aus anderen Umgebungen) wird über eine separate Transit-VPC zum Private Service Connect-Endpunkt in der Transit-VPC geleitet, die mit der Apigee-VPC verknüpft ist.
- In der Anwendungs-VPC wird ein interner Load Balancer (ILB im Diagramm) verwendet, um die Anwendung über einen Private Service Connect-Endpunkt in der Apigee-VPC verfügbar zu machen.
Sie können mehrere Endpunkte im selben VPC-Netzwerk bereitstellen, wie im folgenden Diagramm dargestellt. Um verschiedene Anwendungsfälle abzudecken, können Sie die verschiedenen möglichen Netzwerkpfade mit Cloud Router und VPC-Firewallregeln steuern. Wenn Sie beispielsweise Ihr lokales Netzwerk über mehrere Hybridnetzwerkverbindungen mit Google Cloud verbinden, können Sie einen Teil des Traffics von lokal über eine Verbindung und den Rest über eine andere Verbindung an bestimmte Google APIs oder veröffentlichte Dienste senden. Außerdem können Sie Globaler Zugriff auf Private Service Connect verwenden, um Failover-Optionen bereitzustellen.
Varianten
Das Architekturmuster für gatewaygesteuerten eingehenden Traffic kann mit anderen Ansätzen kombiniert werden, um verschiedene Designanforderungen zu erfüllen, die dennoch die Kommunikationsanforderungen des Musters berücksichtigen. Das Muster bietet folgende Optionen:
Auf Google APIs aus anderen Umgebungen zugreifen
Für Szenarien, in denen auf Google-Dienste wie Cloud Storage oder BigQuery zugegriffen werden muss, ohne Traffic über das öffentliche Internet zu senden, bietet Private Service Connect eine Lösung. Wie im folgenden Diagramm dargestellt, ermöglicht es den Zugriff auf die unterstützten Google APIs und ‑Dienste (einschließlich Google Maps, Google Ads undGoogle Cloud) aus lokalen oder anderen Cloud-Umgebungen über eine Hybridnetzwerkverbindung mit der IP-Adresse des Private Service Connect-Endpunkts. Weitere Informationen zum Zugriff auf Google APIs über Private Service Connect-Endpunkte finden Sie unter Zugriff auf Google APIs über Endpunkte.
Im vorherigen Diagramm muss Ihr lokales Netzwerk über Cloud VPN-Tunnel oder einen Cloud Interconnect-VLAN-Anhang mit dem Transit-VPC-Netzwerk (Consumer) verbunden sein.
Auf Google APIs kann über Endpunkte oder Back-Ends zugegriffen werden. Mit Endpunkten können Sie ein Bundle von Google APIs zum Ziel haben. Mit Backends können Sie eine bestimmte regionale Google API als Ziel festlegen.
Anwendungs-Back-Ends mit Private Service Connect für andere Umgebungen verfügbar machen
In bestimmten Szenarien, wie im gestaffelten Hybridmuster hervorgehoben, müssen Sie möglicherweise Back-Ends in Google Cloud bereitstellen, während Front-Ends in privaten Rechenumgebungen verbleiben. Dieser Ansatz ist zwar weniger verbreitet, kann aber bei komplexen, monolithischen Frontends, die möglicherweise auf Legacy-Komponenten basieren, sinnvoll sein. Oder, was häufiger vorkommt, wenn verteilte Anwendungen in mehreren Umgebungen verwaltet werden, einschließlich lokaler und anderer Clouds, die eine Verbindung zu Backends erfordern, die in Google Cloud über ein Hybridnetzwerk gehostet werden.
In einer solchen Architektur können Sie ein lokales API-Gateway oder einen Load Balancer in der privaten lokalen Umgebung oder in anderen Cloud-Umgebungen verwenden, um das Anwendungs-Frontend direkt im öffentlichen Internet verfügbar zu machen. Die Verwendung von Private Service Connect in Google Cloud ermöglicht private Verbindungen zu den Back-Ends, die über einen Private Service Connect-Endpunkt verfügbar gemacht werden, idealerweise über vordefinierte APIs, wie im folgenden Diagramm dargestellt:
Das Design im vorherigen Diagramm verwendet eine Apigee Hybrid-Bereitstellung, die aus einer Verwaltungsebene in Google Cloud und einer Laufzeitebene besteht, die in Ihrer anderen Umgebung gehostet wird. Sie können die Laufzeitebene auf einem verteilten API-Gateway auf einer der unterstützten Kubernetes-Plattformen in Ihrer lokalen Umgebung oder in anderen Cloud-Umgebungen installieren und verwalten. Je nach Ihren Anforderungen an verteilte Arbeitslasten in Google Cloud und anderen Umgebungen können Sie Apigee auf Google Cloud mit Apigee Hybrid verwenden. Weitere Informationen finden Sie unter Verteilte API-Gateways.
Hub-and-Spoke-Architektur verwenden, um Anwendungs-Back-Ends für andere Umgebungen verfügbar zu machen
In bestimmten Szenarien kann es erforderlich sein, APIs von Anwendungs-Back-Ends, die in Google Cloud gehostet werden, über verschiedene VPC-Netzwerke hinweg verfügbar zu machen. Wie im folgenden Diagramm dargestellt, dient eine Hub-VPC als zentraler Verbindungspunkt für die verschiedenen VPCs (Spokes), wodurch eine sichere Kommunikation über private Hybridkonnektivität ermöglicht wird. Optional können lokale API-Gateway-Funktionen in anderen Umgebungen wie Apigee Hybrid verwendet werden, um Clientanfragen lokal zu beenden, wo das Anwendungs-Frontend gehostet wird.
Wie im obigen Diagramm dargestellt:
- Um zusätzliche NGFW-Layer-7-Prüffunktionen bereitzustellen, wird die NVA mit NGFW-Funktionen optional in das Design integriert. Möglicherweise benötigen Sie diese Funktionen, um bestimmte Sicherheitsanforderungen und die Sicherheitsrichtlinienstandards Ihrer Organisation zu erfüllen.
Bei diesem Design wird davon ausgegangen, dass für Spoke-VPCs keine direkte VPC-zu-VPC-Kommunikation erforderlich ist.
- Wenn eine Kommunikation zwischen Spokes erforderlich ist, können Sie die NVA verwenden, um diese Kommunikation zu ermöglichen.
- Wenn Sie verschiedene Backends in verschiedenen VPCs haben, können Sie Private Service Connect verwenden, um diese Backends für die Apigee-VPC verfügbar zu machen.
- Wenn VPC-Peering für die Nord- und Südverbindungen zwischen Spoke-VPCs und Hub-VPC verwendet wird, müssen Sie die Transitivitätsbeschränkung von VPC-Netzwerken über VPC-Peering berücksichtigen. Um diese Einschränkung zu umgehen, haben Sie folgende Möglichkeiten:
- Verwenden Sie eine NVA, um die VPCs zu verbinden.
- Berücksichtigen Sie gegebenenfalls das Private Service Connect-Modell.
- Wenn Sie eine Verbindung zwischen der Apigee-VPC und Back-Ends in anderenGoogle Cloud -Projekten in derselben Organisation ohne zusätzliche Netzwerkkomponenten herstellen möchten, verwenden Sie freigegebene VPCs.
Wenn NVAs für die Traffic-Prüfung erforderlich sind, einschließlich Traffic aus Ihren anderen Umgebungen, sollte die Hybridkonnektivität zu lokalen oder anderen Cloud-Umgebungen in der Hybrid-Transit-VPC beendet werden.
Wenn das Design die NVA nicht enthält, können Sie die hybride Konnektivität in der Hub-VPC beenden.
Wenn bestimmte Load-Balancing-Funktionen oder Sicherheitsfunktionen erforderlich sind, z. B. das Hinzufügen von Google Cloud Armor-DDoS-Schutz oder WAF, können Sie optional einen externen Application Load Balancer am Perimeter über eine externe VPC bereitstellen, bevor Sie externe Clientanfragen an die Back-Ends weiterleiten.
Best Practices
- Wenn Clientanfragen aus dem Internet lokal von einem Frontend empfangen werden müssen, das in einer privaten On-Premise- oder anderen Cloudumgebung gehostet wird, sollten Sie Apigee Hybrid als API-Gateway-Lösung in Betracht ziehen. Dieser Ansatz ermöglicht auch eine nahtlose Migration der Lösung in eine vollständig Google Cloud-gehostete Umgebung, während die Konsistenz der API-Plattform (Apigee) beibehalten wird.
- Verwenden Sie den Apigee-Adapter für Envoy mit einer Architektur für die Apigee-Hybrid-Bereitstellung mit Kubernetes, wenn dies für Ihre Anforderungen und die Architektur geeignet ist.
- Das Design von VPCs und Projekten in Google Cloud sollte den Anforderungen an die Ressourcenhierarchie und das sichere Kommunikationsmodell entsprechen, wie in diesem Leitfaden beschrieben.
- Durch die Einbeziehung einer Transit-VPC in dieses Design können zusätzliche Perimeter-Sicherheitsmaßnahmen und Hybridkonnektivität außerhalb der Arbeitslast-VPC bereitgestellt werden.
- Mit Private Service Connect können Sie über die interne IP-Adresse des Endpunkts über ein Hybridnetzwerk auf Google APIs und Google-Dienste in lokalen Umgebungen oder anderen Cloud-Umgebungen zugreifen. Weitere Informationen finden Sie unter Über lokale Hosts auf den Endpunkt zugreifen.
- Mit VPC Service Controls können Sie Dienstperimeter auf Projekt- oder VPC-Netzwerkebene angeben, um Google Cloud -Dienste in Ihren Projekten zu schützen und das Risiko einer Daten-Exfiltration zu minimieren.
- Bei Bedarf können Sie Dienstperimeter über ein 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 Netzwerkebene auf Private Service Connect-Ressourcen über den Private Service Connect-Endpunkt steuern. Beispielsweise können Firewallregeln für ausgehenden Traffic in der Anwendungs-VPC (Nutzer-VPC) den Zugriff von VM-Instanzen auf die IP-Adresse oder das Subnetz Ihrer Endpunkte einschränken. Weitere Informationen zu VPC-Firewallregeln im Allgemeinen finden Sie unter VPC-Firewallregeln.
- Beim Entwerfen einer Lösung mit NVAs ist es wichtig, die Hochverfügbarkeit (HA) der NVAs zu berücksichtigen, um einen Single Point of Failure zu vermeiden, der die gesamte Kommunikation blockieren könnte. Folgen Sie den Design- und Implementierungsrichtlinien für HA und Redundanz Ihres NVA-Anbieters.
- Um die Perimetersicherheit zu erhöhen und Ihr API-Gateway zu schützen, das in der jeweiligen Umgebung bereitgestellt wird, können Sie optional Load-Balancing- und Web Application Firewall-Mechanismen in Ihrer anderen Rechenumgebung (Hybrid oder andere Cloud) implementieren. Implementieren Sie diese Optionen im Perimeternetzwerk, das direkt mit dem Internet verbunden ist.
- Wenn Instanzen einen Internetzugang benötigen, verwenden Sie Cloud NAT in der Anwendungs-VPC, damit Arbeitslasten auf das Internet zugreifen können. Dadurch vermeiden Sie, dass VM-Instanzen mit externen öffentlichen IP-Adressen in Systemen zugewiesen werden, die hinter einem API-Gateway oder einem Load Balancer bereitgestellt werden.
- 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.