Dataflow – Sicherheit und Berechtigungen

Dataflow-Pipelines können lokal (um Tests bei kleinen Datasets auszuführen) oder auf verwalteten Google Cloud-Ressourcen ausgeführt werden, die den verwalteten Dataflow-Dienst verwenden. Ob lokal oder in der Cloud, Ihre Pipeline und deren Worker verwenden ein Berechtigungssystem, um sicheren Zugriff auf Pipelinedateien und -ressourcen zu erhalten. Dataflow-Berechtigungen werden entsprechend der Rolle zugewiesen, die für den Zugriff auf Pipelineressourcen verwendet wird. In diesem Dokument werden die folgenden Konzepte erläutert:

  • Dataflow-VMs aktualisieren
  • Rollen und Berechtigungen, die zum Ausführen von lokalen und Google Cloud-Pipelines erforderlich sind
  • Erforderliche Rollen und Berechtigungen für den projektübergreifenden Zugriff auf Pipelineressourcen
  • Datentypen, die in einem Dataflow-Dienst und zur Datensicherheit verwendet werden

Hinweis

Weitere Informationen zur Projektkennzeichnung bei Google Cloud erhalten Sie in der Plattformübersicht. Die Kennzeichnung umfasst den Projektnamen, die Projekt-ID und die Projektnummer.

Dataflow-VMs aktualisieren und patchen

Dataflow nutzt Container-Optimized OS. Somit gelten die Sicherheitsprozesse von Container-Optimized OS auch für Dataflow.

Batchpipelines sind zeitgebunden und erfordern keine Wartung. Beim Start einer neuen Batchpipeline wird das neueste Dataflow-Image verwendet.

Wenn für Streamingpipelines ein Sicherheitspatch sofort erforderlich ist, werden Sie von Google Cloud mithilfe von Sicherheitsbulletins benachrichtigt. Für Streamingpipelines empfehlen wir die Verwendung der Option --update, um Ihren Job mit dem neuesten Dataflow-Image neu zu starten.

Dataflow-Container-Images sind in der Google Cloud Console verfügbar.

Sicherheit und Berechtigungen für lokale Pipelines

Bei lokaler Ausführung wird Ihre Apache Beam-Pipeline als das Google Cloud-Konto ausgeführt, das Sie mit der ausführbaren Datei von Google Cloud CLI konfiguriert haben. Führen Sie deshalb Apache Beam SDK-Vorgänge lokal aus. Ihr Google Cloud-Konto muss Zugriff auf die gleichen Dateien und Ressourcen haben.

Zum Auflisten des als Standard ausgewählten Google Cloud-Kontos führen Sie den Befehl gcloud config list aus.

Sicherheit und Berechtigungen für Pipelines in Google Cloud

Wenn Sie die Pipeline ausführen, verwendet Dataflow zwei Dienstkonten zum Verwalten von Sicherheit und Berechtigungen:

  • Das Dataflow-Dienstkonto. Der Dataflow-Dienst verwendet das Dataflow-Dienstkonto als Teil der Auftragserstellungsanforderung, z. B. zum Prüfen des Projektkontingents und zum Erstellen von Worker-Instanzen in Ihrem Namen. Dataflow verwendet das Dataflow-Dienstkonto auch während der Jobausführung, um den Job zu verwalten. Dieses Konto wird auch als Dataflow-Dienst-Agent bezeichnet.

  • Das Worker-Dienstkonto. Worker-Instanzen verwenden das Worker-Dienstkonto, um nach dem Senden des Jobs auf Eingabe- und Ausgaberessourcen zuzugreifen. Worker verwendet standardmäßig das Compute Engine-Standarddienstkonto, das mit Ihrem Projekt verknüpft ist, als Worker-Dienstkonto. Damit das Worker-Dienstkonto einen Job erstellen, ausführen und untersuchen kann, muss er die folgenden Rollen haben:

    • roles/dataflow.admin
    • roles/dataflow.worker

Wenn Ihre Apache Beam-Pipelines auf Google Cloud-Ressourcen zugreifen, müssen Sie dem Worker-Dienstkonto Ihres Dataflow-Projekts außerdem die erforderlichen Rollen zuweisen. Das Worker-Dienstkonto muss auf die Ressourcen zugreifen können, während der Dataflow-Job ausgeführt wird. Wenn Ihr Job beispielsweise in BigQuery schreibt, muss Ihr Dienstkonto mindestens die Rolle roles/bigquery.dataEditor haben. Beispiele für Ressourcen:

