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 einer lokalen Ausführung wird Ihre Apache Beam-Pipeline als Google Cloud-Konto ausgeführt, das Sie mit der ausführbaren Datei des gcloud-Befehlszeilentools 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 Job, und während der Jobausführung zum Verwalten des Auftrags.

  • Das Worker-Dienstkonto. Worker-Instanzen verwenden das Worker-Dienstkonto, um nach dem Senden des Jobs auf Eingabe- und Ausgaberessourcen zuzugreifen.

Dataflow-Dienstkonto

Beim Ausführen der Dataflow-Pipeline verändert der Dataflow-Dienst Ressourcen für Sie (zum Beispiel Erstellen weiterer VMs). Wenn Sie die Pipeline im Dataflow-Dienst ausführen, wird das Dataflow-Dienstkonto (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com) verwendet. Das Dataflow-Dienstkonto wird erstellt, wenn die Ressource Dataflow Job zum ersten Mal genutzt wird. 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 unter dem Projekt, einschließlich des Startens von Compute Engine-Workern. Dieses 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 im gcloud-Befehlszeilentool prüfen.

Console

  1. Rufen Sie die Seite Rollen auf.

    Zur Seite "Rollen"

  2. Wählen Sie in der Symbolleiste der Cloud Console Ihr Projekt aus.

  3. Wenn Sie die Berechtigungen des Dataflow-Dienstkontos aufrufen möchten, klicken Sie oben rechts das Kästchen Von Google bereitgestellte Rollenzuweisungen an und klicken Sie dann auf das Kästchen Cloud Dataflow-Dienst-Agent.

gcloud

Sehen Sie sich die Berechtigungen des Dataflow-Dienstkontos an:

gcloud iam roles describe roles/dataflow.serviceAgent

Da Google Cloud-Dienste Lese-/Schreibzugriff auf das Projekt und seine Ressourcen voraussetzen, sollten Sie die Standardberechtigungen, die automatisch für Ihr Projekt festgelegt wurden, nicht ändern. Wenn Sie die Berechtigungen für das Dienstkonto aus den IAM-Richtlinien (Identity and Access Management) entfernen, sind die Konten weiterhin vorhanden, da sie zum Dataflow-Dienst gehören. 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.

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 Ihrer Pipeline zuzugreifen. Das Worker-Dienstkonto wird als Identität für alle Worker-VMs verwendet. 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 prüfen kann, muss es die Rollen roles/dataflow.admin und roles/dataflow.worker haben. Darüber hinaus ist die Berechtigung iam.serviceAccounts.actAs für Ihr Nutzerkonto erforderlich, um die Identität des Dienstkontos zu übernehmen.

Standard-Worker-Dienstkonto

Worker verwenden standardmäßig das Compute Engine-Standarddienstkonto Ihres Projekts als Worker-Dienstkonto. Dieses Dienstkonto (<project-number>-compute@developer.gserviceaccount.com) wird automatisch erstellt, wenn Sie die Compute Engine API für Ihr Projekt über die API-Bibliothek der Cloud Console aktivieren.

Das Compute Engine-Standarddienstkonto bietet einen umfassenden Zugriff auf die Ressourcen Ihres Projekts, was 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 und es als Worker-Dienstkonto verwenden.

Wenn Sie kein nutzerverwaltetes Dienstkonto haben, müssen Sie ein Dienstkonto erstellen und die erforderlichen IAM-Rollen dafür festlegen. Das Konto muss mindestens die Rolle "Dataflow-Worker" haben. 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.

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. Sie müssen die Rolle "Dienstkonto-Token-Ersteller" auch den folgenden von Google verwalteten Dienstkonten im nutzerverwalteten Dienstkonto zuweisen:

  • Standardmäßiges Compute Engine-Dienstkonto (<project-number>-compute@developer.gserviceaccount.com)
  • Dataflow-Dienst-Agent (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com)

Java

Verwenden Sie die Option --serviceAccount und geben Sie Ihr Dienstkonto an, wenn Sie Ihren Pipeline-Job ausführen: --serviceAccount=my-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=my-service-account-name@<project-id>.iam.gserviceaccount.com

Eine Liste der Dienstkonten Ihres Projekts erhalten Sie auf der Seite „Berechtigungen“ in der Cloud Console.

Auf Google Cloud-Ressourcen in mehreren Google Cloud-Projekten zugreifen

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

Damit die Apache Beam-Pipeline projektübergreifend 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.

Auf Cloud Storage-Buckets in Google Cloud-Projekten zugreifen

Um Ihrem Dataflow-Projekt Zugriff auf einen Cloud Storage-Bucket zu gewähren, der zu einem anderen Google Cloud-Projekt gehört, muss der Bucket für das Worker-Dienstkonto Ihres Dataflow-Projekts zugänglich sein. Sie können mit den Cloud Storage-Zugriffssteuerungen den erforderlichen Zugriff gewähren.

