Sécurité et autorisations pour Dataflow

Les pipelines Dataflow peuvent être exécutés en local (pour effectuer des tests sur de petits ensembles de données) ou sur des ressources Google Cloud gérées, à l'aide du service géré Dataflow. Que le pipeline et ses nœuds de calcul soient exécutés localement ou dans le cloud, ils utilisent un système d'autorisations pour assurer la sécurité d'accès aux fichiers et aux ressources du pipeline. Les autorisations Dataflow sont attribuées en fonction du rôle utilisé pour accéder aux ressources du pipeline. Ce document présente les concepts suivants :

• Mettre à niveau des VM Dataflow
• Rôles et autorisations requis pour exécuter des pipelines locaux et Google Cloud
• Rôles et autorisations requis pour accéder aux ressources de pipeline entre projets.
• Types de données utilisés dans un service Dataflow et dans la sécurité des données.

Avant de commencer

Pour en savoir plus sur les identifiants de projet Google Cloud, consultez la présentation de la plate-forme. Ces identifiants incluent le nom, l'ID et le numéro du projet.

Mettre à niveau et corriger des VM Dataflow

Dataflow utilise Container-Optimized OS. Les processus de sécurité de Container-Optimized OS s'appliquent donc également à Dataflow.

Les pipelines par lot sont limités dans le temps et ne nécessitent pas de maintenance. Lorsqu'un nouveau pipeline par lot démarre, la dernière image Dataflow est utilisée.

Pour les pipelines de streaming, si un correctif de sécurité est immédiatement requis, Google Cloud vous avertit à l'aide de bulletins de sécurité. Pour les pipelines de streaming, nous vous recommandons d'utiliser l'option --update pour redémarrer votre tâche avec la dernière image Dataflow.

Les images de conteneurs Dataflow sont disponibles dans Google Cloud Console.

Sécurité et autorisations pour les pipelines locaux

En local, le pipeline Apache Beam est exécuté avec le compte Google Cloud que vous avez configuré à l'aide de l'exécutable de Google Cloud CLI. Par conséquent, les opérations du SDK Apache Beam exécutées localement et votre compte Google Cloud ont accès aux mêmes fichiers et ressources.

Pour répertorier le compte Google Cloud que vous avez sélectionné par défaut, exécutez la commande gcloud config list.

Remarque : Les pipelines locaux peuvent générer des données vers des destinations locales, par exemple des fichiers locaux, ou vers des destinations dans le cloud, comme Cloud Storage ou BigQuery. Si le pipeline exécuté localement écrit des fichiers sur des ressources cloud telles que Cloud Storage, il utilise vos identifiants de compte Google Cloud et le projet Google Cloud que vous avez configuré comme valeur par défaut dans Google Cloud CLI. Pour obtenir des instructions concernant l'authentification avec les identifiants de compte Google Cloud, consultez le guide de démarrage rapide correspondant au langage que vous utilisez.

Sécurité et autorisations pour les pipelines sur Google Cloud

Lorsque vous exécutez un pipeline, Cloud Dataflow utilise deux comptes de service pour gérer la sécurité et les autorisations :

• Le compte de service Dataflow. Le service Dataflow utilise son compte de service dans le cadre d'une requête de création de tâche (par exemple, pour vérifier le quota des projets et créer des instances de nœud de calcul en votre nom). Dataflow utilise également le compte de service Dataflow lors de l'exécution de la tâche pour la gérer. Ce compte est également appelé agent de service Dataflow.

• Le compte de service des nœuds de calcul. Les instances de nœud de calcul utilisent le compte de service du nœud de calcul pour accéder aux ressources d'entrée et de sortie une fois que vous avez envoyé la tâche. Par défaut, les nœuds de calcul utilisent le compte de service Compute Engine par défaut associé à votre projet comme compte de service de nœud de calcul. Pour que le compte de service du nœud de calcul puisse créer, exécuter et examiner une tâche, il doit disposer des rôles suivants :

  • roles/dataflow.admin
  • roles/dataflow.worker

En outre, lorsque vos pipelines Apache Beam accèdent aux ressources Google Cloud, vous devez attribuer les rôles requis au compte de service du nœud de calcul de votre projet Dataflow. Le compte de service du nœud de calcul doit pouvoir accéder aux ressources lors de l'exécution de la tâche Dataflow. Par exemple, si la tâche écrit dans BigQuery, votre compte de service doit également être doté du rôle roles/bigquery.dataEditor. Voici quelques exemples de ressources :