Um die Identität des Dienstkontos zu übernehmen, muss Ihr Nutzerkonto die folgende Rolle haben: iam.serviceAccounts.actAs. Abhängig von anderen Projektberechtigungen benötigt Ihr Nutzerkonto möglicherweise auch die Rolle roles/dataflow.developer.

So fügen Sie Ihrem Projekt die erforderlichen Rollen hinzu:

Console

  1. Öffnen Sie in der Google Cloud Console die Seite IAM.

    IAM aufrufen

  2. Wählen Sie Ihr Projekt aus.

  3. Klicken Sie in der Zeile mit Ihrem Nutzerkonto auf Hauptkonto bearbeiten und dann auf Weitere Rolle hinzufügen.

  4. Wählen Sie in der Drop-down-Liste die Rolle Dienstkontonutzer aus.

  5. Klicken Sie in der Zeile mit dem Compute Engine-Standarddienstkonto auf Hauptkonto bearbeiten und dann auf Weitere Rolle hinzufügen.

  6. Wählen Sie aus der Drop-down-Liste die Rolle Dataflow-Worker aus.

  7. Wiederholen Sie diese Schritte für den Dataflow-Administrator und alle Rollen, die von den in Ihrem Job verwendeten Ressourcen benötigt werden. Klicken Sie dann auf Speichern.

    Weitere Informationen zum Zuweisen von Rollen finden Sie unter IAM-Rolle über die Console zuweisen.

gcloud-CLI

  1. Weisen Sie Ihrem Nutzerkonto die Rolle roles/iam.serviceAccountUser zu. Führen Sie dazu diesen Befehl aus:

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS --role=roles/iam.serviceAccountUser
    • Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.
    • Ersetzen Sie EMAIL_ADDRESS durch die E-Mail-Adresse des Dienstkontos.

  2. Weisen Sie Ihrem Compute Engine-Standarddienstkonto Rollen zu. Führen Sie den folgenden Befehl für jede der folgenden IAM-Rollen einmal aus: roles/dataflow.admin, roles/dataflow.worker und alle Rollen, die für die im Job verwendeten Ressourcen erforderlich sind.

    gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLE
    • Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.
    • Ersetzen Sie PROJECT_NUMBER durch die Projekt-ID. Ihre Projektnummer finden Sie unter Projekte identifizieren oder verwenden Sie den Befehl gcloud projects describe.
    • Ersetzen Sie SERVICE_ACCOUNT_ROLE durch jede einzelne Rolle.

Dataflow-Dienstkonto

Alle Projekte, die die Ressource Dataflow Job verwendet haben, haben ein Dataflow-Dienstkonto, das auch als Dataflow-Dienst-Agent bezeichnet wird und die folgende E-Mail-Adresse hat:

service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com

Dieses Dienstkonto wird von Google erstellt und verwaltet und Ihrem Projekt automatisch zugewiesen, wenn die Ressource Dataflow Job zum ersten Mal verwendet wird.

Als Teil der Ausführung der Dataflow-Pipeline verändert der Dataflow-Dienst Ressourcen für Sie. Dadurch werden beispielsweise zusätzliche VMs erstellt. Wenn Sie Ihre Pipeline mit dem Dataflow-Dienst ausführen, verwendet der Dienst dieses Dienstkonto.

Diesem Konto wird die Rolle „Dataflow-Dienst-Agent“ für das Projekt zugewiesen. Es verfügt über die erforderlichen Berechtigungen zum Ausführen eines Dataflow-Jobs im Projekt, einschließlich des Startens von Compute Engine-Workern. Das Konto wird ausschließlich vom Dataflow-Dienst und speziell für Ihr Projekt verwendet.

Sie können die Berechtigungen des Dataflow-Dienstkontos in der Cloud Console oder der Google Cloud-Befehlszeile prüfen.

Console

  1. Rufen Sie die Seite Rollen auf.

    Zur Seite "Rollen"

  2. Wählen Sie gegebenenfalls Ihr Projekt aus.

  3. Klicken Sie in der Liste auf den Titel Cloud Dataflow Service Agent. Es wird eine Seite mit den Berechtigungen geöffnet, die dem Dataflow-Dienstkonto zugewiesen sind.

