Sécurité et autorisations pour Dataflow

Vous pouvez exécuter des pipelines Dataflow en local ou sur des ressources Google Cloudgérées à l'aide de l'exécuteur 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
  • 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 deGoogle Cloud . Ces identifiants incluent le nom, l'ID du projet et le numéro du projet.

Mettre à niveau et appliquer des correctifs sur des VM Dataflow

Dataflow utilise Container-Optimized OS. Les processus de sécurité de Container-Optimized OS s'appliquent donc également à Dataflow. Pour en savoir plus sur la manière dont Google sécurise et renforce ces VM, consultez Sécurité et renforcement des VM de nœud de calcul.

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 en informe à l'aide de bulletins de sécurité. Pour les pipelines de streaming, nous vous recommandons d'utiliser l'option --update pour redémarrer votre job avec la dernière image Dataflow.

Les images de conteneurs Dataflow sont disponibles dans la consoleGoogle Cloud .

Sécurité des images de conteneurs

Dataflow utilise des images de conteneurs pour l'environnement d'exécution du code utilisateur du pipeline. Par défaut, une image Apache Beam prédéfinie est utilisée. Vous pouvez également fournir un conteneur personnalisé.

Google renforce et corrige le système d'exploitation des images de base utilisées par les images appartenant à Dataflow. Google effectue rapidement n'importe quel correctif pour ces images disponibles. Toutes les ressources de production Dataflow, y compris les images Beam fournies par défaut, sont automatiquement et régulièrement analysées pour détecter d'éventuelles failles. Tous les problèmes identifiés dans les conteneurs appartenant à Google sont traités conformément à un objectif de niveau de service (SLO) défini. Les problèmes liés aux conteneurs Beam sont traités par la communauté Beam. Dans le cadre du modèle de responsabilité partagée de Dataflow, nous vous recommandons d'utiliser des images de conteneurs personnalisées pour gérer les problèmes de sécurité de manière réactive.

Bien que les images Container-Optimized OS utilisées par Dataflow soient conformes au niveau 1 du CIS, la conformité globale est une responsabilité partagée. Les instances de VM sur lesquelles ces conteneurs s'exécutent résident dans le projet du client. Les clients sont responsables de l'analyse de leurs propres ressources de projet. Vous pouvez utiliser Security Command Center pour analyser vos ressources afin de détecter les problèmes de conformité et les failles.

Environnement d'exécution

Pour l'environnement d'exécution du code utilisateur du pipeline, Dataflow utilise une image Apache Beam prédéfinie ou un conteneur personnalisé, le cas échéant.

L'utilisateur pour l'exécution du conteneur est sélectionné par le service Dataflow. Dataflow ne vous permet pas d'exécuter des images de conteneur de SDK personnalisées ni des images de conteneur de modèles personnalisés pour les modèles Flex en tant qu'utilisateur non racine.

Contrairement à d'autres environnements (comme Google Kubernetes Engine (GKE)) où les conteneurs s'exécutent sur des nœuds partagés, les VM de nœud de calcul Dataflow ne sont pas partagées entre les pipelines. Les ressources de pipeline sont allouées par job. Il n'y a pas de partage de VM ni d'autres ressources entre les pipelines.

Le cycle de vie de l'environnement d'exécution est lié à celui du pipeline. Il est démarré au début du pipeline et arrêté à la fin du pipeline. L'environnement d'exécution peut être redémarré une ou plusieurs fois pendant l'exécution du pipeline.

Sécurité et autorisations pour les pipelines locaux

