Internetzugriff und Firewallregeln konfigurieren

In diesem Dokument wird erläutert, wie Sie Dataflow-VM-Instanzen für den Internetzugriff konfigurieren, Netzwerk-Tags erstellen und Firewallregeln für das mit Ihren Dataflow-Jobs verknüpfte Netzwerk definieren.

Für dieses Dokument sind Grundkenntnisse über Google Cloud-Netzwerke erforderlich. Informationen zum Definieren eines Netzwerks für Ihren Dataflow-Job finden Sie unter Netzwerk und Subnetzwerk angeben.

Hinweis: Das Netzwerk default enthält Konfigurationen, durch die Dataflow-Jobs ausgeführt werden können. Andere Dienste können dieses Netzwerk jedoch auch verwenden. Achten Sie darauf, dass die Änderungen im Netzwerk default mit allen Ihren Diensten kompatibel sind. Erstellen Sie alternativ ein separates Netzwerk für Dataflow.

Internetzugang für Dataflow

Virtuelle Maschinen (VMs) von Dataflow-Workern müssen Google Cloud APIs und Dienste erreichen. Je nach Anwendungsfall benötigen Ihre VMs möglicherweise auch Zugriff auf Ressourcen außerhalb von Google Cloud. Verwenden Sie eine der folgenden Methoden, um den Internetzugriff für Dataflow zu konfigurieren:

• Konfigurieren Sie Worker-VMs mit einer externen IP-Adresse, damit sie den Anforderungen für den Internetzugriff entsprechen.

• Konfigurieren Sie den privaten Google-Zugriff. Mit privatem Google-Zugriff können VMs, die nur interne IP-Adressen haben, auf IP-Adressen für Google Cloud und Dienste zugreifen.

• Konfigurieren Sie eine Private Service Connect-Endpunkt-IP-Adresse für den Zugriff auf Google Cloud APIs und Dienste.

• Konfigurieren Sie eine NAT-Lösung, z. B. Cloud NAT. Diese Option dient zum Ausführen von Jobs, die auf APIs und Dienste außerhalb von Google Cloud zugreifen, die Internetzugriff benötigen. Beispielsweise benötigen Python SDK-Jobs möglicherweise Zugriff auf den Python-Paketindex (PyPI), um Pipelineabhängigkeiten herunterzuladen. In diesem Fall müssen Sie entweder Worker-VMs mit externen IP-Adressen konfigurieren oder Cloud NAT verwenden. Sie können auch Python-Pipelineabhängigkeiten während der Jobübermittlung angeben. Sie können beispielsweise benutzerdefinierte Container verwenden, um Python-Pipelineabhängigkeiten bereitzustellen. Dadurch ist es nicht mehr erforderlich, auf PyPI zur Laufzeit zuzugreifen.

  Weitere Informationen finden Sie unter Python-Pipelineabhängigkeiten verwalten in der Apache Beam-Dokumentation.

Externe IP-Adresse deaktivieren

Standardmäßig weist der Dataflow-Dienst Workern sowohl externe als auch interne IP-Adressen zu. Wenn Sie externe IP-Adressen deaktivieren, kann die Dataflow-Pipeline nur auf Ressourcen an folgenden Orten zugreifen:

• Weitere Instanz im selben VPC-Netzwerk
• Freigegebenes VPC-Netzwerk
• Netzwerk mit aktiviertem VPC Network-Peering

Auch ohne externe IP-Adressen können Sie Verwaltungs- und Monitoringaufgaben ausführen. Wenn Sie auf Ihre Worker zugreifen möchten, verwenden Sie SSH über die oben aufgeführten Optionen. Die Pipeline kann jedoch nicht auf das Internet zugreifen und Internethosts haben keinen Zugriff auf Ihre Dataflow-Worker.

Wenn Sie keine externen IP-Adressen verwenden, ist Ihre Datenverarbeitungsinfrastruktur besser geschützt. Außerdem verringern Sie die Anzahl der externen IP-Adressen, die Sie im Rahmen Ihres Google Cloud-Projektkontingents nutzen.

Wenn Sie externe IP-Adressen deaktivieren, können Ihre Dataflow-Jobs nicht auf APIs und Dienste außerhalb von Google Cloud zugreifen, die Internetzugriff benötigen.

Informationen zum Einrichten des Internetzugriffs für Jobs mit internen IP-Adressen finden Sie im vorherigen Abschnitt.

Führen Sie einen der folgenden Schritte aus, um externe IP-Adressen zu deaktivieren:

Java

