Sicurezza e autorizzazioni di Dataflow

Puoi eseguire le pipeline Dataflow in locale o su risorse Google Cloud gestite utilizzando il runner Dataflow. Sia che le pipeline vengano eseguite localmente o nel cloud, la pipeline e i relativi worker utilizzano un sistema di autorizzazioni per mantenere l'accesso sicuro ai file e alle risorse della pipeline. Le autorizzazioni Dataflow vengono assegnate in base al ruolo utilizzato per accedere alle risorse della pipeline. Questo documento spiega i seguenti concetti:

  • Upgrade delle VM Dataflow
  • Ruoli e autorizzazioni richiesti per l'esecuzione di pipeline locali e Google Cloud
  • Ruoli e autorizzazioni richiesti per accedere alle risorse della pipeline
  • Tipi di dati utilizzati in un servizio Dataflow e nella sicurezza dei dati

Prima di iniziare

Scopri di più sugli identificatori di progetto Google Cloud nella panoramica diGoogle Cloud . Questi identificatori includono il nome, l'ID progetto e il numero del progetto.

Esegui l'upgrade e applica patch alle VM Dataflow

Dataflow utilizza Container-Optimized OS. I processi di sicurezza di Container-Optimized OS si applicano anche a Dataflow. Per ulteriori dettagli su come Google protegge e rafforza queste VM, consulta Sicurezza e protezione delle VM worker.

Le pipeline batch sono limitate nel tempo e non richiedono manutenzione. Quando viene avviata una nuova pipeline batch, viene utilizzata l'immagine Dataflow più recente.

Per le pipeline di streaming, se è necessaria immediatamente una patch di sicurezza, Google Cloud ti invia una notifica utilizzando i bollettini di sicurezza. Per le pipeline di streaming, ti consigliamo di utilizzare l'opzione --update per riavviare il job con l'immagine Dataflow più recente.

Le immagini container di Dataflow sono disponibili nella consoleGoogle Cloud .

Sicurezza delle immagini container

Dataflow utilizza immagini container per l'ambiente di runtime del codice utente della pipeline. Per impostazione predefinita, viene utilizzata un'immagine Apache Beam predefinita. Puoi anche fornire un container personalizzato.

Google rafforza e applica patch al sistema operativo delle immagini di base utilizzate dalle immagini di proprietà di Dataflow. Google rende immediatamente disponibili eventuali patch per queste immagini. Tutte le risorse di produzione di Dataflow, incluse le immagini Beam fornite per impostazione predefinita, vengono analizzate automaticamente e regolarmente per rilevare eventuali vulnerabilità. Eventuali problemi identificati nei container di proprietà di Google vengono risolti in base a un obiettivo del livello di servizio (SLO) definito. I problemi nei container Beam vengono risolti dalla community di Beam. Nell'ambito del modello di responsabilità condivisa di Dataflow, per gestire i problemi di sicurezza in modo reattivo, ti consigliamo di utilizzare immagini container personalizzate.

Sebbene le immagini Container-Optimized OS utilizzate da Dataflow siano conformi al livello 1 di CIS, il raggiungimento della conformità complessiva è una responsabilità condivisa. Le istanze VM su cui vengono eseguiti questi container si trovano all'interno del progetto del cliente. I clienti sono responsabili della scansione delle proprie risorse di progetto. Puoi utilizzare Security Command Center per analizzare le tue risorse alla ricerca di vulnerabilità e conformità.

Ambiente di runtime

Per l'ambiente di runtime del codice utente della pipeline, Dataflow utilizza un'immagine Apache Beam predefinita o un container personalizzato, se ne è stato fornito uno.

L'utente per l'esecuzione del container viene selezionato dal servizio Dataflow. Dataflow non consente di eseguire immagini container SDK personalizzate o immagini container di template personalizzati per i template flessibili come utente non root.

A differenza di altri ambienti (come Google Kubernetes Engine (GKE)) in cui i container vengono eseguiti su nodi condivisi, le VM worker di Dataflow non sono condivise tra le pipeline. Le risorse della pipeline vengono allocate per singolo job. Non esiste una condivisione tra pipeline di VM e altre risorse.

Il ciclo di vita dell'ambiente di runtime è legato al ciclo di vita della pipeline. Viene avviato all'inizio della pipeline e interrotto al termine della pipeline. L'ambiente di runtime potrebbe essere riavviato una o più volte durante l'esecuzione della pipeline.

Sicurezza e autorizzazioni per le pipeline locali

Quando esegui l'operazione in locale, la pipeline Apache Beam viene eseguita come l'accountGoogle Cloud che hai configurato con l'eseguibile di Google Cloud CLI. Le operazioni dell'SDK Apache Beam eseguite localmente e il tuo account Google Cloud hanno accesso agli stessi file e alle stesse risorse.

Per elencare l'account Google Cloud che hai selezionato come predefinito, esegui il comando gcloud config list.

Le pipeline locali possono inviare dati a destinazioni locali, come file locali, o a destinazioni cloud, come Cloud Storage o BigQuery. Se la pipeline eseguita localmente scrive file in risorse basate su cloud come Cloud Storage, utilizza le credenziali dell'account Google Cloud e il progetto Google Cloud che hai configurato come predefinito di Google Cloud CLI. Per istruzioni su come eseguire l'autenticazione con le credenziali del tuo account Google Cloud , consulta il tutorial per il linguaggio che stai utilizzando: Java, Python o Go.

Sicurezza e autorizzazioni per le pipeline su Google Cloud