gcloud-CLI

Sehen Sie sich die Berechtigungen des Dataflow-Dienstkontos an:

gcloud iam roles describe roles/dataflow.serviceAgent

Da Google Cloud-Dienste Lese- und Schreibzugriff auf das Projekt und seine Ressourcen voraussetzen, sollten Sie die Standardberechtigungen, die automatisch für Ihr Projekt festgelegt wurden, nicht ändern. Wenn für ein Dataflow-Dienstkonto die Berechtigungen für ein Projekt entfernt werden, kann Dataflow keine VMs starten und keine anderen Verwaltungsaufgaben ausführen.

Wenn Sie die Berechtigungen für das Dienstkonto aus den IAM-Richtlinien (Identity and Access Management) entfernen, bleibt das Konto vorhanden, da es zum Dataflow-Dienst gehört.

Worker-Dienstkonto

Compute Engine-Instanzen setzen die Ausführung der Apache Beam SDK-Vorgänge in der Cloud um. Diese Worker verwenden das Worker-Dienstkonto Ihres Projekts, um auf die Dateien und andere Ressourcen zuzugreifen, die mit der Pipeline verknüpft sind. Das Worker-Dienstkonto wird als Identität für alle Worker-VMs verwendet und alle Anfragen, die von der VM stammen, verwenden das Worker-Dienstkonto. Dieses Dienstkonto wird auch für die Interaktion mit Ressourcen wie Cloud Storage-Buckets und Pub/Sub-Themen verwendet.

Damit das Worker-Dienstkonto einen Job erstellen, ausführen und untersuchen kann, muss er die folgenden Rollen haben:

  • roles/dataflow.admin
  • roles/dataflow.worker

Standard-Worker-Dienstkonto

Worker verwenden standardmäßig das Compute Engine-Standarddienstkonto Ihres Projekts als Worker-Dienstkonto. Dieses Dienstkonto hat die folgende E-Mail-Adresse:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dieses Dienstkonto wird automatisch erstellt, wenn Sie die Compute Engine API für Ihr Projekt über die API-Bibliothek in der Google Cloud Console aktivieren.

Das Compute Engine-Standarddienstkonto bietet einen umfassenden Zugriff auf die Ressourcen Ihres Projekts, was Ihnen den Einstieg in Dataflow erleichtert. Für Produktionsarbeitslasten empfehlen wir jedoch, dass Sie ein neues Dienstkonto erstellen, das nur die benötigten Rollen und Berechtigungen enthält.

Vom Nutzer verwaltetes Worker-Dienstkonto angeben

Wenn Sie Ressourcen mit einer detaillierten Zugriffssteuerung erstellen und verwenden möchten, können Sie ein nutzerverwaltetes Dienstkonto erstellen. Verwenden Sie dieses Konto als Worker-Dienstkonto.

  1. Wenn Sie noch kein nutzerverwaltetes Dienstkonto haben, erstellen Sie zuerst ein Dienstkonto.

  2. Legen Sie die erforderlichen IAM-Rollen für Ihr Dienstkonto fest.

    • Damit das Dienstkonto einen Job erstellen, ausführen und prüfen kann, muss es die Rollen roles/dataflow.admin und roles/dataflow.worker oder eine benutzerdefinierte IAM-Rolle mit den erforderlichen Berechtigungen für diese Rollen haben. Eine Liste der erforderlichen Berechtigungen finden Sie unter Rollen.
    • Außerdem werden möglicherweise zusätzliche Rollen benötigt, damit für Ihren Job erforderliche Google Cloud-Ressourcen wie BigQuery, Pub/Sub oder Schreibvorgänge in Cloud Storage verwendet werden können. Wenn Ihr Job beispielsweise Daten aus BigQuery liest, muss Ihr Dienstkonto mindestens die Rolle roles/bigquery.dataViewer haben.
    • Achten Sie außerdem darauf, dass Ihr nutzerverwaltetes Dienstkonto Lese- und Schreibzugriff auf den im Dataflow-Job angegebenen Staging-Speicherort und den temporären Speicherort hat.
    • Um die Identität des Dienstkontos zu übernehmen, muss Ihr Nutzerkonto die Berechtigung iam.serviceAccounts.actAs haben.

  3. Weisen Sie dem Dataflow-Dienstkonto (service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com) und dem Compute Engine-Dienst-Agent (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) die folgenden Rollen zu. Beide Konten sind von Google verwaltete Dienstkonten im nutzerverwalteten Dienstkonto. Diese Konten befinden sich im selben Projekt wie das vom Nutzer verwaltete Dienstkonto, auch wenn der Dataflow-Job in einem anderen Projekt ausgeführt wird.

    Eine Anleitung zum Zuweisen von Rollen für Dienstkonten finden Sie im Abschnitt Einzelne Rolle gewähren auf der Seite „Zugriff auf Dienstkonten verwalten“.

  4. Geben Sie beim Ausführen Ihres Pipelinejobs Ihr Dienstkonto an.

    Java

    Verwenden Sie die Option --serviceAccount und geben Sie Ihr Dienstkonto an, wenn Sie den Pipeline-Job über die Befehlszeile ausführen: --serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Verwenden Sie die Option --service-account-email und geben Sie Ihr Dienstkonto an, wenn Sie den Pipeline-Job als Flex-Vorlage ausführen: --service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Python

    Verwenden Sie die Option --service_account_email und geben Sie Ihr Dienstkonto an, wenn Sie Ihren Pipeline-Job ausführen: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Einfach loslegen (Go)

    Verwenden Sie die Option --service_account_email und geben Sie Ihr Dienstkonto an, wenn Sie Ihren Pipeline-Job ausführen: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