1. Aktivieren Sie Privaten Google-Zugriff für Ihr Netzwerk oder Subnetzwerk.
2. Legen Sie für die Parameter Ihres Dataflow-Jobs --usePublicIps=false und --network=NETWORK-NAME oder --subnetwork=SUBNETWORK-NAME fest.

   Ersetzen Sie je nach Auswahl einen der folgenden Strings:

   • NETWORK-NAME ist der Name Ihres Compute Engine-Netzwerks
   • SUBNETWORK-NAME ist der Name Ihres Compute Engine-Subnetzwerks

Python

1. Implementieren Sie alle Python-Paketabhängigkeiten gemäß der Anleitung zu den Apache Beam-Pipelineabhängigkeiten.
2. Aktivieren Sie Privaten Google-Zugriff für Ihr Netzwerk oder Subnetzwerk.
3. Legen Sie für die Parameter Ihres Dataflow-Jobs --no_use_public_ips und --network=NETWORK oder --subnetwork=SUBNETWORK fest.

Ersetzen Sie je nach Auswahl einen der folgenden Strings:

• NETWORK-NAME ist der Name Ihres Compute Engine-Netzwerks
• SUBNETWORK-NAME ist der Name Ihres Compute Engine-Subnetzwerks

Go

1. Aktivieren Sie Privaten Google-Zugriff für Ihr Netzwerk oder Subnetzwerk.
2. Legen Sie für die Parameter Ihres Dataflow-Jobs --no_use_public_ips und --network=NETWORK oder --subnetwork=SUBNETWORK fest.

Ersetzen Sie je nach Auswahl einen der folgenden Strings:

• NETWORK-NAME ist der Name Ihres Compute Engine-Netzwerks
• SUBNETWORK-NAME ist der Name Ihres Compute Engine-Subnetzwerks

Netzwerk-Tags für Dataflow

Netzwerk-Tags sind Textattribute, die Sie an Compute Engine-VMs anhängen können. Mit Netzwerk-Tags können Sie VPC-Netzwerk-Firewallregeln und bestimmte benutzerdefinierte statische Routen für bestimmte VM-Instanzen festlegen. Dataflow unterstützt das Hinzufügen von Netzwerk-Tags zu allen Worker-VMs, die einen bestimmten Dataflow-Job ausführen.

Auch wenn Sie den Netzwerkparameter nicht verwenden, fügt Dataflow jeder erstellten Worker-VM immer das Standard-Netzwerk-Tag dataflow hinzu.

Netzwerk-Tags aktivieren

Die Netzwerk-Tags können nur dann angegeben werden, wenn Sie die Dataflow-Jobvorlage zum Erstellen eines Jobs ausführen. Nachdem ein Job gestartet wurde, können Sie dem Job keine weiteren Netzwerk-Tags hinzufügen. Wenn Sie weitere Netzwerk-Tags auf einen Job anwenden möchten, müssen Sie Ihre Jobvorlage mit den erforderlichen Netzwerk-Tags neu erstellen.

Fügen Sie Ihrem Pipelinecode Folgendes hinzu, unabhängig davon, ob Sie in Java oder Python ausführen:

--experiments=use_network_tags=TAG-NAME

Ersetzen Sie TAG-NAME durch die Namen Ihrer Tags. Wenn Sie mehr als ein Tag hinzufügen, trennen Sie jedes Tag mit einem Semikolon (;) ab, wie im folgenden Format gezeigt: TAG-NAME-1;TAG-NAME-2;TAG-NAME-3;....

Auch wenn Sie diesen Parameter nicht verwenden, fügt Dataflow jeder erstellten Worker-VM immer das Netzwerk-Tag dataflow hinzu.

Netzwerk-Tags für Flex-Vorlagen-VMs aktivieren

Nutzen Sie bei Verwendung von Flex-Vorlagen die Option --additional-experiments, wie im folgenden Beispiel gezeigt, um Netzwerk-Tags für Dataflow-Worker-VMs zu aktivieren:

--additional-experiments=use_network_tags=TAG-NAME

Zum Aktivieren von Netzwerk-Tags für Worker-VMs und Launcher-VMs müssen Sie die folgenden beiden Optionen verwenden:

--additional-experiments=use_network_tags=TAG-NAME
--additional-experiments=use_network_tags_for_flex_templates=TAG-NAME

Ersetzen Sie TAG-NAME durch die Namen Ihrer Tags. Wenn Sie mehr als ein Tag hinzufügen, trennen Sie jedes Tag mit einem Semikolon (;) ab, wie im folgenden Format gezeigt: TAG-NAME-1;TAG-NAME-2;TAG-NAME-3;....

Nachdem Sie die Netzwerk-Tags aktiviert haben, werden die Tags geparst und an die VMs angehängt.