En local, le pipeline Apache Beam est exécuté avec le compteGoogle Cloud que vous avez configuré à l'aide de l'exécutable de Google Cloud CLI. Les opérations du SDK Apache Beam exécutées localement et votre compte Google Cloudont 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.

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 les identifiants de votre 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 votre compte Google Cloud , consultez le tutoriel correspondant au langage que vous utilisez : Java, Python ou Go.

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 job (par exemple, pour vérifier le quota des projets et créer des instances de nœuds de calcul en votre nom). Dataflow utilise également le compte de service Dataflow lors de l'exécution du job pour gérer celui-ci. 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 de 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 par défaut Compute Engine associé à votre projet en tant que compte de service de nœud de calcul. Nous vous recommandons de spécifier un compte de service géré par l'utilisateur au lieu d'utiliser le compte de service de nœud de calcul par défaut.

Pour emprunter l'identité du compte de service lorsque vous exécutez un pipeline, le compte qui lance le pipeline doit disposer de l'autorisation iam.serviceAccounts.actAs. Cette autorisation est incluse dans le rôle Utilisateur du compte de service (roles/iam.serviceAccountUser). Emprunter l'identité d'un compte de service vous permet d'adopter temporairement son identité et ses autorisations pour effectuer des tâches nécessitant différents niveaux d'accès, tout en évitant les risques associés aux clés persistantes. Pour en savoir plus, consultez Utiliser l'emprunt d'identité d'un compte de service.

En fonction des autres autorisations du projet, votre compte utilisateur peut également avoir besoin du rôle roles/dataflow.developer. Si vous êtes propriétaire du projet ou éditeur, vous disposez déjà des autorisations contenues dans le rôle roles/dataflow.developer.

Bonnes pratiques

  • Si possible, pour le compte de service de nœud de calcul, spécifiez un compte de service géré par l'utilisateur au lieu d'utiliser le compte de service de nœud de calcul par défaut.
  • Lorsque vous accordez des autorisations sur les ressources, attribuez le rôle contenant les autorisations minimales requises pour la tâche. Vous pouvez créer un rôle personnalisé qui n'inclut que les autorisations requises.
  • Lorsque vous attribuez des rôles pour accéder aux ressources, utilisez le niveau de ressource le plus bas possible. Par exemple, au lieu d'attribuer le rôle roles/bigquery.dataEditor sur un projet ou un dossier, accordez-le sur la table BigQuery.
  • 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 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.

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 de pipelines Dataflow, Dataflow manipule les ressources en votre nom. (par exemple, en créant des VM supplémentaires). Lorsque vous exécutez votre pipeline avec Dataflow, ce compte de service est utilisé.

Ce compte se voit attribuer le rôle d'agent de service Dataflow sur le projet. Il dispose des autorisations nécessaires pour exécuter un job Dataflow dans le projet, y compris pour démarrer des nœuds de calcul Compute Engine. Ce compte est utilisé exclusivement par Dataflow et est propre à votre projet.

Vous pouvez examiner les rôles attribués au compte de service Dataflow dans la consoleGoogle Cloud ou dans la Google Cloud CLI.

Console

  1. Accéder à la page Rôles

    Accéder à la page "Rôles"

  2. Si nécessaire, sélectionnez votre projet.

  3. Dans la liste, cliquez sur le titre Agent de service Cloud Dataflow. Une page contenant la liste des autorisations attribuées au compte de service Dataflow s'affiche.

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 pour le compte de service de la stratégie IAM (Identity and Access Management), le compte reste présent, car il appartient au service Dataflow.

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és au pipeline. Le compte de service de 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 de 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 de nœud de calcul puisse exécuter un job, il doit disposer du rôle roles/dataflow.worker.
  • Pour que le compte de service du nœud de calcul puisse créer ou examiner un job, il doit disposer du rôle roles/dataflow.admin.

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 du job Dataflow. Par exemple, si le job écrit dans BigQuery, votre compte de service doit également être doté du rôle roles/bigquery.dataEditor sur la table BigQuery. Voici quelques exemples de ressources :

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

Par défaut, les nœuds de calcul utilisent le compte de service par défaut Compute Engine 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-compute@

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 .

Bien que vous puissiez utiliser le compte de service Compute Engine par défaut en tant que compte de service de nœud de calcul Dataflow, nous vous recommandons de créer un compte de service de nœud de calcul Dataflow dédié, qui ne dispose que des rôles et autorisations dont vous avez besoin.

