Cloud SQL nur mit privater IP: das Gut, schlecht und hässlich

Die -Daten sind die neue Goldmine aller Unternehmen, und dieser Schatz muss sicher und geschützt sein . Aus diesem Grund ist es seit vielen Jahren eine gängige Vorgehensweise eines Datenbankadministrators, jeglichen öffentlichen Zugriff auf die Datenbank zu entfernen die öffentliche IP und gewähren nur Zugriff von der privaten IP.
Diese „goldene“ Regel wird von allen erzwungen Sicherheitsteams und sie benötigen für jede Cloud-Bereitstellung dasselbe Muster.

Cloud SQL-Dienst , der verwaltete Datenbankdienst in Google Cloud, ermöglicht Folgendes:

Dank dieser Funktionen können Sie die Anforderungen des Sicherheitsteams durchsetzen .

Aber ist es ein Problem, wenn wir da arbeiten? y-to-day, um keine öffentliche IP auf Cloud SQL-Instanzen zu haben?

Lassen Sie uns dies über 3 Anwendungsfälle überprüfen:

  1. Compute Engine Konnektivität
  2. Serverlose Dienste Konnektivität
  3. Lokale Umgebung Konnektivität

Cloud SQL-Proxy-Binärdatei

Bevor ich näher auf die Anwendungsfälle eingehe, möchte ich mich kurz auf die Hauptfunktion von Cloud SQL-Proxy

  • Diese Binärdatei öffnet eine sicherer und durchgehender verschlüsselter Tunnel . Zusammenfassend lässt sich sagen, dass die Daten während der Übertragung verschlüsselt werden, auch wenn Ihre Datenbank kein SSL-Zertifikat besitzt.
  • Vor dem Öffnen des Tunnels prüft die Binärdatei die IAM-Dienst-API, wenn der aktuelle Berechtigungsnachweis berechtigt ist, auf die Cloud SQL-Instanz zuzugreifen. Dies ist zusätzlich zur Standarddatenbankauthentifizierung durch Benutzer / Kennwort eine zusätzliche Sicherheitsebene.
  • Der Tunnel kann an einem lokalen Port (TCP-Verbindungsmodus) oder an einem Unix-Socket geöffnet sein (nicht möglich am) Windows-Umgebung)
  • The Good: Compute Engine-Konnektivität

    Da dieses „private IP-Sicherheitsmuster“ erstellt wurde Für ältere Architekturen (dh lokale VM und privates Netzwerk) passt die Einschränkung perfekt zur IaaS-Welt (dh Compute Engine + VPC).
    Ich erwähne Compute Engine, aber es gilt auch für alle Dienste, die Compute Engine-Instanzen verwenden: Datenfluss, Dataproc, GKE, …

    • Stellen Sie Ihre VM in der bereit Dieselbe VPC wie die private IP der Cloud SQL-Instanzen.
    • Verwenden Sie die private IP der Cloud SQL-Instanz, um sie von Ihrer App aus zu erreichen, die auf der Compute Engine bereitgestellt wird.
    • Öffnen Sie die erforderlichen Firewall-Regeln, wenn benötigt.

    Das ist „gut“ !!

    Hinweis: Die Verwendung des Cloud SQL-Proxys in diesem Fall kann erläutert werden. Es wird eine zusätzliche Sicherheitsschicht hinzugefügt, indem die Autorisierung anhand von IAM-Diensten und der verschlüsselten Kommunikation überprüft wird, aber auch zusätzliche Latenz und potenzielle Fehlerquellen hinzugefügt werden. Es ist eine Frage der Kompromisse.

    The Bad: Serverless Services Connectivity

    Wenn wir die „neue Welt“ verwenden der Cloud, dem serverlosen Paradigma , sind die Dinge mit Cloud Run , Cloud-Funktionen und App Engine .

    In der Tat, wenn Sie auf serverlosen Plattformen bereitstellen Per Definition müssen Sie die Server und damit die Server befinden sich nicht in Ihrer VPC . Daher ist es nicht sofort möglich, die private Cloud SQL-IP zu erreichen, die mit der VPC Ihres Projekts verbunden ist.

    Wenn Sie sich mit Cloud Run befassen, Cloud-Funktionen und App Engine finden Sie , wie Sie Ihre Cloud SQL-Instanz mit Ihrem serverlosen Dienst verbinden können dank einer integrierten Funktion:

    Fügen Sie der Konfiguration den Namen der Cloud SQL-Instanzverbindung hinzu, und beim Start der Instanz wird automatisch ein Tunnel erstellt.

    In Wirklichkeit handelt es sich um eine Verbindung, die durch Cloud SQL-Proxy im Unix-Socket-Modus geöffnet wurde . Diese Lösung funktioniert jedoch nur, wenn die Cloud SQL-Instanz eine öffentliche IP hat.
    Im Fall von nur privater IP und selbst wenn eine Der private IP-Verbindungsmodus ist mit dem Cloud SQL-Proxy vorhanden. funktioniert nicht!

    Verbinden Sie die serverlosen Dienste mit der privaten Cloud SQL-IP

    Hoffentlich gibt es eine Lösung. Sie können auf private IP in den Cloud SQL-Verbindungs-Tutorials hierfür ( Beispiel für Cloud-Funktionen ).

    Zusammenfassend müssen Sie:

    • Erstellen Sie eine serverloser VPC-Connector in derselben Region wie Ihr serverloser Dienst. Und natürlich mit derselben VPC wie Ihre Cloud SQL-Instanz verbunden.
      Beachten Sie, dass heute alle Regionen vom serverlosen VPC-Connector unterstützt werden, dies war jedoch eine Weile nicht der Fall.
    • Stellen Sie Ihren serverlosen Dienst mit diesem VPC-Connector bereit, der von Cloud-Ausführung , Cloud-Funktionen und App Engine
    • Verwenden Sie in Ihrer App die private Cloud SQL-IP (anstelle der Unix-Socket-Verbindung)

    Diese Lösung funktioniert, führt jedoch ein neues Netzwerkelement , ein zusätzliche Kosten und eine mögliche neue Fehlerstelle in der Konnektivitätskette.

    Das ist „schlecht“ !!

    The Ugly: Lokale Umgebungskonnektivität

    Wenn Sie Ihre Datenbank abfragen möchten , irgendwann in der Produktion, über Ihre auf Ihrem Computer installierte bevorzugte Datenbank-IDE müssen Sie Ihre lokale Umgebung mit der Cloud verbinden SQL-Instanz und damit über die private IP.

    Da die Cloud SQL-Instanz keine öffentliche IP hat, können Sie diese nicht direkt von erreichen Das Internet (Ihr Computer) und Cloud SQL-Proxy können auch nicht . Die Lösung besteht darin, eine Bastion-Host : eine Brücken-VM zwischen der Außenwelt (öffentliche IP) und der Innenwelt (private IP).

    Erstellen Sie dazu eine kleine Compute Engine-Instanz , beispielsweise eine f1-micro ( sehr erschwinglich (weniger als 5 USD pro Monat), um dies zu erreichen.

    Anforderung des Sicherheitsteams : Alle VMs dürfen keine öffentliche IP haben. Natürlich sind Firewall-Regeln für 0.0.0.0/0 nicht zulässig, insbesondere für Port 22 (ssh)

    Bastion-Host ohne öffentliche IP

    Neue Einschränkungen ! Aber es ist konsequent: Wenn Sie die Tür schließen, müssen Sie das Fenster öffnen lassen !!
    Kein Problem, Google Cloud bietet hierfür eine großartige und einfache Lösung: Identitätsbewusster Proxy (IAP)

    Bei IAP müssen Sie nur einen Google Cloud IAP gewähren IP-Bereich

    35.235.240.0/20 für den Zugriff auf Ihre Compute Engine an Port 22 in Ihren Firewall-Regeln . Daher ist es nicht erforderlich, 0.0.0.0/0 (das gesamte Internet) zu öffnen Erreichen Sie den Compute Engine ssh -Port!

    Verwenden Sie dann das gcloud SDK, um eine Verbindung zu Ihrem Bastion-Host Compute herzustellen Engine-Instanz
    gcloud compute ssh --zone=
    Und die Magie passiert! Das gcloud SDK erkennt automatisch das Fehlen einer öffentlichen IP der Compute Engine Instanz und öffnet automatisch einen IAP-Tunnel, um in SSH die Instanz zu verbinden. Es ist für den Benutzer unsichtbar!

    Der Berechtigungsnachweis (hier das Benutzerkonto, aber es kann sich auch um ein Dienstkonto handeln) muss über ausreichende Berechtigungen zum Erstellen eines IAP-Tunnels verfügen . Die Rollen sind role / iap.tunnelResourceAccessor zum Erstellen des Tunnels und role / compute.instanceAdmin.v1 für den Zugriff auf die VM

    Jetzt sind Sie mit dem Bastion-Host verbunden, aber Sie haben die Cloud SQL-Instanz noch nicht verbunden

    IAP-Tunneling, SSL-Portweiterleitung und Cloud SQL-Proxy

    Und dort beginnt der Teil „hässlich“ . Wir haben zwei Dinge zu erreichen:

    1. Verbinden den Bastion-Host mit der Cloud SQL-Instanz über Die private IP
    2. Leitet die Verbindungsanforderung für die lokale Umgebungsdatenbank an den Bastion-Host an Erreichen Sie die Cloud SQL-Instanz über den Cloud SQL-Proxy-Tunnel

    1. Cloud SQL-Instanzkonnektivität vom Bastion-Host
    Dazu benötigen wir den Cloud SQL-Proxy, um einen Tunnel zwischen dem Bastion-Host und der Cloud SQL-Instanz zu öffnen.

    Erste Ausgabe: Weil Sie Sie haben keine öffentliche IP, Sie können das Internet nicht erreichen!
    Sie können wählen, ob eine Cloud NAT auf dem IP-Bereich der Compute Instance Ihres Bastion-Hosts. Am einfachsten ist es jedoch, in Ihrer lokalen Umgebung herunterzuladen und dann kopiere es auf den Bastion-Host . Um dies zu erreichen, können Sie diesen Befehl verwenden.
    gcloud compute scp /local/path/to/cloud_sql_proxy :/tmp
    Da Sie eine SSH-Verbindung über IAP öffnen können, können Sie auch scp Protokoll (SSH-Kopie) nach Dateien über IAP kopieren! Magie !!

    Großartig, jetzt haben Sie die Binärdatei auf der Compute Engine-Instanz des Bastion-Hosts und Sie möchte testen, ob die Verbindung funktioniert . Sie können die Befehle

    #Connect to bastion host
    gcloud compute ssh --zone=
    #Change the permission of the Cloud SQL proxy binary (do it only once)
    chmod +x /tmp/cloud_sql_proxy
    #Connect to your Cloud SQL instance
    /tmp/cloud_sql_proxy --instances==tcp:3306

    ausführen. Sie finden die connection_name auf der Seite Ihrer Cloud SQL-Instanz

    Zweites Problem: es funktioniert nicht! Und es gibt viele Gründe!

    • Wenn Sie Ihren Bastion-Host erstellt haben Compute Engine mit den Standardparametern , insbesondere der API-Bereichsteil, Sie haben nicht genügend Bereich, um die Cloud SQL-APIs zu erreichen.
      Um dies zu lösen, müssen Sie Ihre Compute Engine stoppen, bearbeiten und Passen Sie die Bereiche an.
    • Wenn der Cloud SQL-Tunnel erstellt wird, werden die IAM-Berechtigungen der aktuellen Anmeldeinformationen (hier werden die Compute Engine-Anmeldeinformationen ) überprüft . Das Compute Engine-Dienstkonto verfügt möglicherweise nicht über genügend Berechtigungen.
      Um dies zu beheben, stellen Sie sicher, dass die Mindestrollen für das Dienstkonto gewährt werden: Cloud SQL client, Cloud SQL editor oder Cloud SQL admin
      Das Standarddienstkonto der Compute Engine verfügt über Rollen / Editor Rolle. Zu breit, aber genug für unseren Anwendungsfall.
    • Wenn Sie standardmäßig eine Google Cloud-API anfordern, wird standardmäßig das öffentliche DNS angefordert . Dies tritt auf, wenn der Cloud SQL-Proxy beim Erstellen des Tunnels die Cloud SQL-API oder den IAM-Dienst anfordert. Und da die Bastion Host Compute Engine keine öffentliche IP hat, kann sie das Internet und die googleapis.com öffentliches DNS.
      Um dies zu lösen, haben Sie zwei Lösungen.Entweder richtet ein Cloud-NAT wie zuvor vorgeschlagen ein oder verwendet eine knifflige Funktion von Google Cloud VPC: Erlaube das aktuelle Subnetz der Bastion Host Compute Engine um die private

      googleapis.com DNS . Gehen Sie dazu zu Ihrer VPC, wählen Sie das richtige Subnetz aus und bearbeiten Sie es. Wählen Sie dann On für das Optionsfeld „Privater Google-Zugriff“ und speichern Sie.

    Großartig !! Jetzt kann die Bastion Host Compute Engine den Cloud SQL-Proxy verwenden, um einen Tunnel vom lokalen Port 3306 zur Cloud SQL-Instanz zu öffnen. über die private IP.

    2. Leiten Sie den lokalen Umgebungsverkehr an die Cloud SQL-Instanz weiter.
    Um dies zu erreichen, verwenden wir nicht die gcloud ssh integrierte Funktion, aber eine alternative Lösung . Neben einer direkten Verbindung mit ssh zu Recheninstanzen ermöglicht das gcloud SDK das Erstellen eines Tunnels an beliebigen Ports .

    Erstellen wir also einen Tunnel an Port 22 des Bastion-Hosts Engine-Instanz berechnen und einen beliebigen lokalen Port definieren (hier 4226)

    gcloud compute start-iap-tunnel  22 \
    --zone= --local-host-port=localhost:4226

    Großartig, ein Tunnel ist öffnen und wir können es verwenden, um die Compute Engine-Instanz des Bastion-Hosts in ssh zu verbinden.

    Lassen Sie den Tunnel in einem Terminal öffnen und laufen und öffnen eine neue.

    Nun, verbinden wir uns mit ssh dazu . In einem Befehl erreichen Sie mehrere obligatorische Dinge, um die Verbindung herzustellen. :

    • Erstellen Sie eine Portweiterleitung von Ihrer lokalen Umgebung an den Bastion-Host. compute engine
      -L 3306:localhost:3306
      “Mein lokaler Port 3306 wird auf der Ziel-VM (hier dem Bastion-Host) weitergeleitet, um den Port 3306 wurde auf dem localhost (dh der Ziel-VM) „
    • Verwenden Sie den von Google während des ersten ssh „d5795cfc2e“>

    automatisch wieder / div> Verbindung zur Compute Engine des Bastion-Hosts (oder scp). Dieser private Schlüssel wird im Verzeichnis home des aktuellen Benutzers ~/.ssh
    -i ~/.ssh/google_compute_engine

  • Öffnen Sie eine ssh Verbindung über den vorhandenen IAP-Tunnel in der Umgebung localhost und Weiterleiten der ssh Datenverkehr vom lokalen Port 4226
    -p 4226 localhost
  • Bei Verbindung mit der Bastion Host Compute Engine Sie möchten den Cloud SQL-Proxy ausführen, um den Tunnel zur Cloud SQL-Instanz am Port 3306 zu erstellen. Führen Sie dazu den gewünschten Befehl auf der Fernbedienung (dem Bastion-Host) nach einem --
    -- /tmp/cloud_sql_proxy instances==tcp:3306
  • aus

    Und alles zusammen

    ssh -L 3306:localhost:3306 \
    -i ~/.ssh/google_compute_engine \
    -p 4226 localhost \
    -- /tmp/cloud_sql_proxy instances==tcp:3306

    Jetzt haben Sie es! Verwenden Sie Ihre bevorzugte Datenbank-IDE, verbinden Sie sie mit localhost:3306 und melden Sie sich mit dem Benutzer / Passwort in Ihrer Datenbank an.

    Wow !! All dies, um einem Sicherheitsmuster entsprechen zu können ! Hier ein Schema dessen, was wir erstellt haben

    Das ist „hässlich“ !!

    Zusätzlicher Nebeneffekt

    Verwenden von Cloud SQL mit einer privaten IP fügt nur Einschränkungen hinzu . In der Tat wird ein Peering zwischen der VPC des Projekts und dem Cloud SQL-Netzwerk (verwaltet von Google Cloud) erstellt.
    Und Peering unterliegt zwei Einschränkungen:

    Dieser letzte Punkt ist sehr wichtig und kann ein Blocker sein, wenn Sie die Datenbankinstanz von einem anderen Projekt aus erreichen möchten . In der Tat möchten Sie aus der VPC eines anderen Projekts ein Peering mit dem Projekt erstellen, das die Cloud SQL-Instanz über die private IP erreichen kann.

    Aufgrund der Transitivitätsbeschränkung können Sie dies jedoch t: Die private Cloud SQL-IP wird in der VPC des anderen Projekts nicht angezeigt.
    Die Problemumgehung besteht darin, ein VPN zu erstellen, um die beiden VPCs zu vergleichen. .
    Das ist euh … „hässlichste“ ??

    Ein zusätzlicher Nebeneffekt ist Die Unfähigkeit von App Script-Apps, Cloud SQL-Instanzen zu verwenden, wenn keine öffentliche IP definiert ist.

    „Intelligentes“ Sicherheitsmuster ist wichtig

    Sicherheitsaspekt und die vorhandenen Muster für Datenbanken Arbeit großartig … in der alten Welt.
    Mit Cloud SQL und Cloud SQL-Proxy sind jetzt zusätzliche Sicherheitsebenen vorhanden, und die alten Muster werden ungültig.

    Was ist das Problem, wenn eine öffentliche IP hat, wenn keine IP-Bereiche zulässig sind , um eine Verbindung herzustellen ?

    Es ist die Definition einer Firewall-Regel in der alten Welt, nicht wahr? nicht wahr? Verweigern Sie allen IPs den Zugriff auf diesen Bereich / diese IP, auf der meine Datenbanken gehostet werden.

    Bedenken des Sicherheitsteams : Wie kann ich sicherstellen, dass kein IP-Bereich zulässig ist?

    Diese Frage ist legitim und deshalb können Sie eine Organisationsrichtlinie erzwingen ( einschränken Autorisierte Netzwerke in Cloud SQL-Instanzen ) bis verhindern das Hinzufügen eines öffentlichen IP-Bereichs auf Cloud SQL-Instanzen und dies unternehmensweit.

    Das Zulassen einer öffentlichen IP in Cloud SQL-Instanzen vermeidet viele Problemumgehungen und seltsame Designs und ohne die Sicherheitsstufe zu verringern.
    Darüber hinaus ist der erstellte Tunnel verschlüsselt und gewährleistet ein hohes Maß an Sicherheit und Vertraulichkeit.

    Die Cloud ändert die Paradigmen (siehe Beyond Corp ) und das Sicherheitsmuster muss aktualisiert werden, um diesen zu entsprechen.
    Intelligente Sicherheitsmuster sind besser als ältere Sicherheitsmuster!

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.