Hinweis: Wenn Sie das Netzwerk-Tag angeben, wird auch das Standard-Netzwerk-Tag Dataflow zu Flex-Vorlagen-Launcher-VMs hinzugefügt.

Siehe die geltenden Limits für Netzwerk-Tags.

Firewallregeln für Dataflow

Mit Firewallregeln können Sie Traffic zu und von Ihren VMs zulassen oder ablehnen. Wenn Ihre Dataflow-Jobs Dataflow Shuffle oder Streaming Engine verwenden, müssen Sie keine Firewallregeln konfigurieren. Andernfalls müssen Sie Firewallregeln konfigurieren, damit Dataflow-VMs Netzwerkverkehr über TCP-Port 12345 für Streaming-Jobs und TCP-Port 12346 für Batch-Jobs senden und empfangen können. Ein Projektinhaber, Projektbearbeiter oder Sicherheitsadministrator muss die erforderlichen Firewallregeln im VPC-Netzwerk erstellen, das von Ihren Dataflow-VMs verwendet wird.

Bevor Sie Firewallregeln für Dataflow konfigurieren, lesen Sie die folgenden Dokumente:

• Übersicht über VPC-Firewallregeln und Firewallregeln verwenden

• Übersicht über hierarchische Firewallrichtlinien und Hierarchische Firewallrichtlinien verwenden

Geben Sie beim Erstellen von Firewallregeln für Dataflow die Dataflow-Netzwerk-Tags an. Andernfalls gelten die Firewallregeln für alle VMs im VPC-Netzwerk.

Gegebenenfalls werden hierarchische Firewallrichtlinien zuerst ausgewertet und diese Regeln überschreiben VPC-Firewallregeln. Wenn sich der Dataflow-Job in einem Projekt befindet, das Teil eines Ordners oder einer Organisation ist, in der hierarchische Firewallrichtlinien verwendet werden, ist die Rolle compute.orgFirewallPolicyAdmin erforderlich, um Richtlinienänderungen vorzunehmen.

Wenn Sie beim Ausführen des Pipelinecodes keine benutzerdefinierten Netzwerk-Tags erstellt haben, verwenden Dataflow-VMs das Standard-Tag dataflow. Wenn keine benutzerdefinierten Netzwerk-Tags vorhanden sind, erstellen Sie Firewallregeln mit dem Standard-Tag dataflow.

Wenn Sie beim Ausführen des Pipelinecodes benutzerdefinierte Netzwerk-Tags erstellt haben, verwenden Dataflow-VMs diese Tags. Erstellen Sie die Firewallregeln mit den benutzerdefinierten Tags.

Einige VPC-Netzwerke, wie das automatisch erstellte Netzwerk default, enthalten die Regel default-allow-internal, die die Firewallanforderung für Dataflow erfüllt.

Beispiel einer Firewallregel für eingehenden Traffic

Die Firewallregel für eingehenden Traffic ermöglicht Dataflow-VMs, Pakete voneinander zu empfangen. Sie müssen immer Firewallregeln zum Zulassen von eingehendem Traffic erstellen, da der Traffic sonst immer blockiert wird, auch wenn Regeln für ausgehenden Traffic diesen Traffic zulassen.

Im folgenden Beispiel wird für Dataflow eine Firewallregel für eingehenden Traffic erstellt, wobei alle Worker-VMs das Standard-Netzwerk-Tag dataflow haben. Ein Projektinhaber, Projektbearbeiter oder Sicherheitsadministrator kann mit dem folgenden gcloud-Befehl eine Regel zum Zulassen von eingehendem Traffic erstellen. Diese lässt Traffic über die TCP-Ports 12345 und 12346 von VMs mit dem Netzwerk-Tag dataflow zu anderen VMs mit demselben Tag zu:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_INGRESS \
    --action=allow \
    --direction=ingress \
    --network=NETWORK  \
    --target-tags=CUSTOM_TAG \
    --source-tags=CUSTOM_TAG \
    --priority=PRIORITY_NUM \
    --rules tcp:12345-12346

Dabei gilt:

• FIREWALL_RULE_NAME_INGRESS ist ein Name für die Firewallregel.

• NETWORK: der Name des Netzwerks, das die Worker-VMs verwenden

• CUSTOM_TAG ist eine durch Kommas getrennte Liste von Netzwerk-Tags.

  Die folgende Liste enthält Richtlinien zur Verwendung von Netzwerk-Tags:

  • Wenn Sie --target-tags weglassen, gilt die Regel für alle VMs im VPC-Netzwerk.

  • Wenn Sie --source-tags und alle anderen Quellspezifikationen weglassen, ist Traffic von jeder Quelle zulässig.

  • Wenn Sie keine benutzerdefinierten Netzwerk-Tags angegeben haben und die Regel für Dataflow-VMs spezifisch sein soll, verwenden Sie dataflow als Netzwerk-Tag.

  • Wenn Sie benutzerdefinierte Netzwerk-Tags angegeben haben und die Regel für Dataflow-VMs spezifisch sein soll, verwenden Sie Ihre benutzerdefinierten Netzwerk-Tags.