Selon la configuration de vos règles d'administration, le compte de service par défaut peut se voir attribuer automatiquement le rôle Éditeur sur votre projet. Nous vous recommandons vivement de désactiver l'attribution automatique des rôles en appliquant la contrainte de règle d'administration iam.automaticIamGrantsForDefaultServiceAccounts. Si vous avez créé votre organisation après le 3 mai 2024, cette contrainte est appliquée par défaut.

Si vous désactivez l'attribution automatique de rôles, vous devez choisir les rôles à attribuer aux comptes de service par défaut, puis attribuer ces rôles vous-même.

Si le compte de service par défaut dispose déjà du rôle Éditeur, nous vous recommandons de le remplacer par des rôles moins permissifs.

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 contrôle des accès ultrapré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 encore de compte de service géré par l'utilisateur, créez-en un.

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

    • Pour que le compte de service de nœud de calcul puisse exécuter un job, il doit disposer du rôle roles/dataflow.worker.
    • Pour que le compte de service du nœud de calcul puisse créer ou examiner un job, il doit disposer du rôle roles/dataflow.admin.
    • Vous pouvez également créer un rôle IAM personnalisé avec les autorisations requises. Pour obtenir la liste des autorisations requises, consultez la page Rôles.

  3. Votre compte de service peut également avoir besoin de rôles supplémentaires pour utiliser les ressources Google Cloudrequises par votre job, comme BigQuery, Pub/Sub ou Cloud Storage. Par exemple, si le job lit les données à partir de BigQuery, votre compte de service doit également être doté du rôle roles/bigquery.dataViewer sur la table BigQuery.

  4. 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.

  5. Pour lancer le pipeline, votre compte utilisateur doit disposer de l'autorisation iam.serviceAccounts.actAs pour emprunter l'identité du compte de service du nœud de calcul.

  6. Dans le projet contenant le compte de service de nœud de calcul géré par l'utilisateur, le compte de service Dataflow (service-PROJECT_NUMBER@dataflow-service-producer-prod.) et le service Compute Engine Agent (service-PROJECT_NUMBER@compute-system.) doivent disposer des rôles suivants. PROJECT_NUMBER est l'ID du projet dans lequel votre tâche Dataflow s'exécute. Ces deux comptes sont des agents de service.

    Supposons que le job Dataflow s'exécute dans le projet A et que le compte de service de nœud de calcul est hébergé dans le projet B. Assurez-vous que les agents de service du projet A disposent des rôles iam.serviceAccountTokenCreator et iam.serviceAccountUser dans le projet B. Dans le projet dans lequel votre job Dataflow s'exécute, les comptes disposent de ces rôles par défaut. Pour attribuer ces rôles, suivez les étapes de la section Attribuer un rôle unique de la page "Gérer l'accès aux comptes de service".

  7. Lorsque le compte de service de nœud de calcul géré par l'utilisateur et le job se trouvent dans des projets différents, assurez-vous que la contrainte booléenne iam.disableCrossProjectServiceAccountUsage n'est pas appliquée au projet propriétaire du compte de service géré par l'utilisateur. Pour en savoir plus, consultez Activer l'association des comptes de service à plusieurs projets.

  8. 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=SERVICE_ACCOUNT_NAME@PROJECT_ID.

    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=SERVICE_ACCOUNT_NAME@PROJECT_ID.

    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=SERVICE_ACCOUNT_NAME@PROJECT_ID.

    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=SERVICE_ACCOUNT_NAME@PROJECT_ID.

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.

Afficher le compte de service de nœud de calcul d'un job

Pour un job existant, l'adresse e-mail du compte de service de nœud de calcul est stockée dans le champ environment.serviceAccountEmail (environment.service_account_email dans les bibliothèques clientes et RPC) de la ressource Job.

