Cas d'utilisation: contrôle des accès à un cluster Dataproc dans un autre projet

Cette page explique comment gérer le contrôle des accès lorsque vous déployez et exécutez un pipeline qui utilise des clusters Dataproc dans un autre projet Google Cloud.

Scénario

Par défaut, lorsqu'une instance Cloud Data Fusion est lancée dans un Google Cloud, il déploie et exécute des pipelines clusters Dataproc au sein du même projet. Toutefois, votre organisation peut vous demander d'utiliser des clusters dans un autre projet. Pour ce cas d'utilisation, vous devez gérer l'accès entre les projets. La page suivante explique comment modifier les configurations de référence (par défaut) et appliquer les contrôles d'accès appropriés.

Avant de commencer

Pour comprendre les solutions de ce cas d'utilisation, vous avez besoin du contexte suivant:

Hypothèses et portée

Ce cas d'utilisation présente les exigences suivantes :

  • Une instance Cloud Data Fusion privée. Pour des raisons de sécurité, une organisation peut exiger que vous utilisiez ce type Compute Engine.
  • Une source et un récepteur BigQuery
  • Contrôle des accès avec IAM, et non basé sur les rôles (RBAC).

Solution

Cette solution compare des architectures et des cas d'utilisation spécifiques configuration.

Architecture

Les diagrammes suivants comparent l'architecture de projet pour créer une instance Cloud Data Fusion et exécuter des pipelines lorsque vous utilisez des clusters dans le même projet (référence) et dans un autre projet via le VPC du projet locataire.

Architecture de référence

Ce schéma présente l'architecture de référence des projets :

Architecture des locataires, des clients et des projets Dataproc dans Cloud Data Fusion.

Pour la configuration de référence, vous créez une instance Cloud Data Fusion privée et exécuter un pipeline sans personnalisation supplémentaire:

  • Utilisez l'un des profils de calcul intégrés
  • La source et le récepteur se trouvent dans le même projet que l'instance.
  • Aucun rôle supplémentaire n'a été accordé aux comptes de service

Pour en savoir plus sur les projets locataires et clients, consultez la page Mise en réseau.

Architecture de cas d'utilisation

Ce diagramme montre l'architecture du projet lorsque vous utilisez des clusters dans un autre projet :

Architecture des projets de locataire, client et Dataproc dans Cloud Data Fusion.

Configurations

Les sections suivantes comparent les configurations de référence aux configurations spécifiques au cas d'utilisation pour utiliser des clusters Dataproc dans un autre projet via le VPC par défaut du projet de locataire.

Dans les descriptions de cas d'utilisation suivantes, le projet client correspond à l'emplacement Exécution de l'instance Cloud Data Fusion et du projet Dataproc est l'endroit où le cluster Dataproc est lancé.

VPC et instance du projet locataire

Référence Cas d'utilisation
Dans le schéma précédent de l'architecture de référence, le projet locataire contient les composants suivants:
  • Le VPC par défaut, qui est créé automatiquement.
  • Déploiement physique de l'instance Cloud Data Fusion.
 Aucune configuration supplémentaire n'est requise pour ce cas d'utilisation.

Projet client

Référence Cas d'utilisation
Votre projet Google Cloud est l'endroit où vous déployez et exécutez des pipelines. Par défaut, les clusters Dataproc sont lancés dans ce lorsque vous exécutez vos pipelines. Dans ce cas d'utilisation, vous gérez deux projets. Sur cette page, projet client désigne l'endroit où Cloud Data Fusion s'exécute sur l'instance.
Le projet Dataproc fait référence où sont lancés les clusters Dataproc.

VPC du client

Référence Cas d'utilisation

Du point de vue du client, c'est le VPC du client où Cloud Data Fusion se trouve logiquement.


En résumé
 : Vous trouverez les détails du VPC client sur la page "Réseaux VPC" de votre projet.

Accéder à la page "Réseaux VPC"

 Aucune configuration supplémentaire n'est requise pour ce cas d'utilisation.

Sous-réseau Cloud Data Fusion

Référence Cas d'utilisation

Du point de vue du client, c'est dans ce sous-réseau que Cloud Data Fusion se trouve.


Point clé à retenir
La région de ce sous-réseau est identique comme emplacement de l'instance Cloud Data Fusion dans le locataire projet. 		Aucune configuration supplémentaire n'est requise pour ce cas d'utilisation.

Sous-réseau Dataproc

Référence Cas d'utilisation

Sous-réseau dans lequel les clusters Dataproc sont lancés lorsque vous exécutez un pipeline.


Points à retenir:
  • Pour cette configuration de référence, Dataproc est exécuté sur le même sous-réseau que l'instance Cloud Data Fusion.
  • Cloud Data Fusion localise un sous-réseau dans la même région que l'instance et le sous-réseau de Cloud Data Fusion. S'il n'y a qu'un seul sous-réseau dans cette région, les sous-réseaux sont identiques.
  • Le sous-réseau Dataproc doit comporter Accès privé à Google.

