Zugriff auf Google APIs über Endpunkte

Dieses Dokument bietet eine Übersicht über Private Service Connect-Endpunkte, die für den Zugriff auf Google APIs verwendet werden.

Wenn eine Anwendung einen Google-Dienst wie Cloud Storage verwendet, stellt Ihre Anwendung standardmäßig eine Verbindung zum Standard-DNS-Namen für diesen Dienst her, z. B. storage.googleapis.com. Die Standard-DNS-Namen für Google-Dienste werden in öffentlich routingfähige IP-Adressen aufgelöst. Traffic, der von Google Cloud-Ressourcen an diese IP-Adressen gesendet wird, verbleibt jedoch im Google-Netzwerk.

Mit Private Service Connect können Sie private Endpunkte mit globalen internen IP-Adressen innerhalb Ihres VPC-Netzwerks erstellen. Sie können diesen internen IP-Adressen DNS-Namen mit aussagekräftigen Namen wie storage-vialink1.p.googleapis.com und bigtable-adsteam.p.googleapis.com zuweisen. Diese Namen und IP-Adressen sind intern in Ihrem VPC-Netzwerk und allen lokalen Netzwerken vergeben, die über Cloud VPN-Tunnel oder VLAN-Anhänge mit ihm verbunden sind. Sie können steuern, welcher Traffic an welchen Endpunkt geleitet wird, und ob der Traffic innerhalb der Google Cloud bleiben soll.

Mit dieser Option erhalten Sie Zugriff auf alle Google APIs und Google-Dienste, die in den API-Bundles enthalten sind.

Abbildung 1. Mit Private Service Connect können Sie Traffic über einen Endpunkt, der in Ihrem VPC-Netzwerk privat ist, an Google APIs senden (zum Vergrößern klicken).

Features und Kompatibilität

In dieser Tabelle sind die Features zusammengefasst, die von Endpunkten unterstützt werden, die für den Zugriff auf Google APIs verwendet werden.

Konfiguration Details
Nutzerkonfiguration (Endpunkt)
Globale Erreichbarkeit Verwendet eine interne globale IP-Adresse
Interconnect-Traffic
Cloud VPN-Traffic
Automatische DNS-Konfiguration
IP-Stack IPv4
Ersteller
Unterstützte Dienste Unterstützte globale Google APIs

Lokaler Zugriff

Private Service Connect-Endpunkte, die Sie für den Zugriff auf Google APIs verwenden, können über unterstützte verbundene lokale Hosts aufgerufen werden. Weitere Informationen finden Sie unter Zugriff auf den Endpunkt über lokale Hosts.

Private Service Connect und Service Directory

Endpunkte sind bei Service Directory registriert. Service Directory ist eine Plattform zum Speichern, Verwalten und Veröffentlichen von Diensten. Wenn Sie einen Endpunkt für den Zugriff auf Google APIs und Google-Dienste erstellen, wählen Sie eine Service Directory-Region und einen Service Directory-Namespace aus.

Service Directory-Region

Service Directory ist ein regionaler Dienst. Die von Ihnen ausgewählte Region definiert, wo sich die Service Directory-Steuerungsebene befindet. Es gibt keinen funktionalen Unterschied zwischen Regionen, es kann jedoch aus Gründen der Verwaltung bestehen.

Wenn Sie den ersten Endpunkt für Google APIs in einem VPC-Netzwerk erstellen, wird die von Ihnen ausgewählte Region als Standardregion für alle nachfolgenden Endpunkte verwendet, die in diesem Netzwerk erstellt werden. Wenn eine Region noch nicht für ein Netzwerk festgelegt ist und Sie keine Region angeben, wird die Region auf us-central1 festgelegt. Alle Endpunkte in einem Netzwerk müssen dieselbe Service Directory-Region verwenden.

Service Directory-Namespace

Wenn Sie den ersten Endpunkt für Google APIs in einem VPC-Netzwerk erstellen, wird der von Ihnen ausgewählte Namespace als Standard-Namespace für alle nachfolgenden Endpunkte verwendet, die in diesem Netzwerk erstellt werden. Wenn der Namespace noch nicht für ein Netzwerk festgelegt ist und Sie keinen Namespace angeben, wird ein vom System generierter Namespace verwendet. Alle Endpunkte in einem Netzwerk müssen denselben Service Directory-Namespace verwenden. Der ausgewählte Namespace darf nur für Endpunkte verwendet werden, die für den Zugriff auf Google APIs verwendet werden. Sie können denselben Namespace für Endpunkte in mehreren Netzwerken verwenden.

