Dataflow – Sicherheit und Berechtigungen

Sie können Dataflow-Pipelines lokal oder auf verwalteten Google Cloud-Ressourcen mit dem verwalteten Dataflow-Dienst ausführen. 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 Zugriff auf Pipelineressourcen
Datentypen, die in einem Dataflow-Dienst und zur Datensicherheit verwendet werden

Hinweise

Weitere Informationen zur Projektkennzeichnung bei Google Cloud erhalten Sie in der Google Cloud-Ü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.

Hinweis: Lokale Pipelines können Daten an lokale Ziele (z. B. lokale Dateien) oder an Cloud-Ziele (z. B. Cloud Storage oder BigQuery) ausgeben. Wenn die lokal ausgeführte Pipeline Dateien in cloudbasierte Ressourcen wie Cloud Storage schreibt, verwendet sie die Anmeldedaten Ihres Google Cloud-Kontos und das als Standardeinstellung für Google Cloud CLI konfigurierte Google Cloud-Projekt. Anweisungen zur Authentifizierung mit den Anmeldedaten für Ihr Google Cloud-Konto finden Sie in der Kurzanleitung für die von Ihnen verwendete Sprache: Java-Kurzanleitung, Python-Kurzanleitung oder Go-Kurzanleitung.

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 während der Jobausführung auch das Dataflow-Dienstkonto, 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. Als Best Practice empfehlen wir, dass Sie ein nutzerverwaltetes Dienstkonto angeben, anstatt das Standard-Worker-Dienstkonto zu verwenden.

Um die Identität des Dienstkontos zu übernehmen, muss das Konto, das die Pipeline startet, die folgende Rolle haben: iam.serviceAccounts.actAs.

Abhängig von anderen Projektberechtigungen benötigt Ihr Nutzerkonto möglicherweise auch die Rolle roles/dataflow.developer. Wenn Sie Projektinhaber oder -bearbeiter sind, haben Sie bereits die Berechtigungen, die in der Rolle roles/dataflow.developer enthalten sind.

Best Practices

Geben Sie wenn möglich für das Worker-Dienstkonto ein nutzerverwaltetes Dienstkonto an, anstatt das Standard-Worker-Dienstkonto zu verwenden.
Wenn Sie Berechtigungen für Ressourcen erteilen, weisen Sie die Rolle zu, die die mindestens erforderlichen Berechtigungen für die Aufgabe enthält. Sie können eine benutzerdefinierte Rolle erstellen, die nur die erforderlichen Berechtigungen enthält.
Verwenden Sie beim Zuweisen von Rollen für den Zugriff auf Ressourcen die niedrigste Ressourcenebene. Anstatt beispielsweise die Rolle roles/bigquery.dataEditor für ein Projekt oder einen Ordner zuzuweisen, weisen Sie die Rolle für die BigQuery-Tabelle zu.
Erstellen Sie einen Bucket mit dem Projekt als Eigentümer, der als Staging-Bucket für Dataflow verwendet werden soll. Die Standard-Bucket-Berechtigungen ermöglichen Dataflow, den Bucket zum Bereitstellen der ausführbaren Dateien der Pipeline zu verwenden.

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. Sie hat 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

Rufen Sie die Seite Rollen auf.

Zur Seite "Rollen"
Wählen Sie gegebenenfalls Ihr Projekt aus.
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

Rufen Sie die Berechtigungen des Dataflow-Dienstkontos auf:

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 der Pipeline zugeordnet sind. 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 ausführen kann, muss es die Rolle roles/dataflow.worker haben.
Damit das Worker-Dienstkonto einen Job erstellen oder prüfen kann, muss es die Rolle roles/dataflow.admin haben.

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 für die BigQuery-Tabelle haben. Beispiele für Ressourcen:

Cloud Storage-Buckets
BigQuery-Datasets
Pub/Sub-Themen und -Abos
Firestore-Datasets

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.

Sie können das Compute Engine-Standarddienstkonto als Dataflow-Worker-Dienstkonto verwenden. Wir empfehlen jedoch, ein dediziertes Dataflow-Worker-Dienstkonto zu erstellen, das nur die benötigten Rollen und Berechtigungen hat.

Abhängig von der Konfiguration Ihrer Organisationsrichtlinie kann dem Standarddienstkonto für Ihr Projekt automatisch die Rolle "Bearbeiter" zugewiesen werden. Wir empfehlen dringend, die automatische Rollenzuweisung zu deaktivieren, indem Sie die Einschränkung der Organisationsrichtlinien iam.automaticIamGrantsForDefaultServiceAccounts erzwingen. Wenn Sie Ihre Organisation nach dem 3. Mai 2024 erstellt haben, wird diese Einschränkung standardmäßig erzwungen.

Wenn Sie die automatische Rollenzuweisung deaktivieren, müssen Sie entscheiden, welche Rollen den Standarddienstkonten zugeteilt werden sollen, und diese Rollen dann selbst zuweisen.

Wenn das Standarddienstkonto bereits die Rolle "Bearbeiter" hat, sollten Sie die Rolle "Bearbeiter" durch weniger strikte Rollen ersetzen. Verwenden Sie zum sicheren Ändern der Rollen des Dienstkontos Policy Simulator, um die Auswirkungen der Änderung zu sehen, und weisen Sie die entsprechenden Rollen zu und widerrufen Sie sie.

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.

