Anwendungsfall: Zugriffssteuerung für einen Managed Service for Apache Spark-Cluster in einem anderen Projekt

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

Szenario

Wenn eine Cloud Data Fusion-Instanz in einemGoogle Cloud -Projekt gestartet wird, werden Pipelines standardmäßig mit Managed Service for Apache Spark-Clustern im selben Projekt bereitgestellt und ausgeführt. Ihre Organisation erfordert jedoch möglicherweise, dass Sie Cluster in einem anderen Projekt verwenden. In diesem Anwendungsfall müssen Sie den Zugriff zwischen den Projekten verwalten. Auf der folgenden Seite wird beschrieben, wie Sie die Baseline-Konfigurationen (Standard) ändern und die entsprechenden Zugriffssteuerungen anwenden können.

Hinweis

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

Annahmen und Geltungsbereich

Dieser Anwendungsfall hat folgende Anforderungen:

  • Eine private Cloud Data Fusion-Instanz. Aus Sicherheitsgründen kann es sein, dass Ihre Organisation die Verwendung dieser Art von Instanz vorschreibt.
  • Eine BigQuery-Quelle und ‑Senke.
  • Zugriffssteuerung mit IAM, nicht mit rollenbasierter Zugriffssteuerung (RBAC).

Lösung

In dieser Lösung werden die Architektur und Konfiguration der Baseline mit denen des Anwendungsfalls verglichen.

Architektur

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

Referenzarchitektur

Das folgende Diagramm zeigt die Baseline-Architektur der Projekte:

Mandanten-, Kunden- und Dataproc-Projektarchitektur 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 Anpassung aus:

  • Sie verwenden eines der integrierten Compute-Profile.
  • Die Quelle und das Ziel befinden sich im selben Projekt wie die Instanz.
  • Keinem der Dienstkonten wurden zusätzliche Rollen zugewiesen.

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

Architektur des Anwendungsfalls

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 an den Anwendungsfall angepassten Konfigurationen für die Verwendung von Managed Service for Apache Spark-Clustern in einem anderen Projekt über die Standard-VPC des Mandantenprojekts verglichen.

In den folgenden Beschreibungen der Anwendungsfälle wird die Cloud Data Fusion-Instanz im Kundenprojekt ausgeführt und der Managed Service for Apache Spark-Cluster wird im Managed Service for Apache Spark-Projekt gestartet.

VPC und Instanz des Mandantenprojekts

Referenz Anwendungsfall
Im obigen 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 stellen Sie Pipelines bereit und führen sie aus. Standardmäßig werden die Managed Service for Apache Spark-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 Managed Service for Apache Spark-Projekt bezieht sich auf den Ort, an dem die Managed Service for Apache Spark-Cluster gestartet werden.

Kunden-VPC

Referenz Anwendungsfall

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


Wichtig
Die VPC-Details 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 (der Kundin/des Kunden) Sicht befindet sich Cloud Data Fusion logisch in diesem Subnetz.


Wichtiger Hinweis:
Die Region dieses Subnetzes ist dieselbe wie der Standort der Cloud Data Fusion-Instanz im Mandantenprojekt. 		Für diesen Anwendungsfall ist keine zusätzliche Konfiguration erforderlich.

Managed Service for Apache Spark-Subnetz

Referenz Anwendungsfall

Das Subnetz, in dem Managed Service for Apache Spark-Cluster gestartet werden, wenn Sie eine Pipeline ausführen.


Zusammenfassung:
  • Bei dieser Baseline-Konfiguration wird Managed Service for Apache Spark 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 Subnetz von Managed Service for Apache Spark muss der privater Google-Zugriff aktiviert sein.

Dies ist ein neues Subnetz, in dem Managed Service for Apache Spark-Cluster gestartet werden, wenn Sie eine Pipeline ausführen.


Zusammenfassung:
  • Setzen Sie für dieses neue Subnetz den privater Google-Zugriff auf Ein.
  • Das Managed Service for Apache Spark-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.


Wichtigste Erkenntnis
  • Die Jobs zum Abrufen und Laden von Daten müssen am selben Standort wie das Dataset verarbeitet werden. Andernfalls tritt ein Fehler auf.
 Die anwendungsfallspezifischen Konfigurationen für die Zugriffssteuerung auf dieser Seite gelten für BigQuery-Quellen und ‑Senken.

Cloud Storage

Referenz Anwendungsfall

Der Speicher-Bucket im Kundenprojekt, der zum Übertragen von Dateien zwischen Cloud Data Fusion und Managed Service for Apache Spark verwendet wird.


Zusammenfassung:
  • Sie können diesen Bucket über die Cloud Data Fusion-Weboberfläche in den Compute-Profil-Einstellungen für kurzlebige Cluster angeben.
  • Für Batch- und Echtzeitpipelines oder Replikationsjobs gilt Folgendes: Wenn Sie im Rechenprofil keinen Bucket angeben, erstellt Cloud Data Fusion einen Bucket im selben Projekt wie die Instanz.
  • Auch für statische Managed Service for Apache Spark-Cluster wird der Bucket in dieser Baseline-Konfiguration von Cloud Data Fusion erstellt und unterscheidet sich von den Staging- und temporären Buckets von Managed Service for Apache Spark.
  • 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.

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 vom BigQuery Sink-Plug-in initiierten Ladejobs.