• Buckets Cloud Storage
• Ensembles de données BigQuery
• Sujets et abonnements Pub/Sub
• Ensembles de données Firestore

Enfin, pour emprunter l'identité du compte de service, votre compte utilisateur doit disposer du rôle suivant : iam.serviceAccounts.actAs. En fonction d'autres autorisations de projet, votre compte utilisateur peut également avoir besoin du rôle roles/dataflow.developer.

Pour ajouter les rôles requis à votre projet, procédez comme suit :

Console

1. Dans Google Cloud Console, accédez à la page IAM.

   Accéder à IAM

2. Sélectionnez votre projet.

3. Sur la ligne contenant votre compte utilisateur, cliquez sur Modifier le compte principal, puis sur Ajouter un autre rôle.

4. Dans la liste déroulante, sélectionnez le rôle Utilisateur du compte de service.

5. Sur la ligne contenant le compte de service Compute Engine par défaut, cliquez sur Modifier le compte principal, puis sur Ajouter un autre rôle.

6. Dans la liste déroulante, sélectionnez le rôle Nœud de calcul Dataflow.

7. Répétez l'opération pour l'administrateur Dataflow et tous les rôles requis par les ressources utilisées dans votre tâche, puis cliquez sur Enregistrer.

   Pour en savoir plus sur l'attribution de rôles, consultez la page Attribuer un rôle IAM à l'aide de la console.

gcloud CLI

1. Attribuez le rôle roles/iam.serviceAccountUser à votre compte de service : Exécutez la commande suivante :

   gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS --role=roles/iam.serviceAccountUser
   

   • Remplacez PROJECT_ID par l'ID de votre projet.
   • Remplacez EMAIL_ADDRESS par l'adresse e-mail du compte utilisateur.

2. Attribuez des rôles à votre compte de service Compute Engine par défaut. Exécutez la commande suivante une fois pour chacun des rôles IAM suivants : roles/dataflow.admin, roles/dataflow.worker, et tous les rôles requis par les ressources utilisées dans votre tâche.

   gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:[e-mail]" --role=SERVICE_ACCOUNT_ROLE
   

   • Remplacez PROJECT_ID par l'ID de votre projet.
   • Remplacez PROJECT_NUMBER par votre numéro de projet. Pour trouver votre numéro de projet, consultez la section Identifier des projets ou utilisez la commande gcloud projects describe.
   • Remplacez SERVICE_ACCOUNT_ROLE par chaque rôle individuel.

Compte de service Dataflow

Tous les projets qui ont utilisé la ressource Dataflow Job disposent d'un compte de service Dataflow, également appelé agent de service Dataflow, qui utilise l'adresse e-mail suivante :

service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com

Ce compte de service est créé et géré par Google, et attribué automatiquement à votre projet lors de la première utilisation de la ressource Dataflow Job.

Lors de l'exécution du pipeline Dataflow, ce service manipule les ressources en votre nom (par exemple, en créant des VM supplémentaires). Lorsque vous exécutez votre pipeline sur le service Dataflow, le service utilise ce compte de service.

Ce compte se voit attribuer le rôle Agent de service Dataflow sur le projet. Il dispose des autorisations nécessaires pour exécuter une tâche Dataflow dans le projet, y compris le démarrage des nœuds de calcul Compute Engine. Ce compte est utilisé exclusivement par le service Dataflow et est propre à votre projet.

Vous pouvez examiner les autorisations du compte de service Dataflow dans la console Google Cloud ou dans Google Cloud CLI.

Console

1. Accéder à la page Rôles

   Accéder à la page "Rôles"

2. Dans la barre d'outils de la console Google Cloud, sélectionnez votre projet.

3. Pour afficher les autorisations du compte de service Dataflow, cochez la case Inclure les attributions de rôles fournies par Google en haut à droite. Cochez la case Agent de service Cloud Dataflow.

gcloud CLI

Affichez les autorisations du compte de service Dataflow:

gcloud iam roles describe roles/dataflow.serviceAgent

Comme les services Google Cloud attendent un accès en lecture/écriture au projet et à ses ressources, nous vous recommandons de ne pas modifier les autorisations par défaut qui sont établies automatiquement pour votre projet. Si un compte de service Dataflow perd ses autorisations sur un projet, Dataflow ne peut pas lancer de VM ni effectuer d'autres tâches de gestion.