Pour récupérer l'objet environment et serviceAccountEmail, vous devez demander la vue de job JOB_VIEW_DESCRIPTION ou JOB_VIEW_ALL lors de l'obtention d'un job. Les requêtes qui utilisent JOB_VIEW_SUMMARY, y compris projects.locations.jobs.list et les requêtes récapitulatives par défaut, omettent environment.serviceAccountEmail.

Les appels d'API en lecture seule pour inspecter les métadonnées de job, tels que projects.locations.jobs.get, n'entraînent pas de frais par requête. Les appels d'API sont soumis aux quotas d'API et de surveillance standards, tandis que les frais Dataflow s'appliquent aux ressources de calcul, de stockage et de traitement des données du pipeline. Pour en savoir plus, consultez la page Tarifs.

Console

  1. Dans la console Google Cloud , accédez à la page Dataflow > Jobs (Jobs).

    Accéder aux tâches

  2. Cliquez sur le nom du job que vous souhaitez inspecter.

  3. Sur la page Informations sur le job, dans le panneau latéral Informations sur le job, cliquez sur REST à côté de Équivalent en bas du panneau.

  4. Dans la boîte de dialogue Réponse REST équivalente, recherchez le champ serviceAccountEmail dans l'objet environment.

    Si vous avez spécifié un compte de service géré par l'utilisateur lors du lancement du job, vous pouvez également trouver l'adresse e-mail du compte de service dans le champ service_account_email de la section Options de pipeline du panneau Informations sur le job.

gcloud CLI

Pour récupérer l'adresse e-mail du compte de service de nœud de calcul d'un job, exécutez la commande gcloud dataflow jobs describe avec l'option --full :

gcloud dataflow jobs describe JOB_ID \
    --region=REGION \
    --project=PROJECT_ID \
    --full \
    --format="value(environment.serviceAccountEmail)"

Remplacez les éléments suivants :

  • JOB_ID : ID du job Dataflow
  • REGION : région dans laquelle le job est exécuté, par exemple us-central1
  • PROJECT_ID : ID du projet contenant le job

REST

Pour récupérer les métadonnées de l'environnement d'exécution d'un job et l'adresse e-mail du compte de service de nœud de calcul, envoyez une requête GET à la méthode projects.locations.jobs.get et définissez le paramètre de requête view sur JOB_VIEW_DESCRIPTION ou JOB_VIEW_ALL :

curl -X GET \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?view=JOB_VIEW_DESCRIPTION"

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet contenant le job
  • REGION : région dans laquelle le job est exécuté, par exemple us-central1
  • JOB_ID : ID du job Dataflow

La réponse est une ressource Job qui inclut l'adresse e-mail du compte de service de nœud de calcul dans environment.serviceAccountEmail :

{
  "id": "JOB_ID",
  "projectId": "PROJECT_ID",
  "name": "JOB_NAME",
  "environment": {
    "serviceAccountEmail": "SERVICE_ACCOUNT_EMAIL"
  }
}

Python

Utilisez la bibliothèque cliente Dataflow pour Python pour appeler get_job avec JobView.JOB_VIEW_DESCRIPTION et lire job.environment.service_account_email :

from google.cloud import dataflow_v1beta3

client = dataflow_v1beta3.JobsV1Beta3Client()
request = dataflow_v1beta3.GetJobRequest(
    project_id="PROJECT_ID",
    location="REGION",
    job_id="JOB_ID",
    view=dataflow_v1beta3.JobView.JOB_VIEW_DESCRIPTION,
)
job = client.get_job(request=request)
print(job.environment.service_account_email)

Pour inspecter tous les jobs d'une région, appelez list_jobs pour lister les ID de job, puis appelez get_job avec JobView.JOB_VIEW_DESCRIPTION pour chaque job.

Java

Utilisez la bibliothèque cliente Dataflow pour Java pour appeler getJob avec JobView.JOB_VIEW_DESCRIPTION et lire job.getEnvironment().getServiceAccountEmail() :

