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 Projekt verwendet. Google Cloud

Szenario

Wenn eine Cloud Data Fusion-Instanz in einemGoogle Cloud -Projekt gestartet wird, werden standardmäßig Pipelines mithilfe von Dataproc-Clustern im selben Projekt bereitgestellt und ausgeführt. Möglicherweise müssen Sie in Ihrer Organisation jedoch 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 Baseline (Standardkonfigurationen) ändern und die entsprechenden Zugriffssteuerungen anwenden.

Hinweis

Für die Lösungen in diesem Anwendungsfall ist der folgende Kontext erforderlich:

Annahmen und Umfang

Dieser Anwendungsfall hat folgende Anforderungen:

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

Lösung

Bei dieser Lösung werden die Architektur und Konfiguration für den Referenzwert und den Anwendungsfall verglichen.

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 Baseline-Architektur der Projekte:

Architektur von Mandanten-, Kunden- und Dataproc-Projekten in Cloud Data Fusion

Für die Baseline-Konfiguration 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.
  • Quell- und Senkenobjekt befinden sich im selben Projekt wie die Instanz
  • Keinen der Dienstkonten wurden zusätzliche Rollen zugewiesen.

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

Anwendungsfallarchitektur

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

Architektur von Mandanten-, Kunden- und Dataproc-Projekten in Cloud Data Fusion

Konfigurationen

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

In den folgenden Anwendungsfallbeschreibungen wird die Cloud Data Fusion-Instanz im Kundenprojekt ausgeführt und der Dataproc-Cluster wird im Dataproc-Projekt gestartet.

VPC und Instanz des Mandantenprojekts

Referenz Anwendungsfall
Im vorherigen Diagramm der Baseline-Architektur 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 werden Pipelines bereitgestellt und ausgeführt. 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 auf den Ort, an dem die Cloud Data Fusion-Instanz ausgeführt wird.
Das Dataproc-Projekt gibt an, wo die Dataproc-Cluster gestartet werden.

Kunden-VPC

Referenz Anwendungsfall

Aus Ihrer Sicht (der des Kunden) befindet sich Cloud Data Fusion logisch im VPC des Kunden.


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

Zur Seite „VPC-Netzwerke“

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

Cloud Data Fusion-Subnetz

Referenz Anwendungsfall

Aus Ihrer Sicht (der des Kunden) befindet sich Cloud Data Fusion logisch in diesem Subnetz.


Zusammenfassung
:Die Region dieses Subnetzes stimmt mit dem Speicherort der Cloud Data Fusion-Instanz im Mandantenprojekt überein. 		Für diesen Anwendungsfall ist keine zusätzliche Konfiguration erforderlich.

Dataproc-Subnetz

Referenz Anwendungsfall

Das Subnetz, in dem Dataproc-Cluster gestartet werden, wenn Sie eine Pipeline ausführen.


Zusammenfassung:
  • Bei dieser Baseline-Konfiguration wird Dataproc im selben Subnetz wie die Cloud Data Fusion-Instanz ausgeführt.
  • Cloud Data Fusion sucht 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.
  • Für das Dataproc-Subnetz muss der private Google-Zugriff aktiviert sein.

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


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

Quellen und Senken

Referenz Anwendungsfall

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


Hauptpunkt:
  • Die Jobs, die Daten abrufen und laden, müssen am selben Speicherort wie das Dataset verarbeitet werden, da sonst ein Fehler auftritt.
 Die nutzungsspezifischen Zugriffssteuerungskonfigurationen auf dieser Seite gelten für BigQuery-Quellen und -Ziele.

Cloud Storage

Referenz Anwendungsfall

Der Speicher-Bucket im Kundenprojekt, der die Übertragung von Dateien zwischen Cloud Data Fusion und Dataproc unterstützt.


Zusammenfassung:
  • Sie können diesen Bucket über die Cloud Data Fusion-Weboberfläche in den Einstellungen für das Compute-Profil für sitzungsspezifische Cluster angeben.
  • Für Batch- und Echtzeit-Pipelines 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.
  • Auch bei statischen Dataproc-Clustern wird der Bucket in dieser Baseline-Konfiguration von Cloud Data Fusion erstellt und unterscheidet sich von den Staging- und Temp-Buckets von Dataproc.
  • Der Cloud Data Fusion API-Dienstagent hat integrierte Berechtigungen zum Erstellen dieses Buckets im Projekt, das die Cloud Data Fusion-Instanz enthält.
 Für diesen Anwendungsfall ist keine zusätzliche Konfiguration erforderlich.