Si vous supprimez les autorisations du compte de service de la stratégie IAM (Identity and Access Management), le compte reste présent, car il appartient au service Dataflow.

Bonne pratique : Créez un bucket appartenant à votre projet, qui servira de bucket de préproduction pour Dataflow. Les autorisations de bucket par défaut permettent à Dataflow d'utiliser le bucket pour organiser les fichiers exécutables du pipeline.

Compte de service de nœud de calcul

Les instances Compute Engine exécutent les opérations du SDK Apache Beam dans le cloud. Ces nœuds de calcul utilisent le compte de service de nœud de calcul de votre projet pour accéder aux fichiers et aux autres ressources associées au pipeline. Le compte de service du nœud de calcul sert d'identité à toutes les VM de nœud de calcul, et toutes les requêtes provenant de la VM utilisent le compte de service du nœud de calcul. Ce compte de service est également utilisé pour interagir avec des ressources telles que des buckets Cloud Storage et des sujets Pub/Sub.

Pour que le compte de service du nœud de calcul puisse créer, exécuter et examiner une tâche, il doit disposer des rôles suivants :

• roles/dataflow.admin
• roles/dataflow.worker

Compte de service de nœud de calcul par défaut

Par défaut, les nœuds de calcul utilisent le compte de service Compute Engine par défaut de votre projet en tant que compte de service de nœud de calcul. Ce compte de service utilise l'adresse e-mail suivante :

<project-number>[e-mail]

Ce compte de service est créé automatiquement lorsque vous activez l'API Compute Engine pour votre projet à partir de la bibliothèque d'API de la console Google Cloud.

Le compte de service Compute Engine par défaut dispose d'un accès étendu aux ressources de votre projet, ce qui facilite la mise en route de Dataflow. Toutefois, pour les charges de travail de production, nous vous recommandons de créer un nouveau compte de service ne disposant que des rôles et autorisations nécessaires.

Remarque : Auparavant, les utilisateurs de Dataflow pouvaient déployer des applications authentifiées en tant que compte de service Compute Engine par défaut, même s'ils n'avaient pas l'autorisation d'emprunter le compte de service Compute Engine par défaut. Cet ancien comportement affecte toujours certaines organisations. Pour plus d'informations, consultez la section Demander des autorisations d'emprunt d'identité lors de l'association de comptes de service aux ressources.

Spécifier un compte de service de nœud de calcul géré par l'utilisateur

Si vous souhaitez créer et utiliser des ressources avec un contrôle d'accès précis, vous pouvez créer un compte de service géré par l'utilisateur. Utilisez ce compte comme compte de service de nœud de calcul.

1. Si vous ne possédez pas de compte de service géré par l'utilisateur, créez un compte de service.

2. Définissez les rôles IAM requis pour votre compte de service.

   • Pour que le compte de service puisse créer, exécuter et examiner un job, il doit disposer des rôles roles/dataflow.admin et roles/dataflow.worker, ou d'un rôle IAM personnalisé disposant des autorisations requises pour ces rôles. Pour obtenir la liste des autorisations requises, consultez la page Rôles.
   • Il peut également avoir besoin de rôles supplémentaires pour utiliser les ressources Google Cloud requises par votre job, comme BigQuery, Pub/Sub ou Cloud Storage. Par exemple, si la tâche lit les données à partir de BigQuery, votre compte de service doit également être doté du rôle roles/bigquery.dataViewer.
   • Assurez-vous que votre compte de service géré par l'utilisateur dispose d'un accès en lecture et en écriture aux emplacements de préproduction et aux emplacements temporaires spécifiés dans le job Dataflow.
   • Pour emprunter l'identité du compte de service, votre compte utilisateur doit disposer de l'autorisation iam.serviceAccounts.actAs.

3. Attribuez les rôles suivants au compte de service Dataflow (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com) et à l'agent de service de Compute Engine (service-<project-number>@compute-system.iam.gserviceaccount.com). Ces deux comptes sont des comptes de service gérés par Google sur le compte de service géré par l'utilisateur.

   • Rôle Créateur de jetons du compte de service (iam.serviceAccountTokenCreator)
   • Rôle Utilisateur du compte de service (iam.serviceAccountUser)

   Pour obtenir des instructions sur l'attribution de rôles à un compte de service, consultez la section Attribuer un rôle unique de la page "Gérer l'accès aux comptes de service".