Wenn Sie einen Endpunkt erstellen, werden die folgenden DNS-Konfigurationen erstellt:

  • Eine private DNS-Zone von Service Directory wird für p.googleapis.com erstellt.

  • DNS-Einträge werden in p.googleapis.com für einige häufig verwendete Google-APIs und -Dienste erstellt, die über Private Service Connect verfügbar sind und standardmäßig DNS-Namen haben, die auf googleapis.com enden.

    Eine Anleitung zum Erstellen von DNS-Einträgen für APIs und Dienste, die keinen DNS-Eintrag in p.googleapis.com haben, finden Sie unter DNS-Einträge erstellen.

Welche Dienste verfügbar sind, hängt davon ab, ob Sie das API Bundle all-apis oder vpc-sc auswählen.

Für jedes VPC-Netzwerk mit einem Endpunkt wird eine DNS-Zone für Service Directory erstellt.

Die DNS-Namen für einen Endpunkt sind in allen Regionen in Ihrem VPC-Netzwerk verfügbar.

Unterstützte APIs

Wenn Sie einen Endpunkt für den Zugriff auf Google APIs und Google-Dienste erstellen, wählen Sie aus, auf welches API-Bundle Sie zugreifen müssen: Alle APIs (all-apis) oder VPC-SC (vpc-sc).

Die API-Bundles unterstützen nur HTTP-basierte Protokolle über TCP (HTTP, HTTPS und HTTP/2). Alle anderen Protokolle, einschließlich MQTT und ICMP, werden nicht unterstützt.

API-Bundle Unterstützte Dienste Nutzungsbeispiel
all-apis

Aktiviert den API-Zugriff auf die meisten Google APIs und Google-Dienste, unabhängig davon, ob sie von VPC Service Controls unterstützt werden. Umfasst den API-Zugriff auf Google Maps, Google Ads, Google Cloud und die meisten anderen Google APIs, einschließlich der Listen unten. Unterstützt keine Google Workspace-Webanwendungen wie Gmail und Google Docs. Interaktive Websites werden nicht unterstützt.

Domainnamen, die übereinstimmen:

  • accounts.google.com (nur die für die OAuth-Authentifizierung benötigten Pfade)
  • *.aiplatform-notebook.cloud.google.com
  • *.aiplatform-notebook.googleusercontent.com
  • appengine.google.com
  • *.appspot.com
  • *.backupdr.cloud.google.com
  • backupdr.cloud.google.com
  • *.backupdr.googleusercontent.com
  • backupdr.googleusercontent.com
  • *.cloudfunctions.net
  • *.cloudproxy.app
  • *.composer.cloud.google.com
  • *.composer.googleusercontent.com
  • *.datafusion.cloud.google.com
  • *.datafusion.googleusercontent.com
  • *.dataproc.cloud.google.com
  • dataproc.cloud.google.com
  • *.dataproc.googleusercontent.com
  • dataproc.googleusercontent.com
  • dl.google.com
  • gcr.io oder *.gcr.io
  • *.googleapis.com
  • *.gstatic.com
  • *.ltsapis.goog
  • *.notebooks.cloud.google.com
  • *.notebooks.googleusercontent.com
  • packages.cloud.google.com
  • pkg.dev oder *.pkg.dev
  • pki.goog oder *.pki.goog
  • *.run.app
  • source.developers.google.com
  • storage.cloud.google.com

Wählen Sie unter folgenden Umständen all-apis aus:

  • Sie verwenden VPC Service Controls nicht.
  • Sie verwenden VPC Service Controls, müssen aber auch auf Google APIs und Google-Dienste zugreifen, die von VPC Service Controls nicht unterstützt werden. 1
vpc-sc

Aktiviert den API-Zugriff auf Google APIs und Google-Dienste, die von VPC Service Controls unterstützt werden.

Blockiert den Zugriff auf Google APIs und Google-Dienste, die VPC Service Controls nicht unterstützen. Unterstützt keine Google Workspace APIs oder Google Workspace-Webanwendungen wie Gmail und Google Docs.