Eine Liste der mit Ihrem Projekt verknüpften Dienstkonten können Sie auf der Seite "Berechtigungen" in der Google Cloud Console abrufen.

Das vom Nutzer verwaltete Dienstkonto kann sich in demselben Projekt wie Ihr Job oder in einem anderen Projekt befinden. Wenn sich das Dienstkonto und der Job in verschiedenen Projekten befinden, müssen Sie das Dienstkonto konfigurieren, bevor Sie den Job ausführen.

Auf Google Cloud-Ressourcen zugreifen

Ihre Apache Beam-Pipelines können entweder im selben Google Cloud-Projekt oder in anderen Projekten auf Google Cloud-Ressourcen zugreifen. Zu diesen Ressourcen gehören:

Damit die Apache Beam-Pipeline auf diese Ressourcen zugreifen kann, müssen Sie die entsprechenden Zugriffssteuerungsmechanismen der Ressourcen verwenden, um explizit Zugriff auf das Worker-Dienstkonto Ihres Dataflow-Projekts zu gewähren.

Wenn Sie Assured Workloads-Features mit Dataflow verwenden, z. B. EU-Regionen und -Support mit Datenhoheitskontrollen, alle Cloud Storage-, BigQuery-, Pub/Sub-, E/A-Connectors und andere Ressourcen, auf die Ihre Pipeline zugreift, müssen sich im Assured Workloads-Projekt oder -Ordner Ihrer Organisation befinden.

Wenn Sie ein vom Nutzer verwaltetes Worker-Dienstkonto verwenden oder auf Ressourcen in anderen Projekten zugreifen, sind möglicherweise zusätzliche Maßnahmen erforderlich. In den folgenden Beispielen wird davon ausgegangen, dass das Compute Engine-Standarddienstkonto verwendet wird. Sie können aber auch ein vom Nutzer verwaltetes Worker-Dienstkonto verwenden.

Auf Artifact Registry-Repositories zugreifen

Wenn Sie benutzerdefinierte Container mit Dataflow verwenden, können Sie Artefakte in ein Artifact Registry-Repository hochladen.

Wenn Sie Artifact Registry mit Dataflow verwenden möchten, benötigen Sie mindestens Artifact Registry Writer-Zugriff (role/artifactregistry.writer) auf das Worker-Dienstkonto, das den Dataflow-Job ausführt.

Alle Repository-Inhalte werden entweder mit von Google verwalteten oder mit vom Kunden verwalteten Verschlüsselungsschlüsseln verschlüsselt. Artifact Registry verwendet standardmäßig von Google verwaltete Verschlüsselungsschlüssel. Dafür ist keine Konfiguration erforderlich.

Auf Cloud Storage-Buckets zugreifen