import com.google.dataflow.v1beta3.GetJobRequest;
import com.google.dataflow.v1beta3.Job;
import com.google.dataflow.v1beta3.JobView;
import com.google.dataflow.v1beta3.JobsV1Beta3Client;

try (JobsV1Beta3Client jobsClient = JobsV1Beta3Client.create()) {
  GetJobRequest request =
      GetJobRequest.newBuilder()
          .setProjectId("PROJECT_ID")
          .setLocation("REGION")
          .setJobId("JOB_ID")
          .setView(JobView.JOB_VIEW_DESCRIPTION)
          .build();
  Job job = jobsClient.getJob(request);
  System.out.println(job.getEnvironment().getServiceAccountEmail());
}

Go

Utilisez la bibliothèque cliente Dataflow pour Go pour appeler GetJob avec JobView_JOB_VIEW_DESCRIPTION et lire job.GetEnvironment().GetServiceAccountEmail() :

import (
        "context"

        dataflow "cloud.google.com/go/dataflow/apiv1beta3"
        dataflowpb "cloud.google.com/go/dataflow/apiv1beta3/dataflowpb"
)

ctx := context.Background()
client, err := dataflow.NewJobsV1Beta3Client(ctx)
if err != nil {
        // Handle error.
}
defer client.Close()

req := &dataflowpb.GetJobRequest{
        ProjectId: "PROJECT_ID",
        Location:  "REGION",
        JobId:     "JOB_ID",
        View:      dataflowpb.JobView_JOB_VIEW_DESCRIPTION,
}
job, err := client.GetJob(ctx, req)
if err != nil {
        // Handle error.
}
serviceAccountEmail := job.GetEnvironment().GetServiceAccountEmail()
_ = serviceAccountEmail

Pour obtenir des exemples complets de bibliothèques clientes dans d'autres langages, consultez les exemples de code GetJob.

Ajouter des rôles

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

Console

  1. Dans la console Google Cloud , 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 votre compte de service de nœud de calcul, 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. Si votre compte de service de nœud de calcul nécessite le rôle d'administrateur Dataflow, répétez cette opération pour l'administrateur Dataflow.

  8. Répétez l'opération pour 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 du projet.
    • Remplacez EMAIL_ADDRESS par l'adresse e-mail du compte utilisateur.

  2. Attribuez des rôles à votre compte de service de nœud de calcul. Exécutez la commande suivante pour le rôle IAM roles/dataflow.worker et pour tous les rôles requis par les ressources utilisées dans votre tâche. Si votre compte de service de nœud de calcul nécessite le rôle Administrateur Dataflow, répétez cette opération pour le rôle IAM roles/dataflow.admin. Cet exemple utilise le compte de service Compute Engine par défaut, mais nous vous recommandons d'employer un compte de service géré par l'utilisateur.

    gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:PROJECT_NUMBER-compute@" --role=SERVICE_ACCOUNT_ROLE
    • Remplacez PROJECT_ID par l'ID du 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.

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 :

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 dépôts Artifact Registry

Lorsque vous utilisez des conteneurs personnalisés avec Dataflow, vous pouvez importer des artefacts dans un dépôt Artifact Registry.

Pour utiliser Artifact Registry avec Dataflow, vous devez accorder au moins l'accès Rédacteur Artifact Registry (role/artifactregistry.writer) au compte de service de nœud de calcul qui exécute le job Dataflow.

L'ensemble du contenu du dépôt est chiffré à l'aide de clés de chiffrement gérées par le client ou par Google-owned and Google-managed encryption keys . Artifact Registry utiliseGoogle-owned and Google-managed encryption keys par défaut, et aucune configuration n'est requise pour cette option.

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. Votre compte de service doit au minimum disposer d'autorisations de lecture et d'écriture sur le bucket et ses contenus. Vous pouvez utiliser les autorisations IAM pour Cloud Storage afin d'accorder l'accès requis.