Quando esegui la pipeline, Dataflow utilizza due service account per gestire la sicurezza e le autorizzazioni:

  • Il service account Dataflow. Il servizio Dataflow utilizza il service account Dataflow nell'ambito della richiesta di creazione del job, ad esempio per controllare la quota del progetto e creare istanze worker per tuo conto. Dataflow utilizza anche il account di servizio Dataflow durante l'esecuzione del job per gestirlo. Questo account è noto anche come agente di servizio Dataflow.

  • Il service account worker. Le istanze worker utilizzano il account di servizio worker per accedere alle risorse di input e output dopo l'invio del job. Per impostazione predefinita, i worker utilizzano il service account Compute Engine predefinito associato al progetto come account di servizio worker. Come best practice, ti consigliamo di specificare un service account gestito dall'utente anziché utilizzare il account di servizio worker predefinito.

Per simulare l'identità del service account quando esegui una pipeline, l'account che avvia la pipeline deve disporre dell'autorizzazione iam.serviceAccounts.actAs. Questa autorizzazione è inclusa nel ruolo Utente account di servizio (roles/iam.serviceAccountUser). La simulazione dell'identità di un service account ti consente di adottare temporaneamente la sua identità e le sue autorizzazioni per eseguire attività che richiedono livelli di accesso diversi, evitando al contempo i rischi associati alle chiavi persistenti. Per saperne di più, consulta Utilizza account di servizio account.

A seconda delle altre autorizzazioni del progetto, il tuo account utente potrebbe aver bisogno anche del ruolo roles/dataflow.developer. Se sei il Project Owner o l'Editor, disponi già delle autorizzazioni contenute nel ruolo roles/dataflow.developer.

Best practice

  • Se possibile, per il service account worker, specifica un service account gestito dall'utente anziché utilizzare il account di servizio worker predefinito.
  • Quando assegni le autorizzazioni per le risorse, concedi il ruolo che contiene le autorizzazioni minime richieste per l'attività. Puoi creare un ruolo personalizzato che includa solo le autorizzazioni richieste.
  • Quando concedi i ruoli per accedere alle risorse, utilizza il livello di risorsa più basso possibile. Ad esempio, anziché concedere il ruolo roles/bigquery.dataEditor su un progetto o una cartella, concedilo sulla tabella BigQuery.
  • Crea un bucket di proprietà del tuo progetto da utilizzare come bucket di gestione temporanea per Dataflow. Le autorizzazioni predefinite del bucket consentono a Dataflow di utilizzare il bucket per archiviare in un'area intermedia i file eseguibili della pipeline.

Account di servizio Dataflow

Tutti i progetti che hanno utilizzato la risorsa Dataflow Job dispongono di un service account Dataflow, noto anche come agente di servizio Dataflow, con l'indirizzo email seguente:

service-PROJECT_NUMBER@dataflow-service-producer-prod.

Questo account di servizio viene creato e gestito da Google e assegnato automaticamente al tuo progetto al primo utilizzo della risorsa Dataflow Job.

Nell'ambito dell'esecuzione delle pipeline di Dataflow, Dataflow manipola le risorse per tuo conto. Ad esempio, crea VM aggiuntive. Questo account di servizio viene utilizzato quando esegui la pipeline con Dataflow.

A questo account viene assegnato il ruolo Agente di servizio Dataflow nel progetto. Dispone delle autorizzazioni necessarie per eseguire un job Dataflow nel progetto, incluso l'avvio dei worker di Compute Engine. Questo account viene utilizzato esclusivamente da Dataflow ed è specifico per il tuo progetto.

Puoi esaminare i ruoli assegnati al account di servizio Dataflow nella consoleGoogle Cloud o in Google Cloud CLI.

Console

  1. Vai alla pagina Ruoli.

    Vai a Ruoli.

  2. Se applicabile, seleziona il tuo progetto.

  3. Nell'elenco, fai clic sul titolo Agente di servizio Cloud Dataflow. Viene visualizzata una pagina che elenca le autorizzazioni assegnate al account di servizio Dataflow.

gcloud CLI

Visualizza le autorizzazioni del account di servizio Dataflow:

gcloud iam roles describe roles/dataflow.serviceAgent

Poiché i servizi Google Cloud prevedono di avere accesso in lettura e scrittura al progetto e alle relative risorse, ti consigliamo di non modificare le autorizzazioni predefinite stabilite automaticamente per il progetto. Se un account di servizio Dataflow perde le autorizzazioni per un progetto, Dataflow non può avviare VM o eseguire altre attività di gestione.

Se rimuovi le autorizzazioni per il account di servizio dalla policy di Identity and Access Management (IAM), l'account rimane presente perché è di proprietà del servizio Dataflow.

Account di servizio worker

Le istanze di Compute Engine eseguono le operazioni dell'SDK Apache Beam nella cloud. Questi worker utilizzano l'account di servizio worker del tuo progetto per accedere ai file e ad altre risorse associate alla pipeline. Il account di servizio worker viene utilizzato come identità per tutte le VM worker e tutte le richieste provenienti dalla VM utilizzano il account di servizio worker. Questo account di servizio viene utilizzato anche per interagire con risorse come i bucket Cloud Storage e gli argomenti Pub/Sub.

  • Affinché il account di servizio worker possa eseguire un job, deve avere il ruolo roles/dataflow.worker.
  • Affinché il account di servizio worker possa creare o esaminare un job, deve avere il ruolo roles/dataflow.admin.

