Anwendungsfall: Zugriffssteuerung für einen Dataproc-Cluster in einem anderen Projekt

Auf dieser Seite wird beschrieben, wie Sie die Zugriffssteuerung verwalten, wenn Sie eine Pipeline bereitstellen und ausführen, die Dataproc-Cluster in einem anderen Google Cloud-Projekt verwendet.

Szenario

Wenn eine Cloud Data Fusion-Instanz in einem Google Cloud-Projekt gestartet wird, werden standardmäßig Pipelines mit Dataproc-Clustern im selben Projekt bereitgestellt und ausgeführt. In Ihrer Organisation müssen Sie möglicherweise Cluster in einem anderen Projekt verwenden. Für diesen Anwendungsfall müssen Sie den Zugriff zwischen den Projekten verwalten. Auf der folgenden Seite wird beschrieben, wie Sie die Basiskonfigurationen (Standardkonfigurationen) ändern und die entsprechenden Zugriffssteuerungen anwenden können.

Hinweise

Um die Lösungen in diesem Anwendungsfall zu verstehen, benötigen Sie den folgenden Kontext:

Annahmen und Umfang

Dieser Anwendungsfall hat folgende Anforderungen:

  • Eine private Cloud Data Fusion-Instanz. Aus Sicherheitsgründen kann ein Unternehmen verlangen, dass Sie diese Art von Instanz verwenden.
  • Eine BigQuery-Quelle und -Senke.
  • Zugriffssteuerung mit IAM, nicht rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC).

Lösung

Diese Lösung vergleicht Architektur und Konfiguration, die eine grundlegende und anwendungsfallspezifische Architektur haben.

Architektur

In den folgenden Diagrammen wird die Projektarchitektur zum Erstellen einer Cloud Data Fusion-Instanz und zum Ausführen von Pipelines verglichen, wenn Sie Cluster im selben Projekt (Baseline) und in einem anderen Projekt über die VPC des Mandantenprojekts verwenden.

Referenzarchitektur

Dieses Diagramm zeigt die grundlegende Architektur der Projekte:

Mandanten-, Kunden- und Dataproc-Projektarchitektur in Cloud Data Fusion

Für die Referenzkonfiguration erstellen Sie eine private Cloud Data Fusion-Instanz und führen eine Pipeline ohne zusätzliche Anpassungen aus:

  • Sie verwenden eines der integrierten Compute-Profile.
  • Quelle und Senke befinden sich im selben Projekt wie die Instanz
  • Keinem der Dienstkonten wurden zusätzliche Rollen gewährt

Weitere Informationen zu Mandanten- und Kundenprojekten finden Sie unter Netzwerk.

Architektur des Anwendungsfalls

Dieses Diagramm zeigt die Projektarchitektur, wenn Sie Cluster in einem anderen Projekt verwenden:

Mandanten-, Kunden- und Dataproc-Projektarchitektur in Cloud Data Fusion

Konfigurationen

In den folgenden Abschnitten werden die Basiskonfigurationen mit den anwendungsfallspezifischen Konfigurationen für die Verwendung von Dataproc-Clustern in einem anderen Projekt über die standardmäßige VPC des Mandantenprojekts verglichen.

In den folgenden Beschreibungen der Anwendungsfälle wird die Cloud Data Fusion-Instanz im Kundenprojekt und im Dataproc-Projekt der Dataproc-Cluster gestartet.

VPC und Instanz des Mandantenprojekts

Referenz Anwendungsfall
Im obigen Referenzarchitekturdiagramm enthält das Mandantenprojekt die folgenden Komponenten:
  • Die Standard-VPC, die automatisch erstellt wird.
  • Die physische Bereitstellung der Cloud Data Fusion-Instanz.
 Für diesen Anwendungsfall ist keine zusätzliche Konfiguration erforderlich.

Kundenprojekt

Referenz Anwendungsfall
In Ihrem Google Cloud-Projekt stellen Sie Pipelines bereit und führen sie aus. Standardmäßig werden die Dataproc-Cluster in diesem Projekt gestartet, wenn Sie Ihre Pipelines ausführen. In diesem Anwendungsfall verwalten Sie zwei Projekte. Auf dieser Seite bezieht sich das Kundenprojekt darauf, wo die Cloud Data Fusion-Instanz ausgeführt wird.
Aus dem Dataproc-Projekt geht hervor, wo die Dataproc-Cluster gestartet werden.

VPC des Kunden

Referenz Anwendungsfall

Aus der Perspektive des Kunden ist Cloud Data Fusion logisch in der VPC des Kunden platziert.