Wählen Sie vpc-sc aus, wenn Sie nur Zugriff auf Google APIs und Google-Dienste benötigen, die von VPC Service Controls unterstützt werden. Das vpc-sc-Bundle erlaubt keinen Zugriff auf Google APIs und Google-Dienste, die VPC Service Controls nicht unterstützen.1
1Hinweis: Wenn Sie Nutzer auf die Google APIs und Google-Dienste beschränken müssen, die VPC Service Controls unterstützen, verwenden Sie vpc-sc. Obwohl VPC Service Controls unabhängig von dem verwendeten Bundle für kompatible und konfigurierte Dienste erzwungen wird, bietet vpc-sc eine zusätzliche Risikominderung bei der Daten-Exfiltration. Die Verwendung von vpc-sc verweigert den Zugriff auf Google APIs und Google-Dienste, die nicht von VPC Service Controls unterstützt werden. Weitere Informationen finden Sie in der Dokumentation zu VPC Service Controls unter Private Verbindung zu Google APIs und Google-Diensten einrichten.

Anforderungen an IP-Adressen

Wenn Sie Private Service Connect für ein VPC-Netzwerk konfigurieren, geben Sie eine IP-Adresse an, die für den Endpunkt verwendet werden soll.

Die Adresse wird dem Kontingent des Projekts für globale interne IP-Adressen angerechnet.

Die IP-Adresse muss die folgenden Spezifikationen erfüllen:

  • Es muss sich um eine einzelne IP-Adresse und nicht um einen Adressbereich handeln.

  • Es muss eine gültige IPv4-Adresse sein. Es kann sich um eine RFC 1918-Adresse oder um eine Adresse außerhalb des RFC 1918-Bereichs handeln. IPv6-Adressen werden für Private Service Connect nicht unterstützt.

  • Sie darf nicht innerhalb der im VPC-Netzwerk konfigurierten Subnetzbereiche liegen.

  • Sie darf sich nicht in einem primären oder sekundären IP-Adressbereich eines beliebigen Subnetzes im VPC-Netzwerk oder in einem Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk verbunden ist.

  • Es darf sich nicht mit einer benutzerdefinierten statischen /32-Route im lokalen VPC-Netzwerk überschneiden. Wenn das VPC-Netzwerk beispielsweise eine benutzerdefinierte statische Route für 10.10.10.10/32 hat, können Sie die Adresse 10.10.10.10 für Private Service Connect nicht reservieren.

  • Sie kann sich nicht mit einer benutzerdefinierten statischen /32-Peering Route überschneiden, wenn Sie das Peering-Netzwerk so konfiguriert haben, dass benutzerdefinierte Routen exportiert werden, und Sie Ihr VPC-Netzwerk so konfiguriert haben, dass benutzerdefinierte Routen importiert werden.

  • Sie darf sich nicht in einem der IP-Bereiche im automatischen Modus befinden (in 10.128.0.0/9), wenn das lokale VPC-Netzwerk ein Netzwerk im automatischen Modus ist, oder durch Peering mit einem Netzwerk im automatischen Modus verbunden ist.

  • Sie darf nicht in einem zugewiesenen IP-Bereich im lokalen VPC-Netzwerk liegen. Sie kann jedoch innerhalb eines zugewiesenen IP-Bereichs in einem Peering-VPC-Netzwerk liegen.

  • Wenn sich ein Endpunkt mit einer benutzerdefinierten dynamischen Route überschneidet, deren Ziel das gleiche /32 ist, hat der Endpunkt Vorrang.

  • Wenn sich die IP-Adresse eines Endpunkts im Zielbereich einer benutzerdefinierten statischen Route, benutzerdefinierten dynamischen Route oder einer benutzerdefinierten Peering-Route befindet und diese Route eine Subnetzmaske hat, die kürzer als /32 ist, hat der Endpunkt eine höhere Priorität.

Anwendungsfälle

Sie können mehrere Endpunkte im selben VPC-Netzwerk erstellen. Die an einen bestimmten Endpunkt gesendete Gesamtbandbreite ist unbegrenzt. Da Endpunkte globale interne IP-Adressen verwenden, können sie von jeder Ressource in Ihrem VPC-Netzwerk oder einem lokalen Netzwerk verwendet werden, das über Cloud VPN-Tunnel oder Cloud Interconnect-Anhänge verbunden ist.

