Übersicht über den Zugriff auf private Dienste in Cloud SQL

In diesem Dokument wird erläutert, wie der Zugriff auf private Dienste private IP-Verbindungen für Cloud SQL bereitstellt. Außerdem werden die Zuweisung von IP-Adressen, Netzwerk- und Sicherheitsaspekte sowie die Verbindung zu mehreren VPCs behandelt.

Der Zugriff auf private Dienste wird als eine VPC-Netzwerk-Peering-Verbindung zwischen dem VPC-Netzwerk und dem VPC-Netzwerk des Dienstanbieters implementiert, in dem sich Ihre Cloud SQL-Instanz befindet. Über diese private Netzwerkverbindung können VM-Instanzen in Ihrem VPC-Netzwerk und die Google Cloud Dienste, auf die Sie zugreifen, ausschließlich über private IP-Adressen mit Ihrer Cloud SQL-Instanz kommunizieren. VM-Instanzen erfordern keinen Internetzugang und keine externen IP-Adressen, um Dienste zu erreichen, die über den Zugriff auf private Dienste verfügbar sind.

IP-Adressen

Wenn Sie den Zugriff auf private Dienste in einem VPC-Netzwerk verwenden möchten, müssen ein oder mehrere IP-Adressbereiche für die VPC verfügbar sein (Weitere Informationen zu IP-Adressen finden Sie unter IP-Adressen). Diese Bereiche müssen groß genug für Cloud SQL und alle anderen Google Cloud verwalteten Dienste sein, die Sie verwenden möchten. Cloud SQL und andere Google Cloud Dienste benötigen jeweils eigene IP-Blöcke aus den zugewiesenen Bereichen. Die Mindestgröße für solche Blöcke beträgt 256 Adressen (Präfixlänge /24), die empfohlene Größe 65.536 Adressen (Präfixlänge /16).

Wenn Sie Instanzen in mehreren Regionen oder für verschiedene Datenbanktypen erstellen möchten, müssen Sie für jede Region oder jeden Datenbanktyp mindestens einen /24-IP-Adressbereich haben. Dies schließt andere Anwendungen wie Filestore oder Memorystore ein.

Wenn Sie den Zugriff auf private Dienste einrichten, können Sie einen vorhandenen Bereich auswählen oder einen neuen zuweisen. Wenn Sie den Bereich für sich zuweisen Google Cloud lassen, wie im nächsten Abschnitt beschrieben, Google Cloud weist einen Bereich mit der Präfixlänge /24 unter dem Namen default-ip-range zu.

Wann separate CIDR-Bereiche verwendet werden sollten

Da Cloud SQL /24-CIDR-Bereiche als IP-Bereichseinheit verwendet, sind in mehreren Fällen separate /24-Bereiche erforderlich.

  • Regionale Trennung: Wenn Sie zwei Cloud SQL-Instanzen in zwei separaten Regionen erstellen, müssen Sie mindestens zwei separate /24-CIDR -Bereiche zuweisen. Jede IP-Bereichseinheit kann nur für Cloud SQL Instanzen in einer einzigen Region verwendet werden.
  • Trennung für ältere PostgreSQL-Versionen: In einem Netzwerk projekt mit der alten Netzwerk architektur können PostgreSQL-Instanzen nicht dieselbe IP-Bereichseinheit wie MySQL- oder SQL Server-Instanzen verwenden. Die PostgreSQL-Instanzen benötigen in jeder Region eigene /24-Bereiche.
  • Erzwungene Trennung der Netzwerkarchitektur: Instanzen, die Sie mit dem Flag --enforce-new-sql-network-architecture erstellen (oder dem entsprechenden API-Feld), können nicht dieselbe IP-Bereichseinheit wie Instanzen im selben Projekt verwenden, die die alte Netzwerkarchitektur verwenden. Die Instanzen, die Sie mit der neuen Netzwerkarchitektur erstellen, benötigen in jeder Region eigene /24-Bereiche.

Beispiel für den Zugriff auf private Dienste

In diesem Beispiel hat das VPC-Netzwerk den Adress bereich 10.240.0.0/16 für Google Cloud Dienste zugewiesen und eine private Verbindung mit diesem Bereich eingerichtet. Jeder Google Cloud Dienst (z. B. Cloud SQL) erstellt ein Subnetz aus dem zugewiesenen Block, um neue Ressourcen in einer bestimmten Region bereitzustellen, z. B. Cloud SQL-Instanzen.

Diagrammübersicht der privaten IP-Konfiguration.