Inoltre, quando le pipeline Apache Beam accedono alle risorse Google Cloud , devi concedere i ruoli richiesti al account di servizio worker del progetto Dataflow. Il account di servizio worker deve essere in grado di accedere alle risorse durante l'esecuzione del job Dataflow. Ad esempio, se il job scrive in BigQuery, il account di servizio deve avere anche almeno il ruolo roles/bigquery.dataEditor nella tabella BigQuery. Ecco alcuni esempi di risorse:

Account di servizio worker predefinito

Per impostazione predefinita, i worker utilizzano il service account predefinito di Compute Engine del tuo progetto come account di servizio worker. Questo account di servizio ha il seguente indirizzo email:

PROJECT_NUMBER-compute@

Questo account di servizio viene creato automaticamente quando abiliti l'API Compute Engine per il tuo progetto dalla libreria API nella console Google Cloud .

Sebbene tu possa utilizzare il account di servizio predefinito di Compute Engine come account di servizio worker Dataflow, ti consigliamo di creare un account di servizio worker Dataflow dedicato con solo i ruoli e le autorizzazioni di cui hai bisogno.

A seconda della configurazione della policy dell'organizzazione, al service account predefinito potrebbe essere assegnato automaticamente il ruolo Editor nel progetto. Ti consigliamo vivamente di disattivare la concessione automatica dei ruoli forzando l'applicazione del vincolo iam.automaticIamGrantsForDefaultServiceAccounts della policy dell'organizzazione. Se hai creato la tua organizzazione dopo il 3 maggio 2024, questo vincolo viene imposto per impostazione predefinita.

Se disattivi la concessione automatica dei ruoli, devi decidere quali ruoli concedere ai service account predefiniti, quindi concedere personalmente questi ruoli.

Se il service account predefinito dispone già del ruolo Editor, ti consigliamo di sostituire il ruolo Editor con ruoli meno permissivi.

Specifica un account di servizio worker gestito dall'utente

Se vuoi creare e utilizzare risorse con controllo dell'accesso granulare dell'accesso, puoi creare un account di servizio gestito dall'utente. Utilizza questo account come service account worker.

  1. Se non hai un account di servizio gestito dall'utente, creane uno.

  2. Imposta i ruoli IAM richiesti per il tuo account di servizio.

    • Affinché il account di servizio worker possa eseguire un job, deve avere il ruolo roles/dataflow.worker.
    • Affinché il account di servizio worker possa creare o esaminare un job, deve avere il ruolo roles/dataflow.admin.
    • In alternativa, crea un ruolo IAM personalizzato con le autorizzazioni richieste. Per un elenco delle autorizzazioni richieste, consulta Ruoli.

  3. Il tuo account di servizio potrebbe aver bisogno di ruoli aggiuntivi per utilizzare le risorse Google Cloudcome richiesto dal tuo job, ad esempio BigQuery, Pub/Sub o Cloud Storage. Ad esempio, se il job legge da BigQuery, il account di servizio deve avere anche almeno il ruolo roles/bigquery.dataViewer nella tabella BigQuery.

  4. Assicurati che il tuo account di servizio gestito dall'utente abbia accesso in lettura e scrittura alle posizioni temporanee e di gestione temporanea specificate nel job Dataflow.

  5. Per avviare la pipeline, il tuo account utente deve disporre dell'autorizzazione iam.serviceAccounts.actAs per impersonare il service account worker.

  6. Nel progetto che contiene il account di servizio worker gestito dall'utente, il service account Dataflow (service-PROJECT_NUMBER@dataflow-service-producer-prod.) e l' agente di servizio Compute Engine (service-PROJECT_NUMBER@compute-system.) devono avere i seguenti ruoli. PROJECT_NUMBER è l'ID del progetto in cui viene eseguito il job Dataflow. Entrambi questi account sono agenti di servizio.

    Supponiamo che il job Dataflow sia in esecuzione nel progetto A e che il account di servizio worker sia ospitato nel progetto B. Assicurati che gli agenti di servizio del progetto A abbiano i ruoli iam.serviceAccountTokenCreator e iam.serviceAccountUser nel progetto B. Nel progetto in cui viene eseguito il job Dataflow, gli account hanno questi ruoli per impostazione predefinita. Per concedere questi ruoli, segui i passaggi descritti nella sezione Concedi un singolo ruolo della pagina Gestisci l'accesso ai service account.

  7. Quando il account di servizio worker gestito dall'utente e il job si trovano in progetti diversi, assicurati che il vincolo booleano iam.disableCrossProjectServiceAccountUsage non sia applicato al progetto proprietario del account di servizio gestito dall'utente. Per saperne di più, consulta Abilita il collegamento dei service account tra progetti.

  8. Quando esegui il job della pipeline, specifica il tuo account di servizio.

    Java

    Utilizza l'opzione --serviceAccount e specifica il tuo service account quando esegui il job della pipeline dalla riga di comando: --serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.

    Utilizza l'opzione --service-account-email e specifica il tuo service account quando esegui il job della pipeline come modello flessibile: --service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.

    Python

    Utilizza l'opzione --service_account_email e specifica il tuo account di servizio quando esegui il job della pipeline: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.

    Vai

    Utilizza l'opzione --service_account_email e specifica il tuo account di servizio quando esegui il job della pipeline: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.

Il account di servizio gestito dall'utente può trovarsi nello stesso progetto del job o in un progetto diverso. Se il account di servizio e il job si trovano in progetti diversi, devi configurare il service account prima di eseguire il job.

Visualizza il account di servizio worker per un job

Per un job esistente, l'indirizzo email del account di servizio worker è archiviato nel campo environment.serviceAccountEmail (environment.service_account_email nelle librerie client e RPC) della risorsa Job.

