VPC Service Controls-konformen privaten Endpunkt aufrufen

Sie können einen privaten Endpunkt für HTTP-Aufrufe aus der Workflowausführung festlegen, indem Sie die Dienstregistrierung von Service Directory mit Workflows verwenden. Wenn Sie einen privaten Endpunkt in einem VPC-Netzwerk (Virtual Private Cloud) erstellen, kann der Endpunkt VPC Service Controls-kompatibel sein.

VPC Service Controls ist einGoogle Cloud -Feature, mit dem Sie einen Dienstperimeter einrichten und eine Datenübertragungsgrenze erstellen können. Dies bietet eine zusätzliche Sicherheitsebene, die unabhängig von der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) ist. Im Gegensatz zur detaillierten identitätsbasierten Zugriffssteuerung von IAM ermöglicht VPC Service Controls eine breitere kontextbasierte Perimetersicherheit, einschließlich der Kontrolle ausgehender Datenübertragungen im gesamten Perimeter.

Nachdem Sie die Schritte in diesem Leitfaden ausgeführt haben, können Sie einen Dienstperimeter erstellen und VPC Service Controls mit Workflows verwenden, um das Risiko einer Daten-Exfiltration zu verringern.

Übersicht über registrierte Netzwerkdienste

In diesem Dokument wird beschrieben, wie Sie eine VM in einem VPC-Netzwerk als Service Directory-Endpunkt registrieren. So können Sie Ihrem Workflow einen Service Directory-Dienstnamen zur Verfügung stellen. Bei der Ausführung des Workflows werden die aus der Dienstregistrierung abgerufenen Informationen verwendet, um die entsprechende HTTP-Anfrage zu senden, ohne dass ein öffentliches Netzwerk verwendet wird.

  • Ein VPC-Netzwerk bietet Konnektivität für Ihre VM-Instanzen (virtuelle Maschinen) und ermöglicht es Ihnen, private Endpunkte in Ihrem VPC-Netzwerk mit internen IP-Adressen zu erstellen. HTTP-Aufrufe an eine VPC-Netzwerkressource werden über ein privates Netzwerk gesendet, während IAM und VPC Service Controls erzwungen werden.

  • Service Directory ist eine Dienst-Registry, in der Informationen zu registrierten Netzwerkdiensten gespeichert werden, einschließlich ihrer Namen, Standorte und Attribute. Unabhängig von ihrer Infrastruktur können Sie Dienste automatisch registrieren und ihre Details erfassen. So können Sie Dienste für alle Ihre Dienstendpunkte im großen Maßstab erkennen, veröffentlichen und verbinden.

Dieses Diagramm bietet einen Überblick:

HTTP-Anfrage an eine Portnummer auf einer VM-Instanz mit Informationen aus Service Directory senden

Hier ist eine allgemeine Liste der erforderlichen Aufgaben:

  1. Berechtigungen für den Cloud Workflows-Dienst-Agent gewähren, damit der Dienst-Agent Service Directory-Ressourcen ansehen und über Service Directory auf VPC-Netzwerke zugreifen kann.
  2. Erstellen Sie ein VPC-Netzwerk, um Netzwerkfunktionen bereitzustellen.
  3. Erstellen Sie eine VPC-Firewallregel, um Traffic zu oder von VM-Instanzen in Ihrem VPC-Netzwerk zuzulassen oder abzulehnen.
  4. Erstellen Sie eine VM-Instanz im VPC-Netzwerk. Eine Compute Engine-VM-Instanz ist eine virtuelle Maschine, die in der Infrastruktur von Google gehostet wird. Die Begriffe Compute Engine-Instanz, VM-Instanz und VM werden synonym verwendet.
  5. Anwendung auf der VM bereitstellen Sie können eine App auf Ihrer VM-Instanz ausführen und prüfen, ob der Traffic wie erwartet bereitgestellt wird.
  6. Service Directory konfigurieren, damit bei der Ausführung Ihres Workflows ein Service Directory-Endpunkt aufgerufen werden kann.

  7. Workflow erstellen und bereitstellen Der Wert private_service_name in Ihrem Workflow gibt den Service Directory-Endpunkt an, den Sie im vorherigen Schritt registriert haben.