Il s'agit d'un nouveau sous-réseau dans lequel lancé lorsque vous exécutez un pipeline.


Points à retenir:
  • Pour ce nouveau sous-réseau, définissez l'accès privé à Google sur Activé :
  • Le sous-réseau Dataproc n'a pas besoin d'être au même emplacement que l'instance Cloud Data Fusion.

Sources et récepteurs

Référence Cas d'utilisation

Sources à partir desquelles les données sont extraites et récepteurs dans lesquels les données sont chargées, tels que les sources et les récepteurs BigQuery.


Point clé à retenir:
  • Les tâches qui extraient et chargent des données doivent être traitées au même emplacement que l'ensemble de données, sinon une erreur se produit.
 Les configurations de contrôle des accès spécifiques au cas d'utilisation de cette page sont destinées aux sources et aux destinations BigQuery.

Cloud Storage

Référence Cas d'utilisation

Bucket de stockage du projet client qui permet de transférer des fichiers entre Cloud Data Fusion et Dataproc.


Points à retenir :
  • Vous pouvez spécifier ce bucket via l'interface Web Cloud Data Fusion dans les paramètres du profil de calcul pour les clusters éphémères.
  • Pour les pipelines par lot et en temps réel, ou les tâches de réplication : si vous ne spécifiez pas de bucket dans le profil de calcul, Cloud Data Fusion en crée un dans le même projet que l'instance à cette fin.
  • Même pour les clusters Dataproc statiques, dans cette configuration de référence, le bucket est créé par Cloud Data Fusion et diffère des buckets de préproduction et temporaires Dataproc.
  • L'agent de service de l'API Cloud Data Fusion dispose d'autorisations intégrées pour créer ce bucket dans le projet contenant l'instance Cloud Data Fusion.
 Aucune configuration supplémentaire n'est requise pour ce cas d'utilisation.

Buckets temporaires utilisés par la source et le récepteur

Référence Cas d'utilisation

Les buckets temporaires créés par des plug-ins pour vos sources et récepteurs tels que les jobs de chargement initiés par le plug-in récepteur BigQuery.


Points à retenir :
  • Vous pouvez définir ces buckets lorsque vous configurez la source et le récepteur Propriétés du plug-in.
  • Si vous ne définissez pas de bucket, un bucket sera créé dans le même projet où Dataproc s'exécute.
  • Si l'ensemble de données est multirégional, le bucket est créé dans le même champ d'application.
  • Si vous définissez un bucket dans la configuration du plug-in, la région le bucket doit correspondre à la région de l'ensemble de données.
  • Si vous ne définissez pas de bucket dans les configurations du plug-in, créé pour vous est supprimé à la fin du pipeline.
 Pour ce cas d'utilisation, le bucket peut être créé dans n'importe quel projet.

Buckets qui sont des sources ou des récepteurs de données pour les plug-ins

Référence Cas d'utilisation
Les buckets client, que vous spécifiez dans les configurations des plug-ins, comme le plug-in Cloud Storage et le FTP pour Plug-in Cloud Storage. Aucune configuration supplémentaire n'est requise pour ce cas d'utilisation.

IAM : agent de service de l'API Cloud Data Fusion

Référence Cas d'utilisation

Lorsque l'API Cloud Data Fusion est activée, le rôle Agent de service de l'API Cloud Data Fusion (roles/datafusion.serviceAgent) est automatiquement attribué au compte de service Cloud Data Fusion, qui est l'agent de service principal.


Points à retenir:
  • Le rôle contient des autorisations pour les services du même projet que l'instance, comme BigQuery Dataproc. Pour connaître tous les services compatibles, consultez les informations sur le rôle.
  • Le compte de service Cloud Data Fusion effectue les opérations suivantes :
    • Communication du plan de données (conception et exécution du pipeline) avec d'autres services (par exemple, communication avec Cloud Storage, BigQuery et Datastream au moment de la conception).
    • Provisionne les clusters Dataproc.
  • Si vous effectuez une réplication à partir d'une source Oracle, ce compte de service doit également disposer des rôles "Datastream Admin" et "Storage Admin" dans le projet où la tâche est effectuée. Cette page ne traite pas d'un de la réplication.

Pour ce cas d'utilisation, attribuez le rôle d'agent de service de l'API Cloud Data Fusion au compte de service du projet Dataproc. Attribuez ensuite les rôles suivants dans ce projet :

  • Rôle d'utilisateur de réseau de Compute
  • Rôle d'éditeur Dataproc

IAM: compte de service Dataproc

Référence Cas d'utilisation

Le compte de service utilisé pour exécuter le pipeline en tant que job dans le cluster Dataproc. Par défaut, il s'agit compte de service Compute Engine.


Facultatif: dans la configuration de référence, vous pouvez modifier la valeur par défaut compte de service vers un autre compte de service du même projet. Accorder les rôles IAM suivants au nouveau compte de service:

  • Rôle d'exécuteur Cloud Data Fusion. Ce rôle permet Dataproc communique avec l'API Cloud Data Fusion.
  • Le rôle Nœud de calcul Dataproc. Ce rôle permet aux jobs de s'exécuter sur Clusters Dataproc.