Per recuperare l'oggetto environment e serviceAccountEmail, devi richiedere la visualizzazione del job JOB_VIEW_DESCRIPTION o JOB_VIEW_ALL quando ricevi un job. Le richieste che utilizzano JOB_VIEW_SUMMARY, tra cui projects.locations.jobs.list e le query di riepilogo predefinite, omettono environment.serviceAccountEmail.

Le chiamate API di sola lettura per ispezionare i metadati dei job, ad esempio projects.locations.jobs.get, non comportano addebiti per richiesta. Le chiamate API sono soggette al monitoraggio standard e alle quote API, mentre gli addebiti di Dataflow si applicano alle risorse di calcolo, archiviazione e trattamento dati della pipeline. Per maggiori informazioni, vedi Prezzi.

Console

  1. Nella console Google Cloud , vai alla pagina Dataflow > Job.

    Vai a Job

  2. Fai clic sul nome del job che vuoi ispezionare.

  3. Nella pagina Dettagli job, nel riquadro laterale Informazioni job, fai clic su REST accanto a Equivalente nella parte inferiore del riquadro.

  4. Nella finestra di dialogo Risposta REST equivalente, individua il campo serviceAccountEmail nell'oggetto environment.

    Se hai specificato un account di servizio gestito dall'utente durante l'avvio del job, puoi trovare l'indirizzo email del account di servizio anche nel campo service_account_email nella sezione Opzioni della pipeline del riquadro Informazioni sul job.

gcloud CLI

Per recuperare l'indirizzo email del account di servizio worker per un job, esegui il comando gcloud dataflow jobs describe con il flag --full:

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

Sostituisci quanto segue:

  • JOB_ID: l'ID del job Dataflow
  • REGION: la regione in cui viene eseguito il job, ad esempio us-central1
  • PROJECT_ID: l'ID del progetto che contiene il job

REST

Per recuperare i metadati dell'ambiente di esecuzione di un job e l'indirizzo email del account di servizio worker, invia una richiesta GET al metodo projects.locations.jobs.get e imposta il parametro di query view su JOB_VIEW_DESCRIPTION o 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"

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto che contiene il job
  • REGION: la regione in cui viene eseguito il job, ad esempio us-central1
  • JOB_ID: l'ID del job Dataflow

La risposta è una risorsa Job che include l'indirizzo email del account di servizio worker in environment.serviceAccountEmail:

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

Python

Utilizza la libreria client di Dataflow per Python per chiamare get_job con JobView.JOB_VIEW_DESCRIPTION e leggere 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)

Per ispezionare tutti i job in una regione, chiama list_jobs per elencare gli ID job, quindi chiama get_job con JobView.JOB_VIEW_DESCRIPTION per ogni job.

Java

Utilizza la libreria client di Dataflow per Java per chiamare getJob con JobView.JOB_VIEW_DESCRIPTION e leggere 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());
}

Vai

Utilizza la libreria client di Dataflow per Go per chiamare GetJob con JobView_JOB_VIEW_DESCRIPTION e leggere 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

Per esempi completi di librerie client in altri linguaggi, consulta gli esempi di codice GetJob.

Aggiungi ruoli

Per aggiungere ruoli al progetto, segui questi passaggi.

Console

  1. Nella console Google Cloud vai alla pagina IAM.

    Vai a IAM

  2. Seleziona il progetto.

  3. Nella riga contenente il tuo account utente, fai clic su Modifica entità, quindi su Aggiungi un altro ruolo.

  4. Nell'elenco a discesa, seleziona il ruolo Service Account User.

  5. Nella riga contenente il tuo account di servizio worker, fai clic su Modifica entità, quindi fai clic su Aggiungi un altro ruolo.

  6. Nell'elenco a discesa, seleziona il ruolo Dataflow Worker.

  7. Se il tuo account di servizio worker richiede il ruolo Amministratore Dataflow, ripeti l'operazione per Amministratore Dataflow.

  8. Ripeti l'operazione per tutti i ruoli richiesti dalle risorse utilizzate nel job, quindi fai clic su Salva.

    Per ulteriori informazioni sulla concessione dei ruoli, consulta Concedi un ruolo IAM utilizzando la console.

gcloud CLI

  1. Concedi il ruolo roles/iam.serviceAccountUser al tuo account utente. Esegui questo comando:

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS --role=roles/iam.serviceAccountUser
    • Sostituisci PROJECT_ID con l'ID progetto.
    • Sostituisci EMAIL_ADDRESS con l'indirizzo email dell'account utente.

  2. Concedi i ruoli al tuo account di servizio worker. Esegui il comando seguente per il ruolo IAM roles/dataflow.worker e per tutti i ruoli richiesti dalle risorse utilizzate nel job. Se il tuo account di servizio worker richiede il ruolo Dataflow Admin, ripeti l'operazione per il ruolo IAM roles/dataflow.admin. Questo esempio utilizza il account di servizio predefinito di Compute Engine, ma ti consigliamo di utilizzare un account di servizio gestito dall'utente.

    gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:PROJECT_NUMBER-compute@" --role=SERVICE_ACCOUNT_ROLE
    • Sostituisci PROJECT_ID con l'ID progetto.
    • Sostituisci PROJECT_NUMBER con il numero del progetto. Per trovare il numero del progetto, consulta Identifica i progetti o utilizza il comando gcloud projects describe.
    • Sostituisci SERVICE_ACCOUNT_ROLE con ogni singolo ruolo.

Accedi alle risorse Google Cloud

Le pipeline Apache Beam possono accedere alle risorse Google Cloud , nello stesso progetto Google Cloud o in altri progetti. Le risorse includono:

Per assicurarti che la pipeline Apache Beam possa accedere a queste risorse, devi utilizzare i rispettivi meccanismi di controllo dell'accesso delle risorse per concedere esplicitamente l'accesso al service account worker del tuo progetto Dataflow.

Se utilizzi le funzionalità di Assured Workloads con Dataflow, ad esempio Regioni UE e assistenza con controlli di sovranità, tutti i connettori Cloud Storage, BigQuery, Pub/Sub, I/O e le altre risorse a cui accede la pipeline devono trovarsi nel progetto o nella cartella Assured Workloads della tua organizzazione.

Se utilizzi un account di servizio worker gestito dall'utente o accedi alle risorse in altri progetti, potrebbe essere necessaria un'azione aggiuntiva. I seguenti esempi presuppongono che venga utilizzato il account di servizio predefinito di Compute Engine, ma puoi anche utilizzare un account di servizio worker gestito dall'utente.

Accedi ai repository Artifact Registry

Quando utilizzi container personalizzati con Dataflow, potresti caricare artefatti in un repository Artifact Registry.

Per utilizzare Artifact Registry con Dataflow, devi concedere almeno l'accesso Artifact Registry Writer (role/artifactregistry.writer) al service account worker che esegue il job Dataflow.

Tutti i contenuti del repository sono criptati utilizzando Google-owned and Google-managed encryption keys o chiavi di crittografia gestite dal cliente. Artifact Registry utilizza Google-owned and Google-managed encryption keys per impostazione predefinita e non è richiesta alcuna configurazione per questa opzione.

Accedi ai bucket Cloud Storage

Per concedere al tuo progetto Dataflow l'accesso a un bucket Cloud Storage, rendi il bucket accessibile al service account worker del tuo progetto Dataflow. Come minimo, il service account deve disporre delle autorizzazioni di lettura e autorizzazione in scrittura sia per il bucket che per i relativi contenuti. Puoi utilizzare le autorizzazioni IAM per Cloud Storage per concedere l'accesso richiesto.

Per concedere al account di servizio worker le autorizzazioni necessarie per leggere e scrivere in un bucket, utilizza il comando gcloud storage buckets add-iam-policy-binding. Questo comando aggiunge il account di servizio del progetto Dataflow a una policy a livello di bucket.

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

Sostituisci quanto segue:

  • BUCKET_NAME: il nome del bucket Cloud Storage
  • PROJECT_NUMBER: il numero del tuo progetto Dataflow. Per trovare il numero del progetto, consulta Identifica i progetti o utilizza il comando gcloud projects describe.
  • SERVICE_ACCOUNT_ROLE: il ruolo IAM, ad esempio storage.objectViewer

Per recuperare un elenco dei bucket Cloud Storage in un progettoGoogle Cloud , utilizza il comando gcloud storage buckets list:

gcloud storage buckets list --project= PROJECT_ID

Sostituisci PROJECT_ID con l'ID del progetto.

A meno che non siano presenti policy dell'organizzazione che limitano la condivisione delle risorse, puoi accedere a un bucket che si trova in un progetto diverso da quello della tua pipeline Dataflow. Per saperne di più sulle limitazioni del dominio, consulta Limitazione delle identità per dominio.

Se non hai un bucket, creane uno nuovo. Poi, concedi al account di servizio worker le autorizzazioni necessarie per leggere e scrivere nel bucket.

Puoi anche impostare le autorizzazioni del bucket dalla console Google Cloud . Per saperne di più, consulta Impostazione delle autorizzazioni dei bucket.

Cloud Storage offre due sistemi per concedere agli utenti l'accesso ai bucket e agli oggetti: IAM ed elenchi di controllo dell'accesso (ACL). Nella maggior parte dei casi, IAM è il metodo consigliato per controllare l'accesso alle risorse.

  • IAM controlla le autorizzazioni in tuttoGoogle Cloud e ti consente di concedere autorizzazioni a livello di bucket e di progetto. Per un elenco dei ruoli IAM associati a Cloud Storage e delle autorizzazioni contenute in ogni ruolo, consulta Ruoli IAM per Cloud Storage. Se hai bisogno di un maggiore controllo sulle autorizzazioni, crea un ruolo personalizzato.

  • Se utilizzi gli ACL per controllare l'accesso, assicurati che le autorizzazioni del account di servizio worker siano coerenti con le impostazioni IAM. A causa dell'incoerenza tra le policy IAM e ACL, il bucket Cloud Storage potrebbe diventare inaccessibile ai job Dataflow quando viene eseguita la migrazione del bucket Cloud Storage dall'accesso granulare all'accesso uniforme a livello di bucket. Per saperne di più, consulta la sezione Indicazioni sugli errori comuni.

Accedi ai set di dati BigQuery

Puoi utilizzare l'API BigQueryIO per accedere ai set di dati BigQuery, nello stesso progetto in cui utilizzi Dataflow o in un progetto diverso. Affinché l'origine e il sink BigQuery funzionino correttamente, i seguenti due account devono avere accesso a tutti i set di dati BigQuery da cui il job Dataflow legge o in cui scrive:

  • L'account Google Cloud che utilizzi per eseguire il job Dataflow
  • Il service account worker che esegue il job Dataflow

Potresti dover configurare BigQuery per concedere esplicitamente l'accesso a questi account. Per ulteriori informazioni sulla concessione dell'accesso ai set di dati BigQuery utilizzando la pagina BigQuery o l'API BigQuery, consulta Controllo dell'accesso a BigQuery.