Auf der IAM- & Admin-Seite in der Cloud Console erhalten Sie eine Liste der Dienstkonten Ihrer Dataflow-Projekte. Wenn Ihnen die Kontonamen bekannt sind, können Sie die gsutil-Befehle ausführen, um den Dienstkonten des Projekts Eigentumsrechte (Lese-/Schreibberechtigungen) sowohl am Bucket als auch dessen Inhalten zu gewähren.

Um den Dienstkonten Ihres Dataflow-Projekts Zugriff auf einen Cloud Storage-Bucket in einem anderen Projekt zu gewähren, führen Sie den folgenden Befehl in Ihrem Shell- oder Terminal-Fenster aus: gsutil acl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Um den Dienstkonten Ihres Dataflow-Projekts Zugriff auf vorhandene Inhalte eines Cloud Storage-Buckets in einem anderen Projekt zu gewähren, führen Sie den folgenden Befehl in Ihrem Shell- oder Terminal-Fenster aus: gsutil -m acl ch -r -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Der vorherige Befehl gewährt nur Zugriff auf vorhandene Ressourcen. Wenn Sie den Dienstkonten des Dataflow-Projekts Standardberechtigungen für den Bucket erteilen, besteht mit diesen auch Zugriff auf Ressourcen, die dem Bucket später hinzugefügt werden: gsutil defacl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Auf BigQuery-Datasets in anderen Google Cloud-Projekten zugreifen

Mit der BigQueryIO API können Sie auf BigQuery-Datasets zugreifen, die zu einem anderen Google Cloud-Projekt gehören, also nicht zu dem Projekt, für das Sie Dataflow verwenden. 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 abcde@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: abcde@gmail.com und 123456789-compute@developer.gserviceaccount.com.

Auf Pub/Sub-Themen und -Abos in anderen Google Cloud-Projekten zugreifen

Sie müssen mit den Features der Identitäts- und Zugriffsverwaltung (IAM) von Pub/Sub projektübergreifende Berechtigungen einrichten, wenn Sie auf Pub/Sub-Themen oder -Abos zugreifen möchten, die zu anderen Google Cloud-Projekten gehören. Dataflow verwendet das Worker-Dienstkonto zum Ausführen Ihrer Jobs und um diesem Dienstkonto Zugriff auf die Pub/Sub-Ressourcen im anderen Projekt zu gewähren.

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

  • roles/pubsub.subscriber: zum Daten nutzen und Abos erstellen
  • roles/pubsub.viewer: zum Abfragen der Konfiguration von Themen und Abos Dataflow erfordert Zugriff auf die Bestätigungsfristen für Abos, um die Fristen entsprechend zu verlängern. Außerdem kann Dataflow mit dieser Berechtigung nach nicht unterstützten Einstellungen für Abos und Themen suchen, die Probleme verursachen können.

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

Auf Firestore in Google Cloud-Projekten zugreifen

Um auf eine Firestore-Datenbank im nativen Modus oder im Datastore-Modus zuzugreifen, die zu einem anderen Google Cloud-Projekt gehört, fügen Sie das Compute Engine-Dienstkonto (<project-number>-compute@developer.gserviceaccount.com) Ihres Dataflow-Projekts als Bearbeiter des Projekts hinzu, zu dem Firestore 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 vertrauenswürdigen 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. Dies ist ein Cloud-Projekt, das die Images für Vorlagenjobs enthält.

Datenzugriff und Sicherheit

Der Dataflow-Dienst funktioniert mit zwei Arten von Daten:

  • Endnutzerdaten. Dies sind die Daten, die von einer Dataflow-Pipeline verarbeitet werden. 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. Ein Pipelinejob kann optional Daten aus Quellen und Senken in anderen Regionen lesen und schreiben, wenn Sie diese Option im Pipelinecode angeben. 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 regionalen Endpunkten finden Sie unter Regionale Endpunkte.

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. Sie müssen sich mit dem gcloud-Befehlszeilentool authentifizieren, um Pipelines zu senden. 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. Dies bedeutet, dass der zugehörige nichtflüchtige Speicher und jegliche Zwischendaten, die darauf gespeichert wurden, gelöscht werden. Die Zwischendaten, die in Cloud Storage gespeichert sind, finden Sie in den untergeordneten Verzeichnissen des Cloud Storage-Pfads, die mit --stagingLocation und/oder --tempLocation angegeben sind. 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. Dies bedeutet, dass der zugehörige nichtflüchtige Speicher und jegliche Zwischendaten, die darauf gespeichert wurden, gelöscht werden. Die Zwischendaten, die in Cloud Storage gespeichert sind, finden Sie in den untergeordneten Verzeichnissen des Cloud Storage-Pfads, die mit --staging_location und/oder --temp_location angegeben sind. 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. Dies 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 nicht die Optionen für die Zonenpipeline 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 Cloud-Ressourcen, die Ihrer Pipeline zugrunde liegen, zur Verfügung stehen. 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.