Berechtigungen für den Cloud Workflows-Dienst-Agent erteilen

Einige Google Cloud -Dienste haben Dienst-Agents, mit denen die Dienste auf Ihre Ressourcen zugreifen können. Wenn eine API einen Dienst-Agent erfordert, erstellt Google den Dienst-Agent, nachdem Sie die API aktiviert und verwendet haben.

  1. Wenn Sie zum ersten Mal einen Workflow bereitstellen, wird der Cloud Workflows-Dienst-Agent automatisch im folgenden Format erstellt:

    service-PROJECT_NUMBER@gcp-sa-workflows.iam.gserviceaccount.com

    Sie können das Dienstkonto mit diesem Befehl manuell in einem Projekt ohne Workflows erstellen:

    gcloud beta services identity create \
        --service=workflows.googleapis.com \
        --project=PROJECT_ID

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID. Google Cloud

  2. Wenn Sie Service Directory-Ressourcen ansehen möchten, weisen Sie dem Workflows-Dienst-Agent die Rolle „Service Directory-Betrachter“ (servicedirectory.viewer) für das Projekt zu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-workflows.iam.gserviceaccount.com \
        --role=roles/servicedirectory.viewer

    Ersetzen Sie PROJECT_NUMBER durch die Projektnummer Ihres Google Cloud-Projekts. Sie finden Ihre Projektnummer auf der Willkommensseite der Google Cloud -Konsole oder durch Ausführen des folgenden Befehls:

    gcloud projects describe PROJECT_ID --format='value(projectNumber)'
  3. Wenn Sie mit Service Directory auf VPC-Netzwerke zugreifen möchten, weisen Sie dem Workflows-Dienst-Agenten die Rolle Autorisierter Dienst für Private Service Connect (roles/servicedirectory.pscAuthorizedService) für das Projekt zu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-workflows.iam.gserviceaccount.com \
        --role=roles/servicedirectory.pscAuthorizedService

VPC-Netzwerk erstellen

Ein VPC-Netzwerk ist eine virtuelle Version eines physischen Netzwerks, die innerhalb des Produktionsnetzwerks von Google implementiert wurde. Sie ermöglicht eine Verbindung für Ihre Compute Engine-VM-Instanzen.

Sie können ein VPC-Netzwerk im automatischen oder benutzerdefinierten Modus erstellen. Jedes neu erstellte Netzwerk muss innerhalb des Projekts einen eindeutigen Namen haben.

Mit dem folgenden Befehl wird beispielsweise ein VPC-Netzwerk im automatischen Modus erstellt:

gcloud compute networks create NETWORK_NAME \
    --subnet-mode=auto

Ersetzen Sie NETWORK_NAME durch einen Namen für das VPC-Netzwerk.

Weitere Informationen finden Sie unter VPC-Netzwerke erstellen und verwalten.

VPC-Firewallregel erstellen

Mit VPC-Firewallregeln können Sie den Traffic zu oder von VM-Instanzen in einem VPC-Netzwerk anhand einer Portnummer, eines Tags oder eines Protokolls zulassen oder ablehnen.

VPC-Firewallregeln werden auf Netzwerkebene definiert und gelten nur für das Netzwerk, in dem sie erstellt werden. Der Name für jede Regel muss jedoch für das Projekt eindeutig sein.

Mit dem folgenden Befehl wird beispielsweise eine Firewallregel für das VPC-Netzwerk erstellt, das Sie zuvor erstellt haben.

gcloud compute firewall-rules create RULE_NAME \
    --network=projects/PROJECT_ID/global/networks/NETWORK_NAME \
    --direction=INGRESS \
    --action=ALLOW \
    --source-ranges=IP_ADDRESS_RANGE \
    --rules=all