Points à retenir:
  • Le compte de service de l'agent API du nouveau service doit être attribué au rôle Utilisateur du compte de service sur le compte de service Dataproc afin que l'agent de l'API de service puisse l'utiliser pour lancer des clusters Dataproc.

Dans cet exemple de cas d'utilisation, nous partons du principe que vous utilisez Compte de service Compute Engine (PROJECT_NUMBER-compute@developer.gserviceaccount.com) du projet Dataproc.


Attribuez les rôles suivants au compte de service Compute Engine par défaut du projet Dataproc.

  • Rôle de nœud de calcul Dataproc
  • Le rôle Administrateur de stockage (ou au minimum l'autorisation "storage.buckets.create") pour autoriser Dataproc à créer des buckets temporaires pour BigQuery.
  • Rôle Utilisateur de tâche BigQuery Ce rôle permet à Dataproc créer des jobs de chargement. Les tâches sont créées dans le projet Dataproc par défaut.
  • Rôle Éditeur d'ensemble de données BigQuery Ce rôle permet à Dataproc de créer des ensembles de données lors du chargement de données.

Attribuez le rôle "Utilisateur du compte de service" au compte de service Cloud Data Fusion sur le compte de service Compute Engine par défaut du projet Dataproc. Cette action doit être effectuée dans Projet Dataproc.

Ajoutez le compte de service Compute Engine par défaut du projet Dataproc au projet Cloud Data Fusion. Attribuez également les rôles suivants :

  • Le rôle de lecteur des objets Storage pour récupérer les tâches de pipeline associées aux artefacts du bucket Cloud Data Fusion Consumer.
  • Le rôle d'exécuteur Cloud Data Fusion est donc requis. peut communiquer avec Cloud Data Fusion en cours d'exécution.

API

Référence Cas d'utilisation
Lorsque vous activez l'API Cloud Data Fusion, les API suivantes sont également activées. Pour en savoir plus sur ces API, consultez API et de votre projet.

Accéder à "API et services"

  • API 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

Lorsque vous activez l'API Cloud Data Fusion, le service suivant sont automatiquement ajoutés à votre projet:

  • Agent de service des API Google
  • Agent de service Compute Engine
  • Agent de service Kubernetes Engine
  • Agent de service Google Container Registry
  • Agent de service Google Cloud Dataproc
  • Agent de service Cloud KMS
  • Compte de service Cloud Pub/Sub
 Pour ce cas d'utilisation, activez les API suivantes dans le projet que contient le projet Dataproc:
  • API Compute Engine
  • API Dataproc (elle est probablement déjà activée dans ce projet). L'API Dataproc Control est automatiquement activée lorsque vous activez l'API Dataproc.
  • API Resource Manager

Clés de chiffrement

Référence Cas d'utilisation

Dans la configuration de référence, les clés de chiffrement peuvent être gérées par Google ou CMEK.


Points à retenir :

Si vous utilisez CMEK, votre configuration de référence nécessite les éléments suivants :

  • La clé doit être régionale et créée dans la même région que l'instance Cloud Data Fusion.
  • Attribuez le rôle "Chiffreur/Déchiffreur de CryptoKeys Cloud KMS" au les comptes de service suivants au niveau de la clé (et non dans le page IAM de la console Google Cloud) dans le projet où elles sont créées:
    • Compte de service de l'API Cloud Data Fusion
    • Compte de service Dataproc, qui est l'agent de service Compute Engine (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) par défaut
    • Agent de service Google Cloud Dataproc (service-PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com)
    • Agent de service Cloud Storage (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)

Selon les services utilisés dans votre pipeline, tels que BigQuery ou Cloud Storage, les comptes de service doivent également se voir attribuer le rôle Chiffreur/Déchiffreur de CryptoKey Cloud KMS :

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

Si vous n'utilisez pas de CMEK, aucune modification supplémentaire n'est nécessaire pour cette utilisation .

Si vous utilisez une CMEK, le rôle Chiffreur/Déchiffreur de CryptoKeys Cloud KMS doit au compte de service suivant au niveau de la clé dans le projet dans lequel elle est créée:

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

En fonction des services utilisés dans votre pipeline, BigQuery ou Cloud Storage, autres comptes de service doit également disposer du rôle Chiffreur/Déchiffreur de CryptoKeys Cloud KMS au niveau de la clé. Exemple :

  • Le compte de service BigQuery (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com)
  • Compte de service Pub/Sub (service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com)
  • Compte de service Spanner (service-PROJECT_NUMBER@gcp-sa-spanner.iam.gserviceaccount.com)

Une fois ces configurations spécifiques au cas d'utilisation effectuées, votre pipeline de données peut commencer à s'exécuter sur des clusters dans un autre projet.

Étape suivante