4. Lorsque vous exécutez la tâche de pipeline, spécifiez votre compte de service.

   Java

   Utilisez l'option --serviceAccount et spécifiez votre compte de service lorsque vous exécutez le job de pipeline à partir de la ligne de commande : --serviceAccount=my-service-account-name@<project-id>.iam.gserviceaccount.com

   Utilisez l'option --service-account-email et spécifiez votre compte de service lorsque vous exécutez le job de pipeline en tant que modèle Flex : --service-account-email=my-service-account-name@<project-id>.iam.gserviceaccount.com

   Python

   Utilisez l'option --service_account_email et spécifiez votre compte de service lorsque vous exécutez la tâche de pipeline : --service_account_email=my-service-account-name@<project-id>.iam.gserviceaccount.com

   Go

   Utilisez l'option --service_account_email et spécifiez votre compte de service lorsque vous exécutez la tâche de pipeline : --service_account_email=my-service-account-name@<project-id>.iam.gserviceaccount.com

Vous pouvez obtenir la liste des comptes de service associés à votre projet à partir de la page Autorisations de la console Google Cloud.

Le compte de service géré par l'utilisateur peut se trouver dans le même projet que votre tâche ou dans un autre projet. Si le compte de service et la tâche se trouvent dans des projets différents, vous devez configurer le compte de service avant d'exécuter la tâche.

Accéder aux ressources Google Cloud

Vos pipelines Apache Beam peuvent accéder aux ressources Google Cloud dans le même projet Google Cloud ou dans d'autres projets. Voici notamment ce que vous y trouverez :

• Buckets Cloud Storage
• Ensembles de données BigQuery
• Sujets et abonnements Pub/Sub
• Ensembles de données Firestore

Pour vous assurer que le pipeline Apache Beam peut accéder à ces ressources, vous devez utiliser les mécanismes de contrôle d'accès respectifs des ressources, afin d'accorder explicitement l'accès au compte de service de nœud de calcul du projet Dataflow.