Damit Ihr Dataflow-Projekt Zugriff auf einen Cloud Storage-Bucket erhält, müssen Sie den Bucket für das Worker-Dienstkonto Ihres Dataflow-Projekts zugänglich machen. Das Dienstkonto benötigt mindestens Lese- und Schreibberechtigungen für den Bucket und dessen Inhalt. Sie können IAM-Berechtigungen für Cloud Storage verwenden, um den erforderlichen Zugriff zu gewähren.

Verwenden Sie den Befehl gcloud storage buckets add-iam-policy-binding, um Ihrem Worker-Dienstkonto die erforderlichen Berechtigungen zum Lesen von und Schreiben in einen Bucket zu erteilen. Mit diesem Befehl wird das Dataflow-Projektdienstkonto einer Richtlinie auf Bucket-Ebene hinzugefügt.

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLE

Ersetzen Sie Folgendes:

  • BUCKET_NAME: der Name Ihres Cloud Storage-Buckets
  • PROJECT_NUMBER: Ihre Dataflow-Projektnummer. Ihre Projektnummer finden Sie unter Projekte identifizieren oder verwenden Sie den Befehl gcloud projects describe.
  • SERVICE_ACCOUNT_ROLE die IAM-Rolle.

Wenn Ihr Dienstkonto vollständige Kontrolle über Speicherobjekte haben muss, einschließlich Auflisten, Erstellen, Aufrufen und Löschen von Objekten und verwalteten Ordnern, weisen Sie Ihrem Dienstkonto die Rolle des Storage-Objekt-Administrators (roles/storage.objectAdmin) zu.

Verwenden Sie den Befehl gcloud storage buckets list, um eine Liste der Cloud Storage-Buckets in einem Google Cloud-Projekt abzurufen:

gcloud storage buckets list --project= PROJECT_ID

Ersetzen Sie PROJECT_ID durch die ID des Projekts.

Sofern Sie nicht durch Organisationsrichtlinien eingeschränkt werden, die die Ressourcenfreigabe einschränken, können Sie auf einen Bucket zugreifen, der sich in einem anderen Projekt als Ihrer Dataflow-Pipeline befindet. Weitere Informationen zu Domaineinschränkungen finden Sie unter Identitäten nach Domain einschränken.

Wenn Sie keinen Bucket haben, erstellen Sie einen neuen Bucket. Erteilen Sie dann dem Worker-Dienstkonto die erforderlichen Berechtigungen zum Lesen von und Schreiben in den Bucket.

Tipp: Sie können Bucket-Berechtigungen auch über die Google Cloud Console festlegen. Weitere Informationen finden Sie unter Erforderliche Berechtigungen festlegen.

Cloud Storage bietet Ihnen zwei Systeme, um Nutzern die Berechtigung zum Zugriff auf Ihre Buckets und Objekte zu erteilen: IAM und Access Control Lists (ACLs). In den meisten Fällen ist IAM die empfohlene Methode zum Steuern des Zugriffs auf Ihre Ressourcen.

  • IAM steuert die Berechtigungen überall in Google Cloud und ermöglicht Ihnen, Berechtigungen auf Bucket- und Projektebene zu erteilen. Eine Liste der IAM-Rollen, die mit Cloud Storage verknüpft sind, sowie die in den einzelnen Rollen enthaltenen Berechtigungen finden Sie unter IAM-Rollen für Cloud Storage. Wenn Sie mehr Kontrolle über Berechtigungen benötigen, erstellen Sie eine benutzerdefinierte Rolle.

  • Wenn Sie den Zugriff über ACLs steuern, müssen Sie darauf achten, dass die Berechtigungen des Worker-Dienstkontos mit Ihren IAM-Einstellungen übereinstimmen. Bei Inkonsistenzen zwischen IAM- und ACL-Richtlinien ist der Cloud Storage-Bucket möglicherweise für Ihre Dataflow-Jobs nicht mehr zugänglich, wenn der Cloud Storage-Bucket von detaillierten Zugriffsberechtigungen zu einem einheitlichen Zugriff auf Bucket-Ebene migriert. Weitere Informationen finden Sie unter Hinweise zu gängigen Fehlern.

Auf BigQuery-Datasets zugreifen