Temporäre Buckets, die von Quelle und Senke verwendet werden

Referenz Anwendungsfall

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


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

Buckets, die Datenquellen oder Datensenken 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 FTP-zu-Cloud Storage-Plug-in. 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 die Rolle Cloud Data Fusion API-Dienst-Agent (roles/datafusion.serviceAgent) automatisch dem Cloud Data Fusion-Dienstkonto, dem primären Dienst-Agent, zugewiesen.


Zusammenfassung:
  • Die Rolle enthält Berechtigungen für Dienste im selben Projekt wie die Instanz, z. B. BigQuery und Dataproc. Informationen zu allen unterstützten Diensten finden Sie in den Rollendetails.
  • Das Cloud Data Fusion-Dienstkonto hat folgende Aufgaben:
    • Kommunikation der Datenebene (Pipeline-Design und -Ausführung) mit anderen Diensten (z. B. Kommunikation mit Cloud Storage, BigQuery und Datastream zur Laufzeit)
    • Ermöglicht die Bereitstellung von Dataproc-Clustern.
  • Wenn Sie von einer Oracle-Quelle replizieren, muss diesem Dienstkonto außerdem die Rolle „Datastream-Administrator“ und die Rolle „Speicheradministrator“ im Projekt zugewiesen werden, 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 innerhalb des Dataproc-Clusters ausgeführt wird. Standardmäßig ist dies das Compute Engine-Dienstkonto.


Optional: In der Baseline-Konfiguration 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-Ausführer“ Mit dieser Rolle kann Dataproc mit der Cloud Data Fusion API kommunizieren.
  • Die Rolle „Dataproc Worker“. 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 werden, damit der Dienst-API-Agent damit Dataproc-Cluster starten kann.

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


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

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

Weisen Sie dem Cloud Data Fusion-Dienstkonto die Rolle „Dienstkontonutzer“ für das standardmäßige Compute Engine-Dienstkonto des Dataproc-Projekts zu. Diese Aktion muss im Dataproc-Projekt ausgeführt werden.

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

  • Die Rolle „Storage Object Viewer“, um Pipeline-Job-bezogene Artefakte aus dem Cloud Data Fusion-Nutzer-Bucket abzurufen.
  • Cloud Data Fusion-Ausführerrolle, damit der Dataproc-Cluster während des Betriebs 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“.

Zu „APIs und Dienste“

  • Cloud Autoscaling API
  • Dataproc API
  • Cloud Dataproc Control 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 im Projekt, das das Dataproc-Projekt enthält:
  • Compute Engine API
  • Dataproc API (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 Baseline-Konfiguration können Verschlüsselungsschlüssel von Google verwaltet oder CMEK sein.


Zusammenfassung:

Wenn Sie CMEK verwenden, sind für Ihre Baseline-Konfiguration folgende Voraussetzungen erforderlich:

  • Der Schlüssel muss regional sein und in derselben Region wie die Cloud Data Fusion-Instanz erstellt werden.
  • Weisen Sie den folgenden Dienstkonten in dem Projekt, in dem sie erstellt werden, auf Schlüsselebene (nicht auf der IAM-Seite der Google Cloud Console) die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ zu:
    • Cloud Data Fusion API-Dienstkonto
    • Dataproc-Dienstkonto, das standardmäßig der Compute Engine-Dienst-Agent (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) ist
    • 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)

Je nach den in Ihrer Pipeline verwendeten Diensten, z. B. BigQuery oder Cloud Storage, müssen Dienstkonten auch die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ gewährt 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 CMEK nicht verwenden, sind für diesen Anwendungsfall keine weiteren Änderungen erforderlich.

Wenn Sie CMEK verwenden, muss dem folgenden Dienstkonto auf Schlüsselebene im Projekt, in dem es erstellt wird, die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ zugewiesen werden:

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

Je nach den in Ihrer Pipeline verwendeten Diensten, z. B. BigQuery oder Cloud Storage, muss auch anderen Dienstkonten die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ auf Schlüsselebene zugewiesen 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 nutzungsfallspezifischen Konfigurationen vorgenommen haben, kann Ihre Datenpipeline in Clustern in einem anderen Projekt ausgeführt werden.

Nächste Schritte