Pour accorder à votre compte de service de nœud de calcul les autorisations nécessaires pour lire et écrire dans un bucket, utilisez la commande gcloud storage buckets add-iam-policy-binding. Cette commande ajoute le compte de service de votre projet Dataflow à une stratégie au niveau du bucket.

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:PROJECT_NUMBER-compute@" --role=SERVICE_ACCOUNT_ROLE

Remplacez les éléments suivants :

  • BUCKET_NAME : nom de votre bucket Cloud Storage
  • PROJECT_NUMBER : numéro de votre projet Dataflow. Pour trouver votre numéro de projet, consultez la section Identifier des projets ou utilisez la commande gcloud projects describe.
  • SERVICE_ACCOUNT_ROLE: rôle IAM, par exemple storage.objectViewer

Pour récupérer la liste des buckets Cloud Storage d'un projetGoogle Cloud , utilisez la commande gcloud storage buckets list :

gcloud storage buckets list --project= PROJECT_ID

Remplacez PROJECT_ID par l'ID du projet.

Sauf si vous êtes limité par des règles d'administration qui limitent le partage des ressources, vous pouvez accéder à un bucket qui se trouve dans un projet différent de celui de votre pipeline Dataflow. Pour en savoir plus sur les restrictions de domaine, consultez la page Restreindre les identités par domaine.

Si vous n'avez pas de bucket, créez-en un. Accordez ensuite à votre compte de service de nœud de calcul les autorisations nécessaires pour lire et écrire dans le bucket.

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

Cloud Storage propose deux systèmes pour autoriser des utilisateurs à accéder à vos buckets et objets : IAM et les listes de contrôle d'accès (LCA). Dans la plupart des cas, IAM est la méthode recommandée pour contrôler l'accès à vos ressources.

  • IAM contrôle les autorisations dansGoogle Cloud et vous permet d'accorder des autorisations au niveau du bucket et du projet. Pour obtenir la liste des rôles IAM associés à Cloud Storage et des autorisations contenues dans chaque rôle, consultez la page Rôles IAM pour Cloud Storage. Si vous souhaitez contrôler davantage les autorisations, créez un rôle personnalisé.

  • Si vous utilisez des LCA pour contrôler l'accès, 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.

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 :

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.

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. Ainsi, Dataflow émet 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 Identity and Access Management de Pub/Sub, consultez la section Exemple de cas d'utilisation : communication entre projets.

Accéder à Firestore

Pour accéder à une base de données Firestore (en mode natif ou mode Datastore), ajoutez votre compte de service de nœud de calcul Dataflow (par exemple, PROJECT_NUMBER-compute@) 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 la console Google Cloud .

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 jobs.

Accéder aux modèles fournis par Google avec des stratégies de limite d'accès des comptes principaux

Si votre organisation utilise des règles de limite d'accès des principaux (PAB), les principaux (tels que les utilisateurs ou les comptes de service) peuvent être empêchés d'afficher et d'exécuter des modèles fournis par Google. Dans ce cas, essayez l'une des solutions suivantes :

  • Mettez à jour la stratégie de limite d'accès des comptes principaux pour autoriser l'accès au projet géré par Google qui héberge les modèles fournis par Google. Ajoutez le projet dataflow-templates (ou le numéro de projet 473832897378) à la stratégie de limite d'accès des comptes principaux en tant que ressource autorisée :

    //cloudresourcemanager.googleapis.com/projects/dataflow-templates

    Pour savoir comment mettre à jour les stratégies de limite d'accès des comptes principaux, consultez Modifier les stratégies de limite d'accès des comptes principaux.

  • Excluez des comptes principaux spécifiques dans la liaison de stratégie. Si seuls des comptes utilisateur ou des comptes de service spécifiques doivent exécuter des modèles fournis par Google, utilisez des expressions de condition dans la liaison de stratégie de limite d'accès des comptes principaux pour exempter ces comptes principaux de la stratégie.

  • Exécutez le modèle à partir de votre propre projet. Utilisez le code du modèle Open Source du dépôt GitHub DataflowTemplates pour créer et déployer le modèle dans votre propre projet. Pour obtenir un exemple, consultez Créer et exécuter un exemple de modèle Flex.