Sie können die BigQueryIO API für den Zugriff auf BigQuery-Datasets in demselben Projekt verwenden, in dem Sie Dataflow verwenden, oder in einem anderen Projekt. Damit BigQuery-Quelle und -Senke ordnungsgemäß funktionieren, müssen die folgenden drei Konten Zugriff auf alle BigQuery-Datasets haben, aus denen Ihr Dataflow-Job liest oder auf die er schreibt:

  • Das Google Cloud-Konto, das Sie zum Ausführen des Dataflow-Jobs verwenden
  • Das Worker-Dienstkonto, das den Dataflow-Job ausführt

Möglicherweise müssen Sie BigQuery konfigurieren, um den Zugriff auf diese Konten explizit zu gewähren. Unter BigQuery-Zugriffssteuerung finden Sie weitere Informationen zum Gewähren des Zugriffs auf BigQuery-Datasets über die BigQuery-Seite oder mit der BigQuery-API.

Unter den erforderlichen BigQuery-Berechtigungen benötigt die Pipeline die IAM-Berechtigung bigquery.datasets.get für den Zugriff auf ein BigQuery-Dataset. In der Regel enthalten die meisten BigQuery-IAM-Rollen die Berechtigung bigquery.datasets.get, aber die Rolle roles/bigquery.jobUser ist eine Ausnahme.

Wenn Ihr Google Cloud-Konto beispielsweise cloudysanfrancisco@gmail.com heißt und die Projektnummer des Projekts, in dem der Dataflow-Job ausgeführt wird, 123456789 lautet, muss allen folgenden Konten der Zugriff auf die verwendeten BigQuery-Datasets gewährt werden: cloudysanfrancisco@gmail.com und 123456789-compute@developer.gserviceaccount.com.

Auf Pub/Sub-Themen und -Abos zugreifen

Für den Zugriff auf ein Pub/Sub-Thema oder -Abo verwenden Sie die Features zur Identitäts- und Zugriffsverwaltung und richten Sie darüber Berechtigungen für das Worker-Dienstkonto ein.

Es sind Berechtigungen der folgenden Pub/Sub-Rollen erforderlich:

  • roles/pubsub.subscriber ist erforderlich, um Daten zu verarbeiten.
  • roles/pubsub.editor ist erforderlich, um ein Pub/Sub-Abo zu erstellen.
  • roles/pubsub.viewer ist empfohlen, damit Dataflow die Konfigurationen von Themen und Abos abfragen kann. Diese Konfiguration hat zwei Vorteile:
    • Dataflow kann für Abos nicht unterstützte Einstellungen suchen, die möglicherweise nicht wie erwartet funktionieren.
    • Wenn das Abo nicht die standardmäßige Bestätigungsfrist von 10 Sekunden verwendet, verbessert sich die Leistung. Dataflow verlängert wiederholt die Bestätigungsfrist für eine Nachricht, während sie von der Pipeline verarbeitet wird. Ohne pubsub.viewer-Berechtigungen kann Dataflow die Bestätigungsfrist nicht abfragen und muss daher eine Standardfrist annehmen. Diese Konfiguration bewirkt, dass Dataflow mehr modifyAckDeadline-Anfragen als notwendig ausgibt.
    • Wenn VPC Service Controls für das Projekt aktiviert ist, zu dem das Abo oder Thema gehört, erlauben IP-Adressen-basierte Regeln für eingehenden Traffic Dataflow nicht, die Konfigurationen abzufragen. In diesem Fall ist eine Regel für eingehenden Traffic erforderlich, die auf dem Worker-Dienstkonto basiert.

Weitere Informationen und einige Codebeispiele, die zeigen, wie die Features der Identitäts- und Zugriffsverwaltung von Pub/Sub verwendet werden, finden Sie unter Beispielanwendungsfall: Projektübergreifende Kommunikation.

Auf Firestore zugreifen

Für den Zugriff auf eine Firestore-Datenbank (im nativen Modus oder im Datastore-Modus) fügen Sie Ihr Dataflow-Worker-Dienstkonto (z. B. PROJECT_NUMBER-compute@developer.gserviceaccount.com) als Bearbeiter des Projekts hinzu, zu dem die Datenbank gehört, oder verwenden Sie eine restriktivere Datastore-Rolle wie roles/datastore.viewer. Aktivieren Sie außerdem die Firestore API in beiden Projekten über die API-Bibliothek in der Google Cloud Console.