Wichtig:
Die VPC-Details des Kunden finden Sie auf der Seite „VPC-Netzwerke“ Ihres Projekts.

Zu VPC-Netzwerken

 Für diesen Anwendungsfall ist keine zusätzliche Konfiguration erforderlich.

Cloud Data Fusion-Subnetz

Referenz Anwendungsfall

Aus der Perspektive des Kunden befindet sich Cloud Data Fusion in diesem Subnetz.


Wichtig:
Die Region dieses Subnetzes entspricht dem Standort der Cloud Data Fusion-Instanz im Mandantenprojekt. 		Für diesen Anwendungsfall ist keine zusätzliche Konfiguration erforderlich.

Dataproc-Subnetz

Referenz Anwendungsfall

Das Subnetz, in dem Dataproc-Cluster beim Ausführen einer Pipeline gestartet werden.


Zusammenfassung:
  • Für diese Basiskonfiguration wird Dataproc im selben Subnetz wie die Cloud Data Fusion-Instanz ausgeführt.
  • Cloud Data Fusion ermittelt ein Subnetz in derselben Region wie die Instanz und das Subnetz von Cloud Data Fusion. Wenn es in dieser Region nur ein Subnetz gibt, sind die Subnetze identisch.
  • Das Dataproc-Subnetz muss privater Google-Zugriff haben.

Dies ist ein neues Subnetz, in dem Dataproc-Cluster gestartet werden, wenn Sie eine Pipeline ausführen.


Zusammenfassung:
  • Legen Sie für dieses neue Subnetz den privater Google-Zugriff auf Ein fest.
  • Das Dataproc-Subnetz muss sich nicht am selben Standort wie die Cloud Data Fusion-Instanz befinden.

Quellen und Senken

Referenz Anwendungsfall

Die Quellen, in denen Daten extrahiert werden, und Senken, in die Daten geladen werden, z. B. BigQuery-Quellen und -Senken.


Wichtigste Erkenntnis:
  • Die Jobs, mit denen Daten abgerufen und geladen werden, müssen am selben Standort wie das Dataset verarbeitet werden. Andernfalls wird ein Fehler ausgegeben.
 Die anwendungsfallspezifischen Konfigurationen für die Zugriffssteuerung auf dieser Seite gelten für BigQuery-Quellen und -Senken.

Cloud Storage

Referenz Anwendungsfall

Der Storage-Bucket im Kundenprojekt, mit dem Dateien zwischen Cloud Data Fusion und Dataproc übertragen werden.


Zusammenfassung:
  • Sie können diesen Bucket über die Cloud Data Fusion-Weboberfläche in den Compute-Profileinstellungen für sitzungsspezifische Cluster angeben.
  • Für Batch- und Echtzeitpipelines oder Replikationsjobs: Wenn Sie im Compute-Profil keinen Bucket angeben, erstellt Cloud Data Fusion zu diesem Zweck einen Bucket im selben Projekt wie die Instanz.
  • Sogar bei statischen Dataproc-Clustern wird der Bucket in dieser Basiskonfiguration von Cloud Data Fusion erstellt und unterscheidet sich von den Dataproc-Staging- und temporären Buckets.
  • Der Cloud Data Fusion API-Dienst-Agent hat integrierte Berechtigungen zum Erstellen dieses Buckets in dem Projekt, das die Cloud Data Fusion-Instanz enthält.
 Für diesen Anwendungsfall ist keine zusätzliche Konfiguration erforderlich.

Von Quelle und Senke verwendete temporäre Buckets

Referenz Anwendungsfall

Die temporären Buckets, die von Plug-ins für Ihre Quellen und Senken erstellt wurden, z. B. die Ladegeräte, die vom BigQuery-Senken-Plug-in initiiert wurden.


Zusammenfassung:
  • Sie können diese Buckets definieren, wenn Sie die Attribute des Quell- und Senken-Plug-ins konfigurieren.
  • Wenn Sie keinen Bucket definieren, wird ein Bucket in dem Projekt erstellt, in dem Dataproc ausgeführt wird.
  • Wenn das Dataset multiregional ist, wird der Bucket im selben Bereich erstellt.
  • Wenn Sie in der Plug-in-Konfiguration einen Bucket definieren, muss die Region des Buckets mit der Region des Datasets übereinstimmen.
  • Wenn Sie in den Plug-in-Konfigurationen keinen Bucket definieren, wird der für Sie erstellte Bucket gelöscht, sobald die Pipeline abgeschlossen ist.
 Für diesen Anwendungsfall kann der Bucket in einem beliebigen Projekt erstellt werden.