Tra le autorizzazioni BigQuery richieste, l'autorizzazione IAM bigquery.datasets.get è necessaria alla pipeline per accedere a un set di dati BigQuery. In genere, la maggior parte dei ruoli IAM di BigQuery include l'autorizzazione bigquery.datasets.get, ma il ruolo roles/bigquery.jobUser è un'eccezione.

Accedi ad argomenti e sottoscrizioni Pub/Sub

Per accedere a un argomento o a una sottoscrizione Pub/Sub, utilizza le funzionalità di Identity and Access Management di Pub/Sub per configurare le autorizzazioni per il service account worker.

Le autorizzazioni dei seguenti ruoli Pub/Sub sono pertinenti:

  • roles/pubsub.subscriber è obbligatorio per utilizzare i dati.
  • roles/pubsub.editor è obbligatorio per creare una sottoscrizione Pub/Sub.
  • roles/pubsub.viewer è consigliato in modo che Dataflow possa eseguire query sulle configurazioni di argomenti e sottoscrizioni. Questa configurazione offre due vantaggi:
    • Dataflow può verificare la presenza di impostazioni non supportate nelle sottoscrizioni che potrebbero non funzionare come previsto.
    • Se la sottoscrizione non utilizza la scadenza di conferma predefinita di 10 secondi, le prestazioni migliorano. Dataflow estende ripetutamente la scadenza di conferma per un messaggio mentre viene elaborato dalla pipeline. Senza le autorizzazioni pubsub.viewer, Dataflow non è in grado di eseguire query sulla scadenza di conferma e deve quindi assumere una scadenza predefinita. Questa configurazione fa sì che Dataflow invii più richieste modifyAckDeadline del necessario.
    • Se i Controlli di servizio VPC sono abilitati nel progetto proprietario della sottoscrizione o dell'argomento, le regole in entrata basate su indirizzi IP non consentono a Dataflow di eseguire query sulle configurazioni. In questo caso, è necessaria una regola in entrata basata sul account di servizio worker.

Per ulteriori informazioni e alcuni esempi di codice che mostrano come utilizzare le funzionalità di Identity and Access Management di Pub/Sub, consulta Caso d'uso di esempio: comunicazione tra progetti.

Accedi a Firestore

Per accedere a un database Firestore (in modalità nativa o Datastore), aggiungi il tuo account di servizio worker Dataflow (ad esempio PROJECT_NUMBER-compute@) come editor del progetto proprietario del database o utilizza un ruolo Datastore più restrittivo come roles/datastore.viewer. Inoltre, abilita l'API Firestore in entrambi i progetti dalla libreria API nella console Google Cloud .

Accedi alle immagini per i progetti con una criteri per l'utilizzo di immagini attendibili

Se hai configurato una policy per immagini attendibili per il tuo progetto e l'immagine di avvio si trova in un altro progetto, assicurati che la criteri per l'utilizzo di immagini attendibili sia configurata in modo da avere accesso all'immagine. Ad esempio, se esegui un job Dataflow basato su modelli, assicurati che il file della policy includa l'accesso al progetto dataflow-service-producer-prod. Questo progetto Google Cloud contiene le immagini per i job dei modelli.

Accedi ai template forniti da Google con le policy di Principal Access Boundary

Se la tua organizzazione utilizza le policy dei confini di accesso dell'entità (PAB), alle entità (come utenti o service account) potrebbe essere impedito di visualizzare ed eseguire i template forniti da Google. In questo caso, prova una delle seguenti soluzioni:

Per visualizzare i sintomi che indicano un problema relativo alla policy di Principal Access Boundary, consulta Errore durante il caricamento dell'elenco dei template nella console Google Cloud e Autorizzazione negata durante il caricamento di un file di template nella documentazione per la risoluzione dei problemi dei template.

Best practice per la sicurezza di Dataflow

La protezione di una pipeline Dataflow richiede la protezione dei dati ai seguenti tre livelli principali:

  1. Sicurezza della rete e dell'infrastruttura
  2. Identity and Access Management (IAM)
  3. Protezione dei dati e crittografia

Dataflow viene eseguito su macchine virtuali gestite con scalabilità automatica (worker). Di conseguenza, la corretta configurazione di questi elementi contribuisce a garantire che i dati non vengano esposti e rimangano protetti durante l'elaborazione.

Sicurezza della rete e dell'infrastruttura

Per impostazione predefinita, ai worker Dataflow vengono assegnati indirizzi IP pubblici per accedere a internet e alle API di Google. In un ambiente sicuro, devi limitare questo accesso.

  • Disattiva gli IP pubblici: esegui i worker Dataflow senza indirizzi IP pubblici passando il parametro --usePublicIps=false.
  • Configura l'accesso privato Google: quando gli IP pubblici sono disattivati, i worker devono comunque comunicare con le API di Google (come Cloud Storage, BigQuery o Pub/Sub). Abilita l'accesso privato Google sulla subnet VPC in modo che i worker possano instradare il traffico ai servizi Google internamente.
  • Utilizza VPC condivisi e Controlli di servizio VPC (VPC-SC):
    • Posiziona le pipeline Dataflow all'interno di un perimetro di sicurezza utilizzando i Controlli di servizio VPC. In questo modo, si riducono i rischi di esfiltrazione di dati, garantendo che i dati non possano essere copiati in risorse esterne al perimetro, nemmeno da utenti con credenziali valide.
    • Utilizza subnet dedicate con regole firewall rigide, consentendo il traffico solo alle risorse necessarie (come il database o il cluster Kafka) e disattiva esplicitamente SSH.

IAM