• PRIORITY_NUM: die Priorität der Firewallregel

  Niedrigere Zahlen haben höhere Prioritäten und 0 ist die höchste Priorität.

Beispiel für eine Firewallregel für ausgehenden Traffic

Die Firewallregel für ausgehenden Traffic ermöglicht Dataflow-VMs, Pakete aneinander zu senden. Wenn Sie Firewallregeln für abzulehnenden ausgehenden Traffic erstellt haben, müssen Sie möglicherweise benutzerdefinierte Firewallregeln zum Zulassen von ausgehendem Traffic in Ihrem VPC-Netzwerk erstellen.

In diesem Beispiel wird eine Firewallregel für ausgehenden Traffic für Dataflow erstellt, wobei alle Worker-VMs das Standard-Netzwerk-Tag dataflow haben. Ein Projektinhaber, Projektbearbeiter oder Sicherheitsadministrator kann mit dem folgenden gcloud-Befehl eine Regel zum Zulassen von ausgehendem Traffic erstellen. Diese lässt Traffic von den TCP-Ports 12345 und 12346 von VMs mit dem Netzwerk-Tag dataflow zu anderen VMs mit demselben Tag zu:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_EGRESS \
    --network=NETWORK \
    --action=allow \
    --direction=egress \
    --target-tags=CUSTOM_TAG \
    --destination-ranges=DESTINATION-RANGES\
    --priority=PRIORITY_NUM  \
    --rules tcp:12345-12346

Dabei gilt:

• FIREWALL_RULE_NAME_EGRESS ist ein Name für die Firewallregel.

• NETWORK: der Name des Netzwerks, das die Worker-VMs verwenden

• CUSTOM_TAG ist eine durch Kommas getrennte Liste von Netzwerk-Tags.

  Die folgende Liste enthält Richtlinien zur Verwendung von Netzwerk-Tags:

  • Wenn Sie --target-tags weglassen, gilt die Regel für alle VMs im VPC-Netzwerk.

  • Wenn Sie --source-tags und alle anderen Quellspezifikationen weglassen, ist Traffic von jeder Quelle zulässig.

  • Wenn Sie keine benutzerdefinierten Netzwerk-Tags angegeben haben und die Regel für Dataflow-VMs spezifisch sein soll, verwenden Sie dataflow als Netzwerk-Tag.

  • Wenn Sie benutzerdefinierte Netzwerk-Tags angegeben haben und die Regel für Dataflow-VMs spezifisch sein soll, verwenden Sie Ihre benutzerdefinierten Netzwerk-Tags.

• DESTINATION-RANGES: eine durch Kommas getrennte Liste von CIDRs

  Fügen Sie den primären IP-Adressbereich des ausgewählten Subnetzwerks hinzu.

• PRIORITY_NUM: die Priorität der Firewallregel

  Niedrigere Zahlen haben höhere Prioritäten und 0 ist die höchste Priorität.

Für bestimmte von Dataflow verwendete TCP-Ports können Sie sich das Containermanifest des Projekts ansehen. Das Containermanifest gibt explizit die Ports an, um dem Container Hostports zuzuordnen.

SSH-Zugriff auf Worker-VMs

Dataflow erfordert kein SSH. Dieses ist jedoch für die Problembehandlung hilfreich.

Wenn Ihre Worker-VM über eine externe IP-Adresse verfügt, können Sie entweder über die Google Cloud Console oder mithilfe des Google Cloud CLI eine Verbindung zur VM herstellen. Wenn Sie eine Verbindung über SSH herstellen möchten, müssen Sie eine Firewallregel haben, die eingehende Verbindungen am TCP-Port 22 von mindestens der IP-Adresse des Systems zulässt, auf dem gcloud ausgeführt wird, oder der IP-Adresse des Systems, auf dem der Webbrowser ausgeführt wird, mit dem Sie auf die Google Cloud Console zugreifen.

Sie können sich die Netzwerkkonfiguration und -aktivität ansehen, indem Sie eine SSH-Sitzung auf einem Ihrer Worker öffnen und iproute2 ausführen. Weitere Informationen finden Sie auf der Seite zu iproute2.

Informationen zum Herstellen einer Verbindung zu einer Worker-VM, die lediglich eine interne IP-Adresse hat, finden Sie unter Verbindungsoption für ausschließlich interne VMs auswählen.