Wenn Sie noch kein nutzerverwaltetes Dienstkonto haben, erstellen Sie zuerst ein Dienstkonto.
Legen Sie die erforderlichen IAM-Rollen für Ihr Dienstkonto fest.
- Damit das Worker-Dienstkonto einen Job ausführen kann, muss es die Rolle roles/dataflow.worker haben.
- Damit das Worker-Dienstkonto einen Job erstellen oder prüfen kann, muss es die Rolle roles/dataflow.admin haben.
- Erstellen Sie alternativ eine benutzerdefinierte IAM-Rolle mit den erforderlichen Berechtigungen. Eine Liste der erforderlichen Berechtigungen finden Sie unter Rollen.
- Es 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 für die BigQuery-Tabelle 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.
Im Projekt, das das vom Nutzer verwaltete Worker-Dienstkonto enthält, das Dataflow-Dienstkonto (service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com) und den Compute Engine-Dienst Der Agent (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) muss die folgenden Rollen haben. PROJECT_NUMBER ist die ID des Projekts, in dem Ihr Dataflow-Job ausgeführt wird. Beide Konten sind Dienst-Agents.
- Rolle „Dienstkonto-Token-Ersteller“ (iam.serviceAccountTokenCreator)
- Rolle „Dienstkontonutzer“ (iam.serviceAccountUser)
Die Konten haben in dem Projekt, in dem der Dataflow-Job ausgeführt wird, standardmäßig diese Rollen. Wenn sich das nutzerverwaltete Worker-Dienstkonto und der Job in verschiedenen Projekten befinden, weisen Sie diese Rollen auch den von Google verwalteten Dienstkonten zu, die vom nutzerverwalteten Worker-Dienstkonto verwendet werden. Führen Sie zum Zuweisen dieser Rollen die Schritte im Abschnitt Einzelne Rolle gewähren auf der Seite „Zugriff auf Dienstkonten verwalten“ aus.
Wenn sich das vom Nutzer verwaltete Worker-Dienstkonto und der Job in verschiedenen Projekten befinden, achten Sie darauf, dass die boolesche Einschränkung iam.disableCrossProjectServiceAccountUsage für das Projekt, zu dem das vom Nutzer verwaltete Dienstkonto gehört, nicht erzwungen wird. Weitere Informationen finden Sie unter Ermöglichen, dass Dienstkonten projektübergreifend angehängt werden können.
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

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

Auf der Seite „Berechtigungen“ in der Google Cloud Console können Sie eine Liste der Dienstkonten abrufen, die mit Ihrem Projekt verknüpft sind.

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.

Rollen hinzufügen

So fügen Sie Ihrem Projekt Rollen hinzu:

Console

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

IAM aufrufen
Wählen Sie Ihr Projekt aus.
Klicken Sie in der Zeile mit Ihrem Nutzerkonto auf Hauptkonto bearbeiten und dann auf Weitere Rolle hinzufügen.
Wählen Sie in der Drop-down-Liste die Rolle Service Account User aus.
Klicken Sie in der Zeile mit Ihrem Worker-Dienstkonto auf Hauptkonto bearbeiten und dann auf Weitere Rolle hinzufügen.
Wählen Sie aus der Drop-down-Liste die Rolle Dataflow-Worker aus.
Wenn Ihr Worker-Dienstkonto die Rolle "Dataflow-Administrator" benötigt, wiederholen Sie den Vorgang für den Dataflow-Administrator.
Wiederholen Sie diese Schritte für alle Rollen, die für die in Ihrem Job verwendeten Ressourcen erforderlich sind, und klicken Sie dann auf Speichern.

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

gcloud-CLI

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.
Weisen Sie Ihrem Worker-Dienstkonto Rollen zu. Führen Sie den folgenden Befehl für die IAM-Rolle roles/dataflow.worker und für alle Rollen aus, die von Ressourcen in Ihrem Job benötigt werden. Wenn Ihr Worker-Dienstkonto die Rolle "Dataflow-Administrator" benötigt, wiederholen Sie den Vorgang für die IAM-Rolle roles/dataflow.admin. In diesem Beispiel wird das Compute Engine-Standarddienstkonto verwendet. Wir empfehlen jedoch, ein nutzerverwaltetes Dienstkonto zu verwenden.
```
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.

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:

Artifact Registry-Repositories
Cloud Storage-Buckets
BigQuery-Datasets
Pub/Sub-Themen und -Abos
Firestore-Datasets

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 Schlüsseln verschlüsselt, die Google gehören oder von Google verwaltet werden, oder mit vom Kunden verwaltete Verschlüsselungsschlüssel. Artifact Registry verwendet standardmäßig Google-eigene und von Google verwaltete Schlü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 ist Ihre Dataflow-Projektnummer. Ihre Projektnummer finden Sie unter Projekte identifizieren oder verwenden Sie den Befehl gcloud projects describe.
SERVICE_ACCOUNT_ROLE: Die IAM-Rolle, z. B. storage.objectViewer.

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 verwenden, entweder in demselben Projekt, 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.

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 führt dazu, 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.

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.

Empfohlene Vorgehensweise

Wir empfehlen, die Sicherheitsmechanismen zu verwenden, die in den 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.