Mit mehreren Endpunkten können Sie verschiedene Netzwerkpfade mithilfe von Cloud Router und Firewallregeln festlegen.

  • Sie können Firewallregeln erstellen, um zu verhindern, dass einige VMs über einen Endpunkt auf Google APIs zugreifen und anderen VMs Zugriff gewähren.

  • Sie können eine Firewallregel für eine VM-Instanz festlegen, die den gesamten Traffic im Internet untersagt. An Private Service Connect-Endpunkte gesendeter Traffic erreicht weiterhin Google.

  • Wenn lokale Hosts, die über einen Cloud-VPN-Tunnel oder einen VLAN-Anhang an eine VPC angeschlossen sind, können Sie einige Anfragen über den Tunnel oder VLAN senden, während Sie weitere Anfragen über das öffentliche Internet senden. Mit dieser Konfiguration können Sie den Tunnel oder VLAN für Dienste wie Google Books umgehen, die nicht vom privaten Google-Zugriff unterstützt werden.

    Für diese Konfiguration erstellen Sie einen Private Service Connect-Endpunkt, bewerben die IP-Adressen des Endpunkts mithilfe von benutzerdefinierten Route Advertisements für Cloud Router und aktivieren eine Cloud DNS-Richtlinie für die Weiterleitung von eingehendem Traffic erstellen. Die Anwendung kann einige Anfragen über den Cloud VPN-Tunnel oder den VLAN-Anhang senden und dazu den Namen des Endpunkts verwenden. Beim Senden weiterer Anfragen über das Internet kann sie den Standard-DNS-Namen verwenden.

  • Wenn Sie Ihr lokales Netzwerk über mehrere VLAN-Anhänge mit Ihrem VPC-Netzwerk verbinden, können Sie einigen Traffic von lokalen Speicherorten über ein VLAN und den Rest über andere senden, wie in Abbildung 2 gezeigt. Auf diese Weise können Sie Ihr eigenes Wide Area Netzwerk anstelle des Netzwerks von Google verwenden und so die Datenverschiebung im Hinblick auf die geografischen Anforderungen steuern.

    Für diese Konfiguration erstellen Sie zwei Endpunkte. Erstellen Sie ein benutzerdefiniertes Route Advertisement für den ersten Endpunkt in der BGP-Sitzung des Cloud Routers, der das erste VLAN verwaltet. Erstellen Sie dann ein anderes benutzerdefiniertes Route Advertisement für den zweiten Endpunkt in der BGP-Sitzung von Cloud Router, der das zweite VLAN verwaltet. Lokale Hosts, die für die Verwendung des Endpunktnamens konfiguriert sind, senden Traffic über den entsprechenden VLAN-Anhang.

  • Sie können auch mehrere VLAN-Anhänge in einer Aktiv/Aktiv-Topologie verwenden. Wenn Sie für die BGP-Sitzungen auf den Cloud Routern, die die VLANs verwalten, dieselbe IP-Adresse des Endpunkts über benutzerdefinierte Route Advertisements bewerben, werden Pakete, die von lokalen Systemen an die Endpunkte gesendet werden, über die VLANs mit ECMP weitergeleitet.

    Abbildung 2. Durch die Konfiguration von Private Service Connect, Cloud Router und lokalen Hosts können Sie steuern, welcher VLAN-Anhang zum Senden von Traffic an Google APIs verwendet wird.

Preise

Die Preise für Private Service Connect werden auf der Seite "VPC-Preise" beschrieben.

Kontingente

Die Anzahl der Private Service Connect-Endpunkte, die Sie für den Zugriff auf Google APIs erstellen können, wird durch das Kontingent PSC Google APIs Forwarding Rules per VPC Network gesteuert. Weitere Informationen finden Sie unter Kontingente.

Einschränkungen für Organisationsrichtlinien

Ein Administrator für Organisationsrichtlinien kann mit der Einschränkung constraints/compute.disablePrivateServiceConnectCreationForConsumers die Gruppe von Endpunkttypen definieren, für die Nutzer keine Weiterleitungsregeln erstellen können.

Informationen zum Erstellen einer Organisationsrichtlinie, die diese Einschränkung verwendet, finden Sie unter Nutzer daran hindern, Endpunkte nach Verbindungstyp bereitzustellen.

Nächste Schritte