Das Diagramm veranschaulicht die folgenden Aspekte der Konfiguration des Zugriffs auf private Dienste:

  • Die private Verbindung ist dem zugewiesenen Bereich 10.240.0.0/16 zugeordnet. Mit dieser Zuweisung, Google Cloud können Dienste Subnetze erstellen, in denen neue Ressourcen bereitgestellt werden.
  • Auf der Google Cloud Seite der Dienste der privaten Verbindung, Google Cloud erstellt ein Projekt für den Kunden. Das Projekt ist isoliert, d. h., es wird von keinem anderen Kunden verwendet und dem Kunden werden nur die Ressourcen in Rechnung gestellt, die er bereitstellt.
  • Jeder Google Cloud Dienst erstellt ein Subnetz, in dem Ressourcen bereitgestellt werden. Der IP-Adressbereich des Subnetzes ist in der Regel ein klassenloser Inter-Domain-Routing-Block (Classless Inter-Domain Routing, CIDR) vom Typ /24, der vom Dienst ausgewählt wird und aus dem zugewiesenen IP-Adressbereich stammt. Das Subnetz des Diensterstellers können Sie nicht ändern. Ein Dienst stellt neue Ressourcen in vorhandenen regionalen Subnetzen bereit, die zuvor von diesem Dienst erstellt wurden. Wenn ein Subnetz voll ist, erstellt der Dienst ein neues Subnetz in derselben Region.
  • VM-Instanzen im Kundennetzwerk können auf Dienstressourcen in jeder Region zugreifen, wenn der Dienst dies unterstützt. Einige Dienste unterstützen jedoch möglicherweise keine regionenübergreifende Kommunikation. Weitere Informationen finden Sie in der Dokumentation des jeweiligen Dienstes.
  • Die Kosten für ausgehende Datenübertragung für regionenübergreifenden Traffic, bei dem eine VM-Instanz mit Ressourcen in einer anderen Region kommuniziert, fallen weiterhin an.
  • Der Cloud SQL-Instanz wird die IP-Adresse 10.240.0.2 zugewiesen. Im VPC-Netzwerk des Kunden werden Anfragen mit dem Ziel 10.240.0.2 über das Netzwerk des Diensterstellers an die private Verbindung weitergeleitet. Nachdem die Anfrage das Dienstnetzwerk erreicht hat, enthält das Dienstnetzwerk Routen, die die Anfrage an die richtige Ressource weiterleiten.
  • Der Traffic zwischen VPC-Netzwerken verläuft intern im Google Cloud Netzwerk, nicht über das öffentliche Internet.

Netzwerkaspekte

Cloud SQL weist für jede Region ein /24-Subnetz aus dem IP-Bereich für den Zugriff auf private Dienste zu. Wenn Sie beispielsweise PostgreSQL-Instanzen in zwei Regionen platzieren, müssen die zugewiesenen IP-Adressbereiche mindestens zwei verfügbare Subnetze der Größe /24 enthalten.

Verbindungen zu einer Cloud SQL-Instanz mit einer privaten IP-Adresse werden für RFC 1918-Adressbereiche automatisch autorisiert. Auf diese Weise können alle privaten Clients auf die Datenbank zugreifen, ohne den Cloud SQL Auth-Proxy zu verwenden.

Cloud SQL lernt standardmäßig keine Subnetzrouten außerhalb des RFC 1918-Bereichs von Ihrer VPC. Sie müssen deshalb das Netzwerk-Peering auf Cloud SQL aktualisieren, um Routen außerhalb des RFC 1918-Bereichs exportieren zu können.

Sicherheitsaspekte

Traffic, der über den Zugriff auf private Dienste geleitet wird, wird mit einem bestimmten Grad an Verschlüsselung bereitgestellt. Weitere Informationen finden Sie unter Google Cloud Virtuelle Netzwerkverschlüsselung und -authentifizierung.

Der Cloud SQL Auth-Proxy kann so konfiguriert werden, dass eine Verbindung über den Zugriff auf private Dienste hergestellt wird. Er bietet eine Authentifizierung über IAM-Anmeldedaten sowie eine Ende-zu-Ende-Verschlüsselung mit einem rotierenden SSL/TLS-Zertifikat.

Wenn Ihre Sicherheitsanforderungen von Ihnen selbst verwaltete SSL/TLS-Zertifikate vorschreiben, die Sie verwalten, verwenden Sie die Anleitungen unter SSL/TLS konfigurieren.

Für jede Instanz ein VPC-Netzwerk mit einer privaten IP-Adresse zu erstellen, gewährleistet eine bessere Netzwerkisolation, als alle Instanzen im "Standard"-VPC-Netzwerk zu erstellen.

Verbindung zu mehreren VPCs

Cloud SQL unterstützt private IP-Adressen über den Zugriff auf private Dienste. Wenn Sie eine Cloud SQL-Instanz erstellen, erstellt Cloud SQL die Instanz in einem eigenen VPC-Netzwerk, dem Cloud SQL-VPC-Netzwerk. Wenn Sie private IP-Adressen aktivieren möchten, müssen Sie eine Peering-Verbindung einrichten zwischen dem Cloud SQL-VPC und Ihrem VPC-Netzwerk. So können Ressourcen in Ihrem VPC-Netzwerk auf die internen IP-Adressen Ihrer Cloud SQL-Ressourcen im Cloud SQL-VPC-Netzwerk zugreifen.

Mithilfe von VPC-Netzwerk-Peering implementiert Cloud SQL den Zugriff auf private Dienste intern. Dadurch können interne IP-Adressen eine Verbindung über zwei VPC-Netzwerke herstellen, unabhängig davon, ob sie zum selben Projekt oder zur selben Organisation gehören. Da das VPC-Netzwerk-Peering jedoch nicht transitiv ist, werden nur Routen zwischen den beiden VPCs gesendet, die direkt per Peering verbunden sind. Wenn Sie ein zusätzliches VPC haben, kann es nicht über die mit Ihrem ursprünglichen VPC eingerichtete Verbindung auf Ihre Cloud SQL-Ressourcen zugreifen.

Um diese Einschränkung zu mildern und Ihre Cloud SQL-Instanz über private IP-Adressen mit mehreren VPCs zu verbinden, können Sie die folgenden Verbindungsoptionen verwenden:

  • Verbindung über benutzerdefinierte beworbene Routen herstellen
  • Connect using an intermediate proxy (SOCKS5)
  • Verbindung über den Cloud SQL Auth-Proxy herstellen

Weitere Informationen zum Verbinden mehrerer VPCs finden Sie unter Instanz mit mehreren VPC-Netzwerken verbinden.

Nächste Schritte