Pour connaître les symptômes d'un problème de stratégie de limite d'accès des comptes principaux, consultez Erreur lors du chargement de la liste des modèles dans la console Google Cloud et Autorisation refusée lors du chargement d'un fichier de modèle dans la documentation de dépannage des modèles.

Bonnes pratiques de sécurité pour Dataflow

La sécurisation d'un pipeline Dataflow nécessite de protéger les données aux trois niveaux principaux suivants :

  1. Sécurité du réseau et de l'infrastructure
  2. Identity and Access Management (IAM)
  3. Protection et chiffrement des données

Dataflow s'exécute sur des machines virtuelles (nœuds de calcul) gérées et à autoscaling. Par conséquent, configurer correctement ces éléments permet de s'assurer que vos données ne sont pas exposées et restent sécurisées pendant le traitement.

Sécurité du réseau et de l'infrastructure

Par défaut, les nœuds de calcul Dataflow se voient attribuer des adresses IP publiques pour accéder à Internet et aux API Google. Dans un environnement sécurisé, vous devez restreindre cet accès.

  • Désactiver les adresses IP publiques : exécutez vos nœuds de calcul Dataflow sans adresse IP publique en transmettant le paramètre --usePublicIps=false.
  • Configurer l'accès privé à Google : lorsque les adresses IP publiques sont désactivées, vos nœuds de calcul doivent toujours communiquer avec les API Google (telles que Cloud Storage, BigQuery ou Pub/Sub). Activez l'accès privé à Google sur votre sous-réseau VPC afin que les nœuds de calcul puissent acheminer le trafic vers les services Google en interne.
  • Utiliser des VPC partagés et VPC Service Controls (VPC-SC) :
    • Placez vos pipelines Dataflow dans un périmètre de sécurité à l'aide de VPC Service Controls. Cela réduit les risques d'exfiltration de données en garantissant que les données ne peuvent pas être copiées vers des ressources situées en dehors du périmètre, même par des utilisateurs disposant d'identifiants valides.
    • Utilisez des sous-réseaux dédiés avec des règles de pare-feu strictes, en n'autorisant le trafic que vers les ressources nécessaires (comme votre base de données ou votre cluster Kafka) et en désactivant explicitement SSH.

IAM

Le principe du moindre privilège est essentiel. Par défaut, Dataflow tente d'utiliser le compte de service Compute Engine par défaut, qui dispose souvent d'autorisations d'éditeur étendues.

  • Utilisez un compte de service de nœud de calcul géré par l'utilisateur : créez un compte de service dédié non privilégié spécifiquement pour vos nœuds de calcul Dataflow et transmettez-le lors de l'envoi du pipeline. Exemple :

    --serviceAccount=YOUR_SERVICE_ACCOUNT@YOUR_PROJECT_ID.

    Une fois le compte de service créé, n'attribuez-lui que des rôles minimaux :

    • Le compte de service de nœud de calcul doit disposer du rôle roles/dataflow.worker.
    • N'accordez qu'un accès en lecture ou en écriture spécifique aux ressources exactes auxquelles le pipeline accède. Par exemple, accordez le rôle roles/storage.objectViewer sur votre bucket Cloud Storage d'entrée et le rôle roles/bigquery.dataEditor sur votre table BigQuery cible spécifique (plutôt que des rôles à l'échelle du projet).

  • Séparer les autorisations du contrôleur et du nœud de calcul : le développeur ou le pipeline CI/CD qui envoie le job a besoin des autorisations roles/dataflow.admin et roles/iam.serviceAccountUser (ou iam.serviceAccounts.actAs) pour déclencher le pipeline. Toutefois, les VM de nœud de calcul réelles n'ont besoin que d'autorisations d'exécution (roles/dataflow.worker).