Auf Images für Projekte mit einer Trusted Image-Richtlinie zugreifen

Wenn für Ihr Projekt eine Trusted Image-Richtlinie eingerichtet ist und sich das Boot-Image in einem anderen Projekt befindet, muss die vertrauenswürdige Image-Richtlinie für den Zugriff auf das Image konfiguriert sein. Wenn Sie beispielsweise einen Dataflow-Job mit Vorlage ausführen, muss die Richtliniendatei Zugriff auf das Projekt dataflow-service-producer-prod enthalten. Dieses Google Cloud-Projekt enthält die Images für Vorlagenjobs.

Datenzugriff und Sicherheit

Der Dataflow-Dienst funktioniert mit zwei Arten von Daten:

  • Endnutzerdaten. Diese Daten werden von einer Dataflow-Pipeline verarbeitet. Eine typische Pipeline liest Daten aus einer oder mehreren Quellen, implementiert Transformationen der Daten und schreibt die Ergebnisse in eine oder mehrere Senken. Alle Quellen und Senken sind Speicherdienste, die nicht direkt von Dataflow verwaltet werden.

  • Betriebsdaten. Diese Daten enthalten alle Metadaten, die für die Verwaltung einer Dataflow-Pipeline erforderlich sind. Diese Daten enthalten sowohl vom Nutzer bereitgestellte Metadaten wie einen Jobnamen oder Pipelineoptionen als auch vom System generierte Metadaten wie eine Job-ID.

Der Dataflow-Dienst verwendet verschiedene Sicherheitsmechanismen, um Ihre Daten sicher und vertraulich aufzubewahren. Diese Mechanismen gelten für folgende Szenarien:

  • Pipeline an den Dienst senden
  • Pipeline auswerten
  • Zugriff auf Telemetrie und Messwerte während und nach Ausführung einer Pipeline anfordern
  • Dataflow-Dienst wie Shuffle oder Streaming Engine verwenden

Datenlokalität

Die gesamte Kerndatenverarbeitung für den Dataflow-Dienst erfolgt in der Region, die im Pipelinecode angegeben ist. Wenn keine Region angegeben ist, wird die Standardregion us-central1 verwendet. Wenn Sie diese Option im Pipelinecode angeben, kann der Pipelinejob optional aus Quellen und Senken in anderen Regionen lesen und schreiben. Die eigentliche Datenverarbeitung findet jedoch nur in der Region statt, in der die Dataflow-VMs ausgeführt werden sollen.

Die Pipelinelogik wird auf einzelnen Worker-VM-Instanzen ausgewertet. Sie können die Zone festlegen, in der sich diese Instanzen und das private Netzwerk, über das sie kommunizieren, befinden. Untergeordnete Berechnungen für die Plattform hängen von Metadaten wie Cloud Storage-Speicherorten oder Dateigrößen ab.

Dataflow ist ein regionaler Dienst. Weitere Informationen zu Datenlokalität und Regionen finden Sie unter Dataflow-Regionen.

Daten in einer Pipelineübermittlung

Die IAM-Berechtigungen für Ihr Google Cloud-Projekt steuern den Zugriff auf den Dataflow-Dienst. Alle Hauptkonten, die Bearbeiter- oder Inhaberrechte für Ihr Projekt erhalten, können Pipelines an den Dienst übergeben. Zum Senden von Pipelines müssen Sie sich über die Google Cloud-Befehlszeile authentifizieren. Nach der Authentifizierung werden Ihre Pipelines über das HTTPS-Protokoll gesendet. Anleitungen zur Authentifizierung mit den Anmeldedaten für Ihr Google Cloud-Konto finden Sie in der Kurzanleitung für Ihre Sprache.

Daten in einer Pipelineauswertung

Als Teil der Auswertung einer Pipeline werden möglicherweise temporäre Daten generiert und lokal in den Worker-VM-Instanzen oder in Cloud Storage gespeichert. Temporäre Daten werden im inaktiven Zustand verschlüsselt und bleiben nach Abschluss einer Pipelineauswertung nicht erhalten. Solche Daten können auch in der in der Dataflow-Pipeline angegebenen Region im Shuffle-Dienst oder im Streaming Engine-Dienst gespeichert werden, sofern Sie sich für den Dienst angemeldet haben.