Buckets, die Quellen oder Senken von Daten für Plug-ins sind

Referenz Anwendungsfall
Kunden-Buckets, die Sie in den Konfigurationen für Plug-ins angeben, z. B. das Cloud Storage-Plug-in und das Plug-in "FTP zu Cloud Storage" Für diesen Anwendungsfall ist keine zusätzliche Konfiguration erforderlich.

IAM: Cloud Data Fusion API-Dienst-Agent

Referenz Anwendungsfall

Wenn die Cloud Data Fusion API aktiviert ist, wird dem Cloud Data Fusion-Dienstkonto, dem primären Dienst-Agent, automatisch die Rolle Cloud Data Fusion API-Dienst-Agent (roles/datafusion.serviceAgent) zugewiesen.


Zusammenfassung:
  • Die Rolle enthält Berechtigungen für Dienste, die sich im selben Projekt wie die Instanz befinden, z. B. BigQuery und Dataproc. Informationen zu allen unterstützten Diensten finden Sie in den Rollendetails.
  • Das Cloud Data Fusion-Dienstkonto führt folgende Schritte aus:
    • Kommunikation der Datenebene (Pipelinedesign und -ausführung) mit anderen Diensten (z. B. Kommunikation mit Cloud Storage, BigQuery und Datastream bei der Entwicklung).
    • Stellt Dataproc-Cluster bereit.
  • Wenn Sie aus einer Oracle-Quelle replizieren, müssen diesem Dienstkonto auch die Rollen Datastream Admin und Storage Admin in dem Projekt zugewiesen sein, in dem der Job ausgeführt wird. Auf dieser Seite wird kein Anwendungsfall für die Replikation behandelt.

Weisen Sie für diesen Anwendungsfall dem Dienstkonto im Dataproc-Projekt die Rolle „Cloud Data Fusion API-Dienst-Agent“ zu. Weisen Sie dann die folgenden Rollen in diesem Projekt zu:

  • Rolle "Compute-Netzwerknutzer"
  • Rolle „Dataproc-Bearbeiter“

IAM: Dataproc-Dienstkonto

Referenz Anwendungsfall

Das Dienstkonto, mit dem die Pipeline als Job im Dataproc-Cluster ausgeführt wird. Standardmäßig ist dies das Compute Engine-Dienstkonto.


Optional: In der Referenzkonfiguration können Sie das Standarddienstkonto in ein anderes Dienstkonto aus demselben Projekt ändern. Weisen Sie dem neuen Dienstkonto die folgenden IAM-Rollen zu:

  • Die Rolle „Cloud Data Fusion-Runner“. Über diese Rolle kann Dataproc mit der Cloud Data Fusion API kommunizieren.
  • Die Dataproc-Worker-Rolle Mit dieser Rolle können die Jobs auf Dataproc-Clustern ausgeführt werden.
Zusammenfassung:
  • Dem API-Agent-Dienstkonto für den neuen Dienst muss die Rolle „Dienstkontonutzer“ für das Dataproc-Dienstkonto zugewiesen sein, damit der Service API-Agent sie zum Starten von Dataproc-Clustern verwenden kann.

In diesem Anwendungsfallbeispiel wird davon ausgegangen, dass Sie das Compute Engine-Standarddienstkonto (PROJECT_NUMBER-compute@developer.gserviceaccount.com) des Dataproc-Projekts verwenden.


Weisen Sie dem Compute Engine-Standarddienstkonto im Dataproc-Projekt die folgenden Rollen zu.

  • Die Dataproc-Worker-Rolle
  • Die Rolle „Storage-Administrator“ (oder mindestens die Berechtigung „storage.buckets.create“), damit Dataproc temporäre Buckets für BigQuery erstellen kann.
  • Rolle „BigQuery-Jobnutzer“. Mit dieser Rolle können Dataproc Load-Jobs erstellen. Die Jobs werden standardmäßig im Dataproc-Projekt erstellt.
  • Rolle „BigQuery-Dataset-Bearbeiter“. Mit dieser Rolle kann Dataproc beim Laden von Daten Datasets erstellen.

Weisen Sie dem Cloud Data Fusion-Dienstkonto im Compute Engine-Standarddienstkonto des Dataproc-Projekts die Rolle „Dienstkontonutzer“ zu. Diese Aktion muss im Dataproc-Projekt ausgeführt werden.