Zusammenfassung:
  • Sie können diese Buckets definieren, wenn Sie die Quell- und Senken-Plug-in-Attribute konfigurieren.
  • Wenn Sie keinen Bucket definieren, wird einer im selben Projekt erstellt, in dem Managed Service for Apache Spark ausgeführt wird.
  • Wenn das Dataset multiregional ist, wird der Bucket im selben Bereich erstellt.
  • Wenn Sie einen Bucket in der Plug-in-Konfiguration 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 nach Abschluss der Pipeline gelöscht.
 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 wie das Cloud Storage-Plug-in und das FTP-zu-Cloud Storage-Plug-in angeben. 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 Service 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 Managed Service for Apache Spark. Eine Liste aller unterstützten Dienste 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 Designzeit).
    • Stellt Managed Service for Apache Spark-Cluster bereit.
  • Wenn Sie Daten aus einer Oracle-Quelle replizieren, muss diesem Dienstkonto auch die Rolle „Datastream-Administrator“ und „Storage-Administrator“ in dem Projekt zugewiesen werden, in dem der Job ausgeführt wird. Auf dieser Seite wird kein Replikationsanwendungsfall behandelt.

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

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

IAM: Dienstkonto für Managed Service for Apache Spark

Referenz Anwendungsfall

Das Dienstkonto, das zum Ausführen der Pipeline als Job im Managed Service for Apache Spark-Cluster verwendet wird. Standardmäßig ist es 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 Managed Service for Apache Spark mit der Cloud Data Fusion API kommunizieren.
  • Die Rolle „Dataproc Worker“. Mit dieser Rolle können Jobs in Managed Service for Apache Spark-Clustern ausgeführt werden.
Zusammenfassung:
  • Dem API-Agent-Dienstkonto für den neuen Dienst muss die Rolle „Dienstkontonutzer“ für das Dienstkonto von Managed Service for Apache Spark gewährt werden, damit der Service API-Agent damit Managed Service for Apache Spark-Cluster starten kann.

In diesem Anwendungsbeispiel wird davon ausgegangen, dass Sie das Compute Engine-Standarddienstkonto (PROJECT_NUMBER-compute@developer.gserviceaccount.com) des Managed Service for Apache Spark-Projekts verwenden.


Weisen Sie dem Compute Engine-Standarddienstkonto im Managed Service for Apache Spark-Projekt die folgenden Rollen zu.

  • Die Rolle „Dataproc Worker“
  • Die Rolle „Storage Admin“ (oder mindestens die Berechtigung `storage.buckets.create`), damit Managed Service for Apache Spark temporäre Buckets für BigQuery erstellen kann.
  • Rolle „BigQuery Job User“ Mit dieser Rolle kann Managed Service for Apache Spark Ladejobs erstellen. Die Jobs werden standardmäßig im Managed Service for Apache Spark-Projekt erstellt.
  • Rolle „BigQuery Dataset Editor“ Mit dieser Rolle kann Managed Service for Apache Spark 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 Managed Service for Apache Spark-Projekts zu. Diese Aktion muss im Managed Service for Apache Spark-Projekt ausgeführt werden.

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

  • Die Rolle „Storage Object Viewer“ zum Abrufen von Artefakten, die sich auf Pipelinejobs beziehen, aus dem Cloud Data Fusion-Consumer-Bucket.
  • Cloud Data Fusion Runner-Rolle, damit der Managed Service for Apache Spark-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 auf der Seite „APIs & Dienste“ in Ihrem Projekt.

Zu „APIs & 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
  • Kubernetes Engine API

Wenn Sie die Cloud Data Fusion API aktivieren, werden die folgenden Dienstkonten automatisch Ihrem Projekt 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 Managed Service for Apache Spark-Projekt enthält, sofern sie noch nicht aktiviert sind:
  • Compute Engine API
  • Dataproc API
  • Cloud Resource Manager API

Verschlüsselungsschlüssel

Referenz Anwendungsfall

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


Zusammenfassung:

Wenn Sie CMEK verwenden, muss Ihre Baseline-Konfiguration Folgendes enthalten:

  • Der Schlüssel muss regional sein und in derselben Region wie die Cloud Data Fusion-Instanz erstellt werden.
  • Weisen Sie den folgenden Dienstkonten auf Schlüsselebene (nicht auf der IAM-Seite der Google Cloud Konsole) im Projekt, in dem sie erstellt wurden, die Rolle „Cloud KMS CryptoKey Encrypter/Decrypter“ zu:
    • Cloud Data Fusion API-Dienstkonto
    • Das Dienstkonto für Managed Service for Apache Spark, 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 wie BigQuery oder Cloud Storage muss den 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 CMEK nicht verwenden, sind für diesen Anwendungsfall keine zusätzlichen Änderungen erforderlich.

Wenn Sie CMEK verwenden, muss dem folgenden Dienstkonto auf Schlüsselebene in dem Projekt, in dem es erstellt wird, die Rolle „Cloud KMS CryptoKey Encrypter/Decrypter“ 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 anderen Dienstkonten auch 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 an den Anwendungsfall angepassten Konfigurationen vorgenommen haben, kann Ihre Datenpipeline in Clustern in einem anderen Projekt ausgeführt werden.

Nächste Schritte