Java

Compute Engine-VMs werden standardmäßig gelöscht, wenn der Dataflow-Job abgeschlossen ist. Dies geschieht unabhängig davon, ob der Job erfolgreich ist oder nicht. Folglich werden die zugehörige Persistent Disk und jegliche Zwischendaten, die darauf gespeichert wurden, gelöscht. Die im Cloud Storage gespeicherten Zwischendaten befinden sich in Unterverzeichnissen des Cloud Storage-Pfads, den Sie als --stagingLocation oder --tempLocation angeben. Wenn Sie eine Ausgabe in eine Cloud Storage-Datei schreiben, können am Ausgabeort temporäre Dateien erstellt werden, bevor der Schreibvorgang abgeschlossen ist.

Python

Compute Engine-VMs werden standardmäßig gelöscht, wenn der Dataflow-Job abgeschlossen ist. Dies geschieht unabhängig davon, ob der Job erfolgreich ist oder nicht. Folglich werden die zugehörige Persistent Disk und jegliche Zwischendaten, die darauf gespeichert wurden, gelöscht. Die im Cloud Storage gespeicherten Zwischendaten befinden sich in Unterverzeichnissen des Cloud Storage-Pfads, den Sie als --staging_location oder --temp_location angeben. Wenn Sie eine Ausgabe in eine Cloud Storage-Datei schreiben, können am Ausgabeort temporäre Dateien erstellt werden, bevor der Schreibvorgang abgeschlossen ist.

Einfach loslegen (Go)

Compute Engine-VMs werden standardmäßig gelöscht, wenn der Dataflow-Job abgeschlossen ist. Dies geschieht unabhängig davon, ob der Job erfolgreich ist oder nicht. Folglich werden die zugehörige Persistent Disk und jegliche Zwischendaten, die darauf gespeichert wurden, gelöscht. Die im Cloud Storage gespeicherten Zwischendaten befinden sich in Unterverzeichnissen des Cloud Storage-Pfads, den Sie als --staging_location oder --temp_location angeben. Wenn Sie eine Ausgabe in eine Cloud Storage-Datei schreiben, können am Ausgabeort temporäre Dateien erstellt werden, bevor der Schreibvorgang abgeschlossen ist.

Daten in Pipelinelogs und Telemetrie

In Cloud Logging gespeicherte Informationen werden in erster Linie durch den Code in Ihrem Dataflow-Programm erzeugt. Der Dataflow-Dienst kann in Cloud Logging auch Warn- und Fehlerdaten erzeugen. Diese Daten sind jedoch die einzigen Zwischendaten, die der Dienst zu den Logs hinzufügt. Cloud Logging ist ein globaler Dienst.

Telemetriedaten und die zugehörigen Messwerte werden im inaktiven Zustand verschlüsselt. Der Zugriff auf diese Daten wird über die Leseberechtigungen des Google Cloud-Projekts gesteuert.

Daten in Dataflow-Diensten

Wenn Sie Dataflow Shuffle oder Dataflow Streaming für Ihre Pipeline verwenden, geben Sie die Optionen für die Zonenpipeline nicht an. Geben Sie stattdessen die Region an und legen Sie den Wert auf eine der Regionen fest, in denen Shuffle oder Streaming aktuell verfügbar ist. Dataflow wählt automatisch die Zone in der von Ihnen angegebenen Region aus. Die Endnutzerdaten bei der Übertragung verbleiben in den Worker-VMs und in derselben Zone. Diese Dataflow-Jobs können aber weiterhin in Quellen und Senken lesen und schreiben, die sich außerhalb der VM-Zone befinden. Die Daten bei der Übertragung können auch an den Dataflow Shuffle- oder Dataflow Streaming-Dienst gesendet werden. Sie bleiben jedoch immer in der im Pipelinecode angegebenen Region.

Wir empfehlen, die Sicherheitsmechanismen zu nutzen, die für die zugrunde liegenden Cloud-Ressourcen Ihrer Pipeline verfügbar sind. Diese Mechanismen umfassen die Datensicherheitsfunktionen von Datenquellen und -senken wie BigQuery und Cloud Storage. Außerdem sollten Sie nicht unterschiedliche Vertraulichkeitsstufen in einem einzigen Projekt kombinieren.