Ersetzen Sie Folgendes:

  • RULE_NAME ist ein Name für die Firewallregel.

  • IP_ADDRESS_RANGE: ein oder mehrere IPv4- oder IPv6-Adressbereiche. Als Best Practice sollten Sie die spezifischen IP-Adressbereiche angeben, die für den Zugriff erforderlich sind. Wichtige Hinweise:

    • Der private Netzwerkzugriff für Service Directory verwendet 35.199.192.0/19 als rein internen Bereich mit nächsten Hops, die sich vollständig im Google-Netzwerk befinden. Weitere Informationen finden Sie unter Pfade für Cloud DNS und Service Directory.

    • Wenn Sie 35.235.240.0/20 in die Quellbereiche aufnehmen, sind SSH-Verbindungen mit der TCP-Weiterleitung von Identity-Aware Proxy (IAP) möglich, wenn alle anderen Voraussetzungen erfüllt sind. Weitere Informationen finden Sie unter IAP für TCP-Weiterleitung verwenden.

    • Wenn Sie das SSH-Browsertool verwenden, um über die Google Cloud -Konsole eine Verbindung zu Ihrer Compute Engine-VM herzustellen, gelten bestimmte Anforderungen.

  • Der --rules-Flag-Wert all bewirkt, dass die Firewallregel für alle Protokolle und alle Zielports gilt. Sie können den Umfang durch Angabe von Protokollen und Ports einschränken.

  • Optional können Sie die Flags --target-tags und --target-service-accounts verwenden, um Ziele zu definieren. Andernfalls gilt die Regel für alle Ziele im Netzwerk.

Weitere Informationen finden Sie unter VPC-Firewallregeln verwenden.

VM-Instanz im VPC-Netzwerk erstellen

VM-Instanzen umfassen Google Kubernetes Engine-Cluster (GKE), Instanzen der flexiblen App Engine-Umgebung und andere Google Cloud Produkte, die auf Compute Engine-VMs basieren. Zur Unterstützung des Zugriffs auf private Netzwerke kann eine VPC-Netzwerkressource eine VM-Instanz, eine Cloud Interconnect-IP-Adresse oder ein interner Layer 4-Load-Balancer sein.

Auf Compute Engine-Instanzen können die von Google bereitgestellten öffentlichen Images für Linux und Windows Server ausgeführt werden. Dasselbe gilt für private benutzerdefinierte Images, die Sie erstellen oder von vorhandenen Systemen importieren können. Sie können auch Docker-Container bereitstellen.

Sie können die Maschinenattribute Ihrer Instanzen auswählen, z. B. die Anzahl der virtuellen CPUs oder die Größe des Arbeitsspeichers, und zwar entweder mit vordefinierten Maschinentypen oder mit Ihren eigenen benutzerdefinierten Maschinentypen.

Mit dem folgenden Befehl wird beispielsweise eine Linux-VM-Instanz aus einem öffentlichen Image mit einer Netzwerkschnittstelle erstellt, die an das zuvor erstellte VPC-Netzwerk angehängt ist.

  1. VM-Instanz erstellen und starten:

    gcloud compute instances create VM_NAME \
        --image-family=debian-11 \
        --image-project=debian-cloud \
        --machine-type=e2-micro \
        --network-interface network=projects/PROJECT_ID/global/networks/NETWORK_NAME

    Ersetzen Sie VM_NAME durch einen Namen für die VM.

  2. Wenn Sie aufgefordert werden, die Zone für die Instanz zu bestätigen, geben Sie y ein.

    Notieren Sie sich nach dem Erstellen der VM-Instanz die zurückgegebene INTERNAL_IP-Adresse.

  3. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf:

    Zu Seite „VM-Instanzen“

  4. Klicken Sie in der Spalte Name auf den Namen der entsprechenden VM-Instanz.

  5. Wenn die VM ausgeführt wird, klicken Sie zum Beenden der VM auf  Beenden.

  6. Klicken Sie zum Bearbeiten der VM auf  Bearbeiten.

  7. Wählen Sie im Bereich Netzwerk > Firewalls die Option HTTP-Traffic zulassen oder HTTPS-Traffic zulassen aus, um HTTP- oder HTTPS-Traffic zur VM zuzulassen.

    Klicken Sie in diesem Beispiel das Kästchen HTTP-Traffic zulassen an.

    Compute Engine fügt Ihrer VM ein Netzwerk-Tag hinzu, das die Firewallregel mit der VM verknüpft. Anschließend wird die entsprechende Firewallregel für eingehenden Traffic erstellt, die den gesamten eingehenden Traffic über tcp:80 (HTTP) oder tcp:443 (HTTPS) zulässt.

  8. Um die Änderungen zu speichern, klicken Sie auf Speichern.

  9. Klicken Sie auf Starten/Fortsetzen, um die VM neu zu starten.