Fügen Sie dem Cloud Data Fusion-Projekt das Compute Engine-Standarddienstkonto des Dataproc-Projekts hinzu. Weisen Sie außerdem die folgenden Rollen zu:

  • Die Rolle „Storage Object Viewer“ zum Abrufen von Pipelinejob-bezogenen Artefakten aus dem Cloud Data Fusion-Nutzer-Bucket.
  • Cloud Data Fusion-Runner-Rolle, damit der Dataproc-Cluster während der Ausführung mit Cloud Data Fusion kommunizieren kann.

APIs

Referenz Anwendungsfall
Wenn Sie die Cloud Data Fusion API aktivieren, werden auch die folgenden APIs aktiviert. Weitere Informationen zu diesen APIs finden Sie in Ihrem Projekt auf der Seite „APIs & Dienste“.

Zur Seite „APIs und Dienste“

  • Cloud Autoscaling API
  • Dataproc API
  • Cloud Dataproc-Steuerungs-API
  • Cloud DNS API
  • Cloud OS Login API
  • Pub/Sub API
  • Compute Engine API
  • Container Filesystem API
  • Container Registry API
  • Service Account Credentials API
  • Identity and Access Management API
  • Google Kubernetes Engine API

Wenn Sie die Cloud Data Fusion API aktivieren, werden Ihrem Projekt automatisch die folgenden Dienstkonten hinzugefügt:

  • Google APIs-Dienst-Agent
  • Compute Engine-Dienst-Agent
  • Kubernetes Engine-Dienst-Agent
  • Google Container Registry-Dienst-Agent
  • Google Cloud Dataproc-Dienst-Agent
  • Cloud KMS-Dienst-Agent
  • Cloud Pub/Sub-Dienstkonto
 Aktivieren Sie für diesen Anwendungsfall die folgenden APIs in dem Projekt, das das Dataproc-Projekt enthält:
  • Compute Engine API
  • Dataproc API (diese ist in diesem Projekt wahrscheinlich bereits aktiviert). Die Dataproc Control API wird automatisch aktiviert, wenn Sie die Dataproc API aktivieren.
  • Resource Manager API

Verschlüsselungsschlüssel

Referenz Anwendungsfall

In der Referenzkonfiguration können Verschlüsselungsschlüssel von Google oder vom CMEK verwaltet werden.


Zusammenfassung:

Wenn Sie CMEK verwenden, ist für die Basiskonfiguration Folgendes erforderlich:

  • Der Schlüssel muss regional sein und in derselben Region wie die Cloud Data Fusion-Instanz erstellt werden.
  • Gewähren Sie den folgenden Dienstkonten die Rolle "Cloud KMS CryptoKey Encrypter/Decrypter" auf Schlüsselebene (nicht auf der IAM-Seite der Google Cloud Console) in dem Projekt, in dem sie erstellt wird:
    • Cloud Data Fusion API-Dienstkonto
    • Dataproc-Dienstkonto, standardmäßig der Compute Engine-Dienst-Agent (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com)
    • Google Cloud Dataproc-Dienst-Agent (service-PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com)
    • Cloud Storage-Dienst-Agent (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)

Abhängig von den in Ihrer Pipeline verwendeten Diensten wie BigQuery oder Cloud Storage muss Dienstkonten auch die Rolle "Cloud KMS CryptoKey Encrypter/Decrypter" zugewiesen werden:

  • Das BigQuery-Dienstkonto (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com)
  • Das Pub/Sub-Dienstkonto (service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com)
  • Das Spanner-Dienstkonto (service-PROJECT_NUMBER@gcp-sa-spanner.iam.gserviceaccount.com)

Wenn Sie keinen CMEK verwenden, sind für diesen Anwendungsfall keine zusätzlichen Änderungen erforderlich.

Wenn Sie CMEK verwenden, muss die Rolle „Cloud KMS CryptoKey Encrypter/Decrypter“ für das folgende Dienstkonto auf Schlüsselebene in dem Projekt, in dem sie erstellt wird, bereitgestellt werden:

  • Cloud Storage-Dienst-Agent (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)

Abhängig von den in Ihrer Pipeline verwendeten Diensten wie BigQuery oder Cloud Storage muss auch anderen Dienstkonten die Rolle "Cloud KMS CryptoKey Encrypter/Decrypter" auf Schlüsselebene gewährt werden. Beispiel:

  • Das BigQuery-Dienstkonto (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com)
  • Das Pub/Sub-Dienstkonto (service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com)
  • Das Spanner-Dienstkonto (service-PROJECT_NUMBER@gcp-sa-spanner.iam.gserviceaccount.com)

Nachdem Sie diese anwendungsfallspezifischen Konfigurationen vorgenommen haben, kann Ihre Datenpipeline auf Clustern in einem anderen Projekt ausgeführt werden.

Nächste Schritte