Protection et chiffrement des données

Bien que Google Cloud chiffre par défaut toutes les données en transit et au repos, les secteurs hautement réglementés nécessitent souvent un contrôle supplémentaire sur les clés de chiffrement.

  • Implémenter des clés de chiffrement gérées par le client (CMEK) : utilisez Cloud Key Management Service pour générer et gérer vos propres clés. Transmettez votre clé à Dataflow à l'aide de l'option --dataflowKmsKey. Dataflow utilise cette clé pour chiffrer :
    • Disques persistants associés aux VM de nœud de calcul.
    • Données d'état de brassage pour les pipelines de traitement par lot.
    • État de Streaming Engine pour les pipelines de streaming.
  • Sécurisez vos secrets : ne codez jamais en dur les mots de passe, les clés API ou les identifiants de base de données dans votre code Apache Beam ou vos options de pipeline. Accédez-y de manière dynamique pendant les phases Setup ou StartBundle de votre pipeline à l'aide de Secret Manager.
  • Déployez des files d'attente de lettres mortes (DLQ) : évitez de consigner des éléments bruts non analysés lorsqu'une erreur se produit, car ils peuvent contenir des informations permettant d'identifier personnellement l'utilisateur ou des secrets. Au lieu de cela, interceptez les exceptions de traitement et acheminez les éléments défaillants vers un bucket Cloud Storage ou un sujet Pub/Sub "lettre morte" chiffré pour une inspection isolée et sécurisée.

Analyse du code et des failles du pipeline

La sécurité s'applique également à la chaîne d'approvisionnement logicielle de votre code Apache Beam.

  • Analyse des images de conteneurs : si vous utilisez des images de conteneurs personnalisées pour vos nœuds de calcul Dataflow (à l'aide de l'option --sdkContainerImage), stockez-les dans Artifact Registry et activez l'analyse automatique des failles.
  • Maintenez les images à jour : pour les pipelines de streaming qui s'exécutent en continu, mettez régulièrement à jour votre pipeline pour utiliser les dernières versions du SDK Apache Beam. Google renforce et corrige régulièrement les images de base du système d'exploitation sous-jacent utilisées par Dataflow.

Checklist de sécurité rapide

Utilisez le tableau suivant pour identifier un objectif de sécurité et comment l'atteindre.

Objectif Paramètre ou outil de sécurité Objectif
Propriété de la clé --dataflowKmsKey Chiffre l'état du pipeline et les disques des nœuds de calcul à l'aide de Cloud KMS.
Accès de moindre privilège --serviceAccount Exécute les nœuds de calcul sous une identité restreinte.
Aucune exposition à Internet --usePublicIps=false Empêche l'attribution d'adresses IP publiques aux nœuds de calcul.
Empêcher l'exfiltration VPC Service Controls (VPC-SC) Limitez le déplacement des données en dehors de votre limite de confiance.
Accès sécurisé à l'API Accès privé à Google Permet aux nœuds de calcul d'accéder à Cloud Storage et à BigQuery de manière privée.
Sécuriser les identifiants Secret Manager Extrait dynamiquement les mots de passe et les clés au moment de l'exécution.
Sécuriser des buckets Cloud Storage Autorisations de moindre privilège Limitez les autorisations sur les buckets Cloud Storage utilisés par Dataflow.

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 les métadonnées fournies par l'utilisateur, telles qu'un nom de job ou des options de pipeline, et les métadonnées générées par le système, telles qu'un ID de job.

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

Tout le traitement des données de base pour 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, le job de pipeline peut éventuellement lire et écrire à partir de sources et de récepteurs situés dans 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 où 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 localisation et les régions des données, consultez la page Régions Dataflow.

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 la 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 votre 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 opté pour ce 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 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 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 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 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. Toutefois, les données restent toujours dans la région spécifiée dans le code du pipeline.

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.