Weitere Informationen finden Sie unter VM-Instanz erstellen und starten.

Anwendung auf der VM bereitstellen

Um die Netzwerkkonfiguration zu testen und zu bestätigen, dass der Traffic wie erwartet bereitgestellt wird, können Sie eine einfache App auf Ihrer VM bereitstellen, die einen Port überwacht.

Mit den folgenden Befehlen wird beispielsweise ein Node.js-Webdienst erstellt, der an Port 3000 empfangsbereit ist.

  1. Stellen Sie eine SSH-Verbindung zu Ihrer VM-Instanz her.

  2. Aktualisieren Sie die Paket-Repositorys:

    sudo apt update
  3. Installieren Sie NVM, Node.js und npm.

    Weitere Informationen finden Sie unter Node.js-Entwicklungsumgebung einrichten.

  4. package.json-Datei interaktiv erstellen:

    npm init

    Beispiel:

    {
    "name": "test",
    "version": "1.0.0",
    "description": "",
    "main": "index.js",
    "scripts": {
    "test": "hello"
    },
    "author": "",
    "license": "ISC"
    }
  5. Installieren Sie Express, ein Webanwendungs-Framework für Node.js:

    npm install express
  6. Schreiben Sie den Code für die Test-App:

    vim app.js

    Im folgenden Beispiel wird eine App erstellt, die auf GET-Anfragen an den Root-Pfad (/) mit dem Text „Hello, world!“ antwortet.

    const express = require('express');
    const app = express();
    
    app.get('/', (req, res) => {
      res.status(200).send('Hello, world!').end();
    });
    
    app.listen(3000, () => {
      console.log('Sample app listening on port 3000.');
    });

    Notieren Sie sich den Port, den die App überwacht. Beim Konfigurieren des Endpunkts für den Service Directory-Dienst muss dieselbe Portnummer verwendet werden.

  7. Prüfen Sie, ob die App Port 3000 überwacht:

    node app.js

Compute Engine bietet eine Reihe von Bereitstellungsoptionen. Weitere Informationen finden Sie unter Compute Engine-Bereitstellungsstrategie für Ihre Arbeitslast auswählen.

Service Directory konfigurieren

Damit ein privater Endpunkt über die Ausführung eines Workflows aufgerufen werden kann, müssen Sie einen Service Directory-Namespace einrichten, einen Dienst im Namespace registrieren und dem Dienst einen Endpunkt hinzufügen.

