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

In diesem Dokument wird erläutert, wie der Zugriff auf private Dienste eine private IP-Verbindung für Cloud SQL ermöglicht. Außerdem werden die IP-Adresszuweisung, Netzwerk- und Sicherheitsaspekte sowie die Verbindung mehrerer VPCs behandelt.

Der Zugriff auf private Dienste wird als 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. Die 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 verwalteten Dienste von Google Cloudsein, die Sie verwenden möchten. Cloud SQL und andere Google Cloud-Dienste erfordern jeweils dedizierte 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 jedoch 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 von Google Cloud zuweisen lassen, wie im nächsten Abschnitt beschrieben, weist Google Cloud 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, gibt es mehrere Bedingungen, unter denen separate /24-Bereiche erforderlich sind.

  • 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 innerhalb einer einzelnen Region verwendet werden.
  • Legacy-PostgreSQL-Trennung: In einem Netzwerkprojekt mit der alten Netzwerkarchitektur können PostgreSQL-Instanzen nicht dieselbe IP-Bereichseinheit mit MySQL- oder SQL Server-Instanzen teilen. Die PostgreSQL-Instanzen benötigen in jeder Region eigene dedizierte /24-Bereiche.
  • Erzwungene Trennung der Netzwerkarchitektur: Instanzen, die Sie mit dem Flag --enforce-new-sql-network-architecture (oder dem entsprechenden API-Feld) erstellen, können nicht dieselbe IP-Bereichseinheit mit Instanzen im selben Projekt teilen, die die alte Netzwerkarchitektur verwenden. Die Instanzen, die Sie mit der neuen Netzwerkarchitektur erstellen, benötigen in jeder Region eigene dedizierte /24-Bereiche.

Beispiel für den Zugriff auf private Dienste

In diesem Beispiel hat das VPC-Netzwerk den Adressbereich 10.240.0.0/16 für Google Cloud -Dienste zugewiesen und eine private Verbindung mit diesem Bereich hergestellt. 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 können Google Cloud -Dienste Subnetze erstellen, in denen neue Ressourcen bereitgestellt werden.
  • Auf der Google Cloud Dienstseite der privaten Verbindung erstellt Google Cloudein Projekt für den Kunden. Das Projekt ist isoliert, was bedeutet, dass keine anderen Kunden es teilen und dem Kunden nur die Ressourcen in Rechnung gestellt werden, die der Kunde bereitstellt.
  • Jeder Google Cloud -Dienst erzeugt ein Subnetz, in dem Ressourcen bereitgestellt werden. Der IP-Adressbereich des Subnetzes ist in der Regel ein /24-CIDR-Block (Classless Inter-Domain Routing), 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 Diensts.
  • 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 zugeordnet. Im Kunden-VPC-Netzwerk 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 imGoogle Cloud -Netzwerk, nicht über das öffentliche Internet.

Überlegungen zum Netzwerk

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, 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.

Mehrere VPC-Verbindungen

Cloud SQL unterstützt private IP-Adressen über den Zugriff auf private Dienste. Wenn Sie eine Cloud SQL-Instanz erstellen, wird sie in einem eigenen VPC-Netzwerk erstellt, der Cloud SQL-VPC. Wenn Sie private IP-Adressen aktivieren möchten, müssen Sie eine Peering-Verbindung zwischen dem Cloud SQL-VPC und Ihrem VPC-Netzwerk einrichten. 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