Il principio del privilegio minimo è fondamentale. Per impostazione predefinita, Dataflow tenta di utilizzare il account di servizio predefinito di Compute Engine, che spesso dispone di ampie autorizzazioni Editor.

  • Utilizza un account di servizio worker gestito dall'utente: crea un account di servizio dedicato e non privilegiato specifico per i tuoi worker Dataflow e passalo durante l'invio della pipeline. Ad esempio:

    --serviceAccount=YOUR_SERVICE_ACCOUNT@YOUR_PROJECT_ID.

    Dopo aver creato il account di servizio, assegnagli solo i ruoli minimi:

    • Il account di servizio worker deve avere il ruolo roles/dataflow.worker.
    • Concedi solo l'accesso in lettura o scrittura specifico alle risorse esatte toccate dalla pipeline. Ad esempio, concedi roles/storage.objectViewer sul bucket Cloud Storage di input e roles/bigquery.dataEditor sulla tabella BigQuery di destinazione specifica (anziché i ruoli a livello di progetto).

  • Autorizzazioni separate per controller e worker: lo sviluppatore o la pipeline CI/CD che invia il job deve disporre delle autorizzazioni roles/dataflow.admin e roles/iam.serviceAccountUser (o iam.serviceAccounts.actAs) per attivare la pipeline. Tuttavia, le VM worker effettive richiedono solo le autorizzazioni di esecuzione del runtime (roles/dataflow.worker).

Protezione dei dati e crittografia

Sebbene Google Cloud cripti tutti i dati in transito e at-rest per impostazione predefinita, i settori altamente regolamentati spesso richiedono un controllo aggiuntivo sulle chiavi di crittografia.

  • Implementa le chiavi di crittografia gestite dal cliente (CMEK): utilizza Cloud Key Management Service per generare e gestire le tue chiavi. Passa la chiave a Dataflow utilizzando il flag --dataflowKmsKey. Dataflow utilizza questa chiave per criptare:
    • Persistent Disk collegati alle VM worker.
    • Dati di stato di shuffling per le pipeline batch.
    • Stato di Streaming Engine per le pipeline di streaming.
  • Proteggi i tuoi secret: non impostare mai password, chiavi API o credenziali del database come hardcoded nel codice Apache Beam o nelle opzioni della pipeline. Accedi a questi dati in modo dinamico durante le fasi Setup o StartBundle della pipeline utilizzando Secret Manager.
  • Esegui il deployment delle code di messaggi non recapitabili (DLQ): evita di registrare elementi non elaborati e non analizzati quando si verifica un errore, poiché potrebbero contenere informazioni che consentono l'identificazione personale (PII) o secret. Invece, intercetta le eccezioni di elaborazione e indirizza gli elementi non riusciti a un bucket Cloud Storage o a un argomento Pub/Sub "dead-letter" criptato per un'ispezione isolata e sicura.

Analisi del codice e delle vulnerabilità della pipeline

La sicurezza si applica anche alla catena di fornitura del software del tuo codice Apache Beam.

  • Analisi delle immagini container: se utilizzi immagini container personalizzate per i worker Dataflow (utilizzando il flag --sdkContainerImage), archiviale in Artifact Registry e attiva l'analisi automatica delle vulnerabilità.
  • Mantieni le immagini aggiornate: per le pipeline di streaming che vengono eseguite continuamente, aggiorna regolarmente la pipeline per utilizzare le ultime release dell'SDK Apache Beam. Google rafforza e applica regolarmente patch alle immagini di base del sistema operativo sottostante utilizzate da Dataflow.

Elenco di controllo di sicurezza rapido

Utilizza la tabella seguente per identificare un obiettivo di sicurezza e come raggiungerlo.

Obiettivo Parametro o strumento di sicurezza Finalità
Proprietà delle chiavi --dataflowKmsKey Cripta lo stato della pipeline e i dischi dei worker utilizzando Cloud KMS.
Accesso con privilegio minimo --serviceAccount Esegue i worker con un'identità limitata.
Nessuna esposizione a internet --usePublicIps=false Impedisce l'assegnazione di IP pubblici ai worker.
Prevenzione dell'esfiltrazione Controlli di servizio VPC (VPC-SC) Limita lo spostamento dei dati al di fuori del tuo perimetro di attendibilità.
Accesso API sicuro Accesso privato Google Consente ai worker di accedere a Cloud Storage e BigQuery in privato.
Proteggi credenziali Secret Manager Estrae dinamicamente password e chiavi in fase di runtime.
Proteggi i bucket Cloud Storage Autorizzazioni con privilegio minimo Limita le autorizzazioni sui bucket Cloud Storage utilizzati da Dataflow.

Accesso ai dati e sicurezza

Il servizio Dataflow funziona con due tipi di dati:

  • Dati degli utenti finali. Questi dati vengono elaborati da una pipeline Dataflow. Una pipeline tipica legge i dati da una o più origini, implementa le trasformazioni dei dati e scrive i risultati in uno o più sink. Tutte le origini e i sink sono servizi di archiviazione non gestiti direttamente da Dataflow.

  • Dati operativi. Questi dati includono tutti i metadati necessari per la gestione di una pipeline Dataflow. Questi dati includono sia i metadati forniti dall'utente, come il nome di un job o le opzioni della pipeline, sia i metadati generati dal sistema, come l'ID job.

Il servizio Dataflow utilizza diversi meccanismi di sicurezza per mantenere i tuoi dati sicuri e privati. Questi meccanismi si applicano ai seguenti scenari:

  • Invio di una pipeline al servizio
  • Valutazione di una pipeline
  • Richiesta di accesso alla telemetria e alle metriche durante e dopo l'esecuzione di una pipeline
  • Utilizzo di un servizio Dataflow come Shuffle o Streaming Engine