Mit den folgenden Befehlen werden beispielsweise ein Namespace, ein Dienst und ein Endpunkt erstellt, der das VPC-Netzwerk und die interne IP-Adresse Ihrer VM-Instanz angibt.

  1. Erstellen Sie einen Namespace:

    gcloud service-directory namespaces create NAMESPACE \
        --location=REGION

    Ersetzen Sie Folgendes:

    • NAMESPACE: Die ID des Namespace oder die voll qualifizierte Kennzeichnung für den Namespace.
    • REGION: die Google Cloud Region, die den Namespace enthält, z. B. us-central1.
  2. Dienst erstellen:

    gcloud service-directory services create SERVICE \
        --namespace=NAMESPACE \
        --location=REGION

    Ersetzen Sie SERVICE durch den Namen des Dienstes, den Sie erstellen.

  3. Konfigurieren Sie einen Endpunkt.

    gcloud service-directory endpoints create ENDPOINT \
        --namespace=NAMESPACE \
        --service=SERVICE \
        --network=projects/PROJECT_NUMBER/locations/global/networks/NETWORK_NAME \
        --port=PORT_NUMBER \
        --address=IP_ADDRESS \
        --location=REGION

    Ersetzen Sie Folgendes:

    • ENDPOINT: der Name des Endpunkts, den Sie erstellen.
    • PORT_NUMBER: der Port, auf dem der Endpunkt ausgeführt wird, z. B. 3000.
    • IP_ADDRESS: die IPv6- oder IPv4-Adresse des Endpunkts. Das ist die interne IP-Adresse, die Sie sich zuvor notiert haben.

Weitere Informationen finden Sie unter Service Directory konfigurieren und Zugriff auf private Netzwerke konfigurieren.

Workflow erstellen und bereitstellen

Der Aufruf eines privaten Endpunkts über Workflows erfolgt über eine HTTP-Anfrage. Die gängigsten Methoden für HTTP-Anfragen haben eine Aufrufverknüpfung wie http.get und http.post. Sie können aber eine beliebige Methode verwenden, um Typ der HTTP-Anfrage. Dazu setzen Sie das Feld call auf http.request und geben den Anfragetyp im Feld method an. Weitere Informationen finden Sie unter HTTP-Anfrage stellen.

  1. Erstellen Sie eine Quellcodedatei für Ihren Workflow:

    touch call-private-endpoint.JSON_OR_YAML

    Ersetzen Sie JSON_OR_YAML durch yaml oder json, je nach Format Ihres Workflows.

  2. Kopieren Sie den folgenden Workflow (in diesem Fall wird ein HTTP-Protokoll für den url-Wert verwendet) in Ihre Quellcodedatei:

    YAML

    main:
      steps:
        - checkHttp:
            call: http.get
            args:
              url: http://IP_ADDRESS
              private_service_name: "projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE"
            result: res
        - ret:
            return: ${res}

    JSON

    {
      "main": {
        "steps": [
          {
            "checkHttp": {
              "call": "http.get",
              "args": {
                "url": "http://IP_ADDRESS",
                "private_service_name": "projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE"
              },
              "result": "res"
            }
          },
          {
            "ret": {
              "return": "${res}"
            }
          }
        ]
      }
    }

    Der Wert private_service_name muss ein String sein, der einen registrierten Service Directory-Dienstnamen im folgenden Format angibt:

    projects/PROJECT_ID/locations/LOCATION/namespaces/NAMESPACE_NAME/services/SERVICE_NAME

  3. Stellen Sie den Workflow bereit. Zu Testzwecken können Sie das Compute Engine-Standarddienstkonto an den Workflow anhängen, um seine Identität darzustellen:

    gcloud workflows deploy call-private-endpoint \
        --source=call-private-endpoint.JSON_OR_YAML \
        --location=REGION \
        --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com
  4. Führen Sie den Workflow aus:

    gcloud workflows run call-private-endpoint \
        --location=REGION

    Das Ergebnis sollte etwa so aussehen:

    argument: 'null'
    duration: 0.650784403s
    endTime: '2023-06-09T18:19:52.570690079Z'
    name: projects/968807934019/locations/us-central1/workflows/call-private-endpoint/executions/4aac88d3-0b54-419b-b364-b6eb973cc932
    result: '{"body":"Hello, world!","code":200,"headers":{"Connection":"keep-alive","Content-Length":"21","Content-Type":"text/html;
    charset=utf-8","Date":"Fri, 09 Jun 2023 18:19:52 GMT","Etag":"W/\"15-NFaeBgdti+9S7zm5kAdSuGJQm6Q\"","Keep-Alive":"timeout=5","X-Powered-By":"Express"}}'
    startTime: '2023-06-09T18:19:51.919905676Z'
    state: SUCCEEDED

Nächste Schritte