Si vous utilisez des fonctionnalités Assured Workloads avec Dataflow (telles que les régions de l'UE et assistance pour les contrôles de souveraineté), tous les connecteurs Cloud Storage, BigQuery, Pub/Sub, E/S et autres ressources auxquels votre pipeline accède doivent être situés dans laprojet ou dossier Assured Workloads.

Si vous utilisez un compte de service de nœud de calcul géré par l'utilisateur ou si vous accédez à des ressources dans d'autres projets, une action supplémentaire peut être nécessaire. Dans les exemples suivants, nous partons du principe que le compte de service Compute Engine par défaut est utilisé, mais vous pouvez également utiliser un compte de service de nœud de calcul géré par l'utilisateur.

Accéder aux buckets Cloud Storage

Pour permettre à votre projet Dataflow d'accéder à un bucket Cloud Storage, rendez-le accessible au compte de service de nœud de calcul de votre projet Dataflow. Vous pouvez accorder l'accès requis à l'aide des contrôles d'accès Cloud Storage.

Remarque : Assurez-vous que les autorisations associées au compte de service de nœud de calcul sont cohérentes avec vos paramètres IAM. En raison de l'incohérence entre les stratégies IAM et LCA le bucket Cloud Storage peut devenir inaccessible pour vos tâches Dataflow lorsque le bucket Cloud Storage est migré d'un accès ultraprécis à un accès uniforme au niveau du bucket. Pour en savoir plus, consultez la section Conseils sur les erreurs fréquentes.

Pour obtenir la liste des comptes de service associés à votre projet Dataflow, consultez la page IAM et administration de la console Google Cloud. Une fois que vous disposez des noms des comptes, vous pouvez exécuter les commandes gsutil pour accorder la propriété des comptes de service du projet (autorisation en lecture/écriture) à la fois au bucket et à ses contenus.

Pour accorder aux comptes de service du projet Dataflow l'accès à un bucket Cloud Storage, exécutez la commande suivante dans la fenêtre de votre shell ou de votre terminal :

gsutil acl ch -u <project-number>[e-mail]:OWNER gs://BUCKET_NAME

Pour permettre aux comptes de service de votre projet Dataflow d'accéder aux contenus existants d'un bucket Cloud Storage, exécutez la commande suivante dans la fenêtre de votre shell ou de votre terminal :

gsutil -m acl ch -r -u <project-number>[e-mail]:OWNER gs://BUCKET_NAME

Remarque : L'option -m exécute la commande en parallèle afin d'accélérer le traitement. L'option -r exécute la commande de manière récursive sur les ressources du bucket.

La commande précédente n'accorde l'accès qu'aux ressources existantes. Si vous accordez aux comptes de service du projet Dataflow l'autorisation par défaut pour le bucket, ils peuvent accéder aux futures ressources ajoutées à celui-ci :

  gsutil defacl ch -u <project-number>[e-mail]:OWNER gs://BUCKET_NAME

Conseil : Vous pouvez également définir des autorisations de bucket à partir de la console Google Cloud. Pour en savoir plus, consultez Définir des autorisations sur un bucket.

Pour savoir si votre projet Google Cloud détient un bucket Cloud Storage spécifique, vous pouvez utiliser la commande de console suivante :

gsutil acl get gs://<your-bucket>

La commande génère une chaîne JSON semblable à celle-ci :

[
  {
    "entity": "project-owners-123456789",
    "projectTeam": {
      "projectNumber": "123456789",
      "team": "owners"
    },
    "role": "OWNER"
  },
  ....
]

Les entrées qui vous intéressent sont celles marquées du rôle "owner" (propriétaire). La valeur projectNumber associée vous indique quel projet est propriétaire de ce bucket. Si ce numéro ne correspond pas à celui de votre projet, vous devez effectuer l'une des opérations suivantes :

• Créer un bucket appartenant à votre projet
• Accorder aux comptes appropriés un accès au bucket

Pour créer un bucket dans le projet Google Cloud avec lequel vous utilisez Cloud Dataflow, utilisez la commande de console suivante :

gsutil mb -p <Project to own the bucket> <bucket-name>

Accéder aux ensembles de données BigQuery

Vous pouvez utiliser l'API BigQueryIO pour accéder aux ensembles de données BigQuery situés dans le même projet que celui dans lequel vous utilisez Dataflow ou dans un autre projet. Pour que la source et le récepteur BigQuery fonctionnent correctement, les deux comptes suivants doivent avoir accès à tous les ensembles de données BigQuery sur lesquels votre tâche Dataflow effectue des opérations de lecture ou d'écriture :

• Compte Google Cloud que vous utilisez pour exécuter la tâche Dataflow.
• Le compte de service de nœud de calcul qui exécute la tâche Dataflow.

Vous devrez peut-être configurer BigQuery pour accorder l'accès de manière explicite à ces comptes. Pour en savoir plus sur l'octroi de l'accès aux ensembles de données BigQuery à l'aide de la page BigQuery ou de l'API BigQuery, consultez la page Contrôle d'accès BigQuery.

Parmi les autorisations BigQuery requises, l'autorisation IAM bigquery.datasets.get est requise par le pipeline pour accéder à un ensemble de données BigQuery. En règle générale, la plupart des rôles IAM BigQuery incluent l'autorisation bigquery.datasets.get, mais le rôle roles/bigquery.jobUser constitue une exception.

Par exemple, si votre compte Google Cloud est [e-mail] et que le numéro du projet sur lequel vous exécutez la tâche Dataflow est 123456789, les comptes suivants doivent tous avoir accès aux ensembles de données BigQuery utilisés : [e-mail] et [e-mail].

Accéder aux sujets et abonnements Pub/Sub

Pour accéder à un sujet ou à un abonnement Pub/Sub, utilisez les fonctionnalités de gestion de l'authentification et des accès de Pub/Sub afin de configurer des autorisations pour le compte de service de nœud de calcul..

Les autorisations des rôles Pub/Sub suivants sont pertinents :

• roles/pubsub.subscriber est obligatoire pour consommer des données.
• roles/pubsub.editor est obligatoire pour créer un abonnement Pub/Sub.
• roles/pubsub.viewer est recommandé, afin que Dataflow puisse interroger les configurations des sujets et des abonnements. Cette configuration présente deux avantages :
  • Dataflow peut vérifier les paramètres non compatibles sur les abonnements susceptibles de ne pas fonctionner comme prévu.
  • Si l'abonnement n'utilise pas le délai de confirmation par défaut de 10 secondes, les performances sont améliorées. Dataflow prolonge de manière répétée le délai de confirmation d'un message pendant son traitement par le pipeline. Sans autorisations pubsub.viewer, Dataflow ne peut pas interroger le délai de confirmation et doit donc supposer un délai par défaut. Cette configuration force Dataflow à émettre plus de requêtes modifyAckDeadline que nécessaire.
  • Si VPC Service Controls est activé sur le projet propriétaire de l'abonnement ou du sujet, les règles d'entrée basées sur les adresses IP ne permettent pas à Dataflow d'interroger les configurations. Dans ce cas, une règle d'entrée basée sur le compte de service du nœud de calcul est requise.

Pour en savoir plus et obtenir des exemples de code illustrant l'utilisation des fonctionnalités de gestion de l'authentification et des accès de Pub/Sub, consultez la page Exemple de cas d'utilisation: communication entre projets.

Accéder à Firestore

Pour accéder à une base de données Firestore (en mode natif ou Datastore), ajoutez votre compte de service de nœud de calcul Dataflow (par exemple, <project-number>[e-mail]) en tant qu'éditeur du projet propriétaire de la base de données, ou utilisez un rôle Datastore plus restrictif, tel que roles/datastore.viewer. Activez également l'API Firestore dans les deux projets à partir de la bibliothèque d'API de Google Cloud Console.

Accéder aux images pour les projets ayant un règlement relatif aux images de confiance

Si vous avez configuré un règlement relatif aux images de confiance pour votre projet et que votre image de démarrage se trouve dans un autre projet, assurez-vous que le règlement relatif aux images de confiance est configuré pour accéder à l'image. Par exemple, si vous exécutez une tâche Dataflow modélisée, assurez-vous que le fichier du règlement inclut l'accès au projet dataflow-service-producer-prod. Ce projet Google Cloud contient les images des modèles de tâches.

Accès aux données et sécurité

Le service Dataflow fonctionne avec deux types de données :

• Données utilisateur final Ces données sont traitées par un pipeline Dataflow. Un pipeline classique lit les données d'une ou de plusieurs sources, met en œuvre les transformations de données et écrit les résultats dans un ou plusieurs récepteurs. Toutes les sources et tous les récepteurs sont des services de stockage qui ne sont pas directement gérés par Dataflow.

• Données opérationnelles. Ces données incluent toutes les métadonnées requises pour la gestion d'un pipeline Dataflow. Ces données incluent à la fois des métadonnées fournies par l'utilisateur, telles que le nom d'une tâche ou des options de pipeline, ainsi que des métadonnées générées par le système, comme un ID de tâche.

Le service Dataflow met en œuvre plusieurs mécanismes de sécurité pour garantir la sécurité et la confidentialité des données. Ces mécanismes s'appliquent aux scénarios suivants :

• Envoyer un pipeline au service
• Évaluer un pipeline
• Demander l'accès à la télémétrie et aux métriques pendant et après l'exécution d'un pipeline
• Utiliser un service Dataflow tel que Shuffle ou Streaming Engine

Localisation des données

Remarque : Nous vous recommandons de toujours spécifier une région lorsque vous exécutez un pipeline. La compatibilité avec les régions par défaut ne sera plus disponible dans une prochaine version.

L'ensemble du traitement des données de base pour le service Dataflow s'effectue dans la région spécifiée dans le code du pipeline. Si aucune région n'est spécifiée, la région par défaut (us-central1) est utilisée. Si vous spécifiez cette option dans le code du pipeline, la tâche de pipeline peut éventuellement lire et écrire des données à partir de sources et de récepteurs d'autres régions. Toutefois, le traitement réel des données ne se produit que dans la région spécifiée pour exécuter les VM Dataflow.

La logique de pipeline est évaluée sur des instances de VM de nœuds de calcul individuelles. Vous pouvez spécifier la zone dans laquelle se trouvent ces instances et le réseau privé sur lequel elles communiquent. Les calculs auxiliaires effectués pour la plate-forme dépendent de métadonnées telles que les emplacements Cloud Storage ou la taille des fichiers.

Dataflow est un service régional. Pour en savoir plus sur la localité des données et les points de terminaison régionaux, consultez la page Points de terminaison régionaux.

Données dans une soumission de pipeline

Les autorisations IAM pour votre projet Google Cloud contrôlent l'accès au service Dataflow. Tous les comptes principaux disposant de droits d'éditeur ou de propriétaire sur votre projet peuvent envoyer des pipelines au service. Pour envoyer des pipelines, vous devez vous authentifier à l'aide de Google Cloud CLI. Une fois que vous êtes authentifié, les pipelines sont envoyés à l'aide du protocole HTTPS. Pour obtenir des instructions concernant l'authentification avec les identifiants de compte Google Cloud, consultez le guide de démarrage rapide correspondant au langage que vous utilisez.

Données dans une évaluation de pipeline

Lors de l'évaluation d'un pipeline, des données temporaires peuvent être générées et stockées localement dans les instances de VM de nœud de calcul ou dans Cloud Storage. Les données temporaires sont chiffrées au repos, et elles ne sont pas persistantes à la fin d'une évaluation. Ces données peuvent également être stockées dans le service Shuffle ou Streaming Engine (si vous avez choisi le service) dans la même région que celle spécifiée dans le pipeline Dataflow.

Java

Par défaut, les VM Compute Engine sont supprimées à la fin de la tâche Dataflow, qu'elle ait réussi ou non. Par conséquent, le disque persistant associé, ainsi que toutes les données intermédiaires qui pourraient y être stockées, sont supprimés. Les données intermédiaires stockées dans Cloud Storage sont disponibles dans des sous-emplacements du chemin Cloud Storage que vous indiquez en tant que --stagingLocation et/ou --tempLocation. Si vous écrivez une sortie dans un fichier Cloud Storage, des fichiers temporaires peuvent être créés dans l'emplacement de sortie avant que l'opération d'écriture ne soit finalisée.

Python

Par défaut, les VM Compute Engine sont supprimées à la fin de la tâche Dataflow, qu'elle ait réussi ou non. Par conséquent, le disque persistant associé, ainsi que toutes les données intermédiaires qui pourraient y être stockées, sont supprimés. Les données intermédiaires stockées dans Cloud Storage sont disponibles dans des sous-emplacements du chemin Cloud Storage que vous indiquez en tant que --staging_location et/ou --temp_location. Si vous écrivez une sortie dans un fichier Cloud Storage, des fichiers temporaires peuvent être créés dans l'emplacement de sortie avant que l'opération d'écriture ne soit finalisée.

Go

Par défaut, les VM Compute Engine sont supprimées à la fin de la tâche Dataflow, qu'elle ait réussi ou non. Par conséquent, le disque persistant associé, ainsi que toutes les données intermédiaires qui pourraient y être stockées, sont supprimés. Les données intermédiaires stockées dans Cloud Storage sont disponibles dans des sous-emplacements du chemin Cloud Storage que vous indiquez en tant que --staging_location et/ou --temp_location. Si vous écrivez une sortie dans un fichier Cloud Storage, des fichiers temporaires peuvent être créés dans l'emplacement de sortie avant que l'opération d'écriture ne soit finalisée.

Données dans les journaux de pipeline et la télémétrie

Les informations stockées dans Cloud Logging sont principalement générées par le code de votre programme Dataflow. Le service Dataflow peut également générer des données d'avertissement et d'erreur dans Cloud Logging, mais il s'agit des seules données intermédiaires que le service ajoute aux journaux. Cloud Logging est un service global.

Les données de télémétrie et les métriques associées sont chiffrées au repos, et l'accès à ces données est contrôlé par les autorisations de lecture de votre projet Google Cloud.

Données dans les services Dataflow

Si vous utilisez Dataflow Shuffle ou Dataflow Streaming pour votre pipeline, ne spécifiez pas les options du pipeline de zone. Au lieu de cela, spécifiez la région et définissez la valeur sur l'une des régions dans lesquelles Shuffle ou Streaming est actuellement disponible. Dataflow sélectionne automatiquement la zone dans la région spécifiée. Les données de l'utilisateur final en transit restent dans les VM de nœud de calcul et dans la même zone. Ces tâches Dataflow peuvent toujours lire et écrire dans des sources et des récepteurs situés en dehors de la zone de la VM. Les données en transit peuvent également être envoyées aux services Dataflow Shuffle ou Dataflow Streaming, mais les données restent toujours dans la région spécifiée dans le code du pipeline.

Pratique recommandée

Nous vous recommandons d'utiliser les mécanismes de sécurité disponibles dans les ressources cloud sous-jacentes de votre pipeline. Ces mécanismes incluent les fonctionnalités de sécurité des données de sources et de récepteurs de données tels que BigQuery et Cloud Storage. Il est également préférable de ne pas mélanger différents niveaux de confiance dans un même projet.