Località dei dati

Tutto il trattamento dati principale per Dataflow avviene nella regione specificata nel codice della pipeline. Se non viene specificata una regione, viene utilizzata la regione predefinita us-central1. Se specifichi questa opzione nel codice della pipeline, il job della pipeline può facoltativamente leggere e scrivere da origini e sink in altre regioni. Tuttavia, il trattamento dati effettivo avviene solo nella regione specificata per l'esecuzione delle VM di Dataflow.

La logica della pipeline viene valutata su singole istanze VM worker. Puoi specificare la zona in cui si trovano queste istanze e la rete privata su cui comunicano. I calcoli accessori per la piattaforma dipendono da metadati come le posizioni di Cloud Storage o le dimensioni dei file.

Dataflow è un servizio regionale. Per saperne di più sulla località dei dati e sulle regioni, consulta Regioni di Dataflow.

Dati in un invio della pipeline

Le autorizzazioni IAM per il tuo progetto Google Cloud controllano l'accesso al servizio Dataflow. Tutte le entità a cui vengono concessi i diritti di editor o proprietario per il tuo progetto possono inviare pipeline al servizio. Per inviare le pipeline, devi autenticarti utilizzando Google Cloud CLI. Dopo l'autenticazione, le pipeline vengono inviate utilizzando il protocollo HTTPS. Per istruzioni su come eseguire l'autenticazione con le credenziali del tuo account Google Cloud , consulta la guida rapida per il linguaggio che stai utilizzando.

Dati in una valutazione della pipeline

Durante la valutazione di una pipeline, potrebbero essere generati dati temporanei archiviati localmente nelle istanze VM worker o in Cloud Storage. I dati temporanei sono criptati at-rest e non vengono conservati al termine della valutazione della pipeline. Questi dati possono anche essere archiviati nel servizio Shuffle o nel servizio Streaming Engine (se hai scelto di utilizzarlo) nella stessa regione specificata nella pipeline di Dataflow.

Java

Per impostazione predefinita, le VM di Compute Engine vengono eliminate al termine del job Dataflow, indipendentemente dal fatto che il job sia riuscito o meno. Di conseguenza, il Persistent Disk associato e tutti i dati intermedi che potrebbero essere archiviati al suo interno vengono eliminati. I dati intermedi archiviati in Cloud Storage si trovano nelle sottolocalità del percorso Cloud Storage che fornisci come --stagingLocation o --tempLocation. Se scrivi l'output in un file Cloud Storage, è possibile che vengano creati file temporanei nella posizione di output prima che l'operazione "write" venga finalizzata.

Python

Per impostazione predefinita, le VM di Compute Engine vengono eliminate al termine del job Dataflow, indipendentemente dal fatto che il job sia riuscito o meno. Di conseguenza, il Persistent Disk associato e tutti i dati intermedi che potrebbero essere archiviati al suo interno vengono eliminati. I dati intermedi archiviati in Cloud Storage si trovano nelle sottolocalità del percorso Cloud Storage che fornisci come --staging_location o --temp_location. Se scrivi l'output in un file Cloud Storage, è possibile che vengano creati file temporanei nella posizione di output prima che l'operazione "write" venga finalizzata.

Vai

Per impostazione predefinita, le VM di Compute Engine vengono eliminate al termine del job Dataflow, indipendentemente dal fatto che il job sia riuscito o meno. Di conseguenza, il Persistent Disk associato e tutti i dati intermedi che potrebbero essere archiviati al suo interno vengono eliminati. I dati intermedi archiviati in Cloud Storage si trovano nelle sottolocalità del percorso Cloud Storage che fornisci come --staging_location o --temp_location. Se scrivi l'output in un file Cloud Storage, è possibile che vengano creati file temporanei nella posizione di output prima che l'operazione "write" venga finalizzata.

Dati nei log e nella telemetria della pipeline

Le informazioni archiviate in Cloud Logging vengono generate principalmente dal codice del tuo programma Dataflow. Il servizio Dataflow potrebbe anche generare dati di avviso ed errore in Cloud Logging, ma questi dati sono gli unici dati intermedi che il servizio aggiunge ai log. Cloud Logging è un servizio globale.

I dati di telemetria e le metriche associate sono criptati at-rest e l'accesso a questi dati è controllato dalle autorizzazioni di lettura del tuo progetto Google Cloud .

Dati nei servizi Dataflow

Se utilizzi Dataflow Shuffle o Dataflow Streaming per la tua pipeline, non specificare le opzioni della pipeline per la zona. Specifica invece la regione e imposta il valore su una delle regioni in cui è disponibile Shuffle o Streaming. Dataflow seleziona automaticamente la zona nella regione che specifichi. I dati degli utenti finali in transito rimangono all'interno delle VM worker e nella stessa zona. Questi job Dataflow possono comunque leggere e scrivere su origini e sink che si trovano al di fuori della zona della VM. I dati in transito possono anche essere inviati ai servizi Dataflow Shuffle o Dataflow Streaming. Tuttavia, i dati rimangono sempre nella regione specificata nel codice della pipeline.

Ti consigliamo di utilizzare i meccanismi di sicurezza disponibili nelle risorse cloud sottostanti della pipeline. Questi meccanismi includono le funzionalità di sicurezza dei dati delle origini e dei sink di dati, come BigQuery e Cloud Storage. Inoltre, è meglio non combinare livelli di attendibilità diversi in un unico progetto.