Sicurezza e autorizzazioni di Dataflow

Puoi eseguire le pipeline Dataflow localmente o sulle risorse Google Cloud gestite utilizzando il programma di esecuzione Dataflow. Indipendentemente dal fatto 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 di Dataflow vengono assegnate in base al ruolo utilizzato per accedere alle risorse della pipeline. Questo documento illustra i seguenti concetti:

  • Upgrade delle VM Dataflow
  • Ruoli e autorizzazioni richiesti per l'esecuzione di pipeline locali e di 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 dei progetti Google Cloud nella panoramica di Google Cloud. Questi identificatori includono il nome, l'ID e il numero di progetto.

Esegui l'upgrade e applica le patch alle VM Dataflow

Dataflow utilizza Container-Optimized OS. I processi di sicurezza di Container-Optimized OS si applicano anche a Dataflow.

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 tramite bollettini sulla sicurezza. Per le pipeline di streaming, consigliamo di utilizzare l'opzione --update per riavviare il job con l'immagine Dataflow più recente.

Le immagini dei contenitori Dataflow sono disponibili nella console Google Cloud.

Sicurezza e autorizzazioni per le pipeline locali

Quando esegui l'esecuzione localmente, la pipeline Apache Beam viene eseguita come account Google Cloud configurato con l'eseguibile Google Cloud CLI. Esegui localmente le operazioni dell'SDK Apache Beam e il tuo account Google Cloud deve avere accesso agli stessi file e alle stesse risorse.

Per elencare l'account Google Cloud selezionato come predefinito, esegui il comandogcloud config list.

Le pipeline locali possono inviare i 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 del tuo account Google Cloud e il progetto Google Cloud che hai configurato come predefinito per Google Cloud CLI. Per istruzioni su come autenticarti con le credenziali del tuo account Google Cloud, consulta la guida rapida per il linguaggio che stai utilizzando: Guida rapida di Java, Guida rapida di Python o Guida rapida di Go.

Sicurezza e autorizzazioni per le pipeline su Google Cloud

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

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

  • L'account di servizio worker. Le istanze di worker utilizzano l'account di servizio worker per accedere alle risorse di input e output dopo l'invio del job. Per impostazione predefinita, i worker utilizzano l'account di servizio predefinito di Compute Engine associato al tuo progetto come account di servizio worker. Come best practice, ti consigliamo di specificare un account di servizio gestito dall'utente instead of using the default worker service account.

Per eseguire il furto d'identità dell'account di servizio, l'account che avvia la pipeline deve avere il seguente ruolo:iam.serviceAccounts.actAs.

A seconda di altre autorizzazioni del progetto, il tuo account utente potrebbe richiedere anche il ruolo roles/dataflow.developer. Se sei un proprietario o un editor del progetto, disponi già delle autorizzazioni contenute nel ruolo roles/dataflow.developer.

Best practice

  • Se possibile, per l'account di servizio di lavoro, specifica un account di servizio gestito dall'utente instead of using the default worker service account.
  • Quando concedi 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 a un progetto o a una cartella, concedilo alla tabella BigQuery.
  • Crea un bucket di proprietà del tuo progetto da utilizzare come bucket di staging per Dataflow. Le autorizzazioni predefinite del bucket consentono a Dataflow di utilizzare il bucket per eseguire il commit dei file eseguibili della pipeline.

Account di servizio Dataflow

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

service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com

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

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

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

Puoi esaminare i ruoli assegnati all'account di servizio Dataflow nella console Google Cloud o in Google Cloud CLI.

Console

  1. Vai alla pagina Ruoli.

    Vai a Ruoli.

  2. Se applicabile, seleziona il progetto.

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

Interfaccia a riga di comando gcloud

Visualizza le autorizzazioni dell'account di servizio Dataflow:

gcloud iam roles describe roles/dataflow.serviceAgent

Poiché i servizi Google Cloud prevedono l'accesso in lettura e scrittura al progetto e alle sue 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 l'account di servizio dal criterio 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 progetto per accedere ai file e ad altre risorse associate alla pipeline. L'account di servizio worker viene utilizzato come identità per tutte le VM worker e tutte le richieste che hanno origine dalla VM utilizzano l'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é l'account di servizio del worker possa eseguire un job, deve disporre del ruolo roles/dataflow.worker.
  • Affinché l'account di servizio dell'operatore 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 all'account di servizio worker del progetto Dataflow. L'account di servizio worker deve essere in grado di accedere alle risorse durante l'esecuzione del job Dataflow. Ad esempio, se il tuo job scrive in BigQuery, il tuo account di servizio deve avere 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 l'account di servizio predefinito di Compute Engine del tuo progetto come account di servizio del worker. Questo account di servizio ha il seguente indirizzo email:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

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

Sebbene sia possibile utilizzare l'account di servizio predefinito di Compute Engine come account di servizio del worker Dataflow, ti consigliamo di creare un account di servizio del worker Dataflow dedicato con solo i ruoli e le autorizzazioni di cui hai bisogno.

A seconda della configurazione dei criteri dell'organizzazione, all'account di servizio predefinito potrebbe essere assegnato automaticamente il ruolo Editor nel progetto. Ti consigliamo vivamente di disattivare la concessione automatica dei ruoli applicando il vincolo iam.automaticIamGrantsForDefaultServiceAccounts delle norme dell'organizzazione. Se hai creato la tua organizzazione dopo il 3 maggio 2024, questo vincolo viene applicato per impostazione predefinita.

Se disattivi la concessione automatica dei ruoli, devi decidere quali ruoli concedere agli account di servizio predefiniti, quindi concedere personalmente questi ruoli.

Se l'account di servizio predefinito ha già il ruolo Editor, ti consigliamo di sostituire il ruolo Editor con ruoli meno permissivi. Per modificare in sicurezza i ruoli dell'account di servizio, utilizza Policy Simulator per vedere l'impatto della modifica, quindi concedi e revoca i ruoli appropriati.

Specifica un account di servizio dell'attività gestito dall'utente

Se vuoi creare e utilizzare risorse con controllo dell'accesso granulare, puoi creare un account di servizio gestito dall'utente. Utilizza questo account come account del servizio 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é l'account di servizio del worker possa eseguire un job, deve disporre del ruolo roles/dataflow.worker.
    • Affinché l'account di servizio dell'operatore 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.
    • Il tuo account di servizio potrebbe richiedere ruoli aggiuntivi per utilizzare le risorse Google Cloud come richiesto dal tuo job, ad esempio BigQuery, Pub/Sub o Cloud Storage. Ad esempio, se il tuo job legge da BigQuery, il tuo account di servizio deve avere almeno il ruolo roles/bigquery.dataViewer nella tabella BigQuery.
    • Assicurati che il tuo account di servizio gestito dall'utente abbia accesso in lettura e scrittura alle posizioni di staging e temporanee specificate nel job Dataflow.
    • Per rubare l'identità dell'account di servizio, il tuo account utente deve disporre dell'autorizzazione iam.serviceAccounts.actAs.

  3. Nel progetto che contiene l'account di servizio worker gestito dall'utente, il service account Dataflow (service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com) e l'agente di servizio Compute Engine (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) 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.

    Nel progetto in cui viene eseguito il job Dataflow, gli account dispongono di questi ruoli per impostazione predefinita. Se l'account di servizio worker gestito dall'utente e il job si trovano in progetti diversi, concedi questi ruoli anche agli account di servizio gestiti da Google utilizzati dall'account di servizio worker gestito dall'utente. Per concedere questi ruoli, segui i passaggi descritti nella sezione Concedere un singolo ruolo della pagina Gestisci l'accesso agli account di servizio.

  4. Quando l'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 per il progetto proprietario dell'account di servizio gestito dall'utente. Per ulteriori informazioni, consulta Abilitare l'attacco degli account di servizio tra progetti.

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

    Java

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

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

    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.iam.gserviceaccount.com

    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.iam.gserviceaccount.com

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

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 Utente account di servizio.

  5. Nella riga contenente l'account di servizio del tuo worker, fai clic su Modifica entità e poi su Aggiungi un altro ruolo.

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

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

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

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

Interfaccia a riga di comando gcloud

  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 all'account di servizio del tuo worker. Esegui il seguente comando per il ruolo IAM roles/dataflow.worker e per eventuali ruoli richiesti dalle risorse utilizzate nel job. Se il tuo account di servizio worker ha bisogno del ruolo Amministratore Dataflow, ripeti l'operazione per il ruolo IAM roles/dataflow.admin. Questo esempio utilizza l'account di servizio predefinito di Compute Engine, ma consigliamo di utilizzare un account di servizio gestito dall'utente.

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

Accedere 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 all'account di servizio dei worker del progetto Dataflow.

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

Se utilizzi un account di servizio per i lavoratori gestito dall'utente o accedi alle risorse in altri progetti, potrebbero essere necessarie ulteriori azioni. I seguenti esempi presuppongono che venga utilizzato l'account di servizio predefinito di Compute Engine, ma puoi anche utilizzare un account di servizio worker gestito dall'utente.

Accedere ai repository Artifact Registry

Quando utilizzi container personalizzati con Dataflow, puoi caricare gli elementi in un repository Artifact Registry.

Per utilizzare Artifact Registry con Dataflow, devi concedere almeno accesso come autore di Artifact Registry (role/artifactregistry.writer) all'account di servizio worker che esegue il job Dataflow.

Tutti i contenuti del repository vengono criptati utilizzando chiavi di proprietà di Google e gestite da Google o chiavi di crittografia gestite dal cliente. Per impostazione predefinita, Artifact Registry utilizza chiavi di proprietà di Google e gestite da Google e non è richiesta alcuna configurazione per questa opzione.

Accedere ai bucket Cloud Storage

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

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

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

Sostituisci quanto segue:

  • BUCKET_NAME: il nome del bucket Cloud Storage
  • PROJECT_NUMBER: il numero del progetto Dataflow. Per trovare il numero del progetto, consulta Identificare 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 progetto Google 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 limitazioni dovute a criteri dell'organizzazione che limitano la condivisione delle risorse, puoi accedere a un bucket che si trova in un progetto diverso dalla pipeline Dataflow. Per ulteriori informazioni sulle limitazioni del dominio, vedi Limitazione delle identità per dominio.

Se non hai un bucket, creane uno nuovo. Quindi, concedi all'account di servizio del tuo worker le autorizzazioni necessarie per leggere e scrivere nel bucket.

Puoi anche impostare le autorizzazioni dei bucket dalla console Google Cloud. Per ulteriori informazioni, consulta Impostare le autorizzazioni dei bucket.

Cloud Storage offre due sistemi per concedere agli utenti l'accesso ai tuoi bucket e ai tuoi 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 tutto Google Cloud e ti consente di concedere autorizzazioni a livello di bucket e progetto. Per un elenco dei ruoli IAM associati a Cloud Storage e delle autorizzazioni contenute in ciascun ruolo, consulta Ruoli IAM per Cloud Storage. Se hai bisogno di un maggiore controllo sulle autorizzazioni, crea un ruolo personalizzato.

  • Se utilizzi le ACL per controllare l'accesso, assicurati che le autorizzazioni degli account di servizio dei lavoratori siano coerenti con le impostazioni IAM. A causa dell'incongruenza tra i criteri 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 ulteriori informazioni, consulta Informazioni sugli errori comuni.

Accedere 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 altro progetto. Affinché l'origine e la destinazione 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:

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

Tra le autorizzazioni BigQuery richieste, l'autorizzazione IAM bigquery.datasets.get è obbligatoria per la 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.

Accedere 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 l'account di servizio di lavoro.

Le autorizzazioni dei seguenti ruoli Pub/Sub sono pertinenti:

  • roles/pubsub.subscriber è obbligatorio per consumare i dati.
  • roles/pubsub.editor è obbligatorio per creare un abbonamento Pub/Sub.
  • roles/pubsub.viewer è consigliato in modo che Dataflow possa eseguire query sulle configurazioni di argomenti e abbonamenti. Questa configurazione presenta due vantaggi:
    • Dataflow può verificare la presenza di impostazioni non supportate negli abbonamenti che potrebbero non funzionare come previsto.
    • Se la sottoscrizione non utilizza la scadenza di ack predefinita di 10 secondi, le prestazioni migliorano. Dataflow estende ripetutamente la scadenza di ack per un messaggio durante l'elaborazione da parte della pipeline. Senza le autorizzazioni pubsub.viewer, Dataflow non è in grado di eseguire query sulla scadenza di ack e deve quindi assumere una scadenza predefinita. Questa configurazione fa sì che Dataflow emetta più richieste di modifyAckDeadline del necessario.
    • Se i Controlli di servizio VPC sono abilitati nel progetto proprietario dell'subscription o dell'argomento, le regole di ingresso basate sull'indirizzo IP non consentono a Dataflow di eseguire query sulle configurazioni. In questo caso, è necessaria una regola di ingresso basata sull'account di servizio del 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.

Accedere a Firestore

Per accedere a un database Firestore (in modalità nativa o in modalità Datastore), aggiungi il tuo account di servizio worker Dataflow (ad esempio PROJECT_NUMBER-compute@developer.gserviceaccount.com) come editor del progetto proprietario del database oppure 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.

Accedere alle immagini per i progetti con un criteri per l'utilizzo di immagini attendibili

Se hai configurato un criterio per immagini attendibili per il tuo progetto e l'immagine di avvio si trova in un altro progetto, assicurati che il criteri per l'utilizzo di immagini attendibili sia configurato per avere accesso all'immagine. Ad esempio, se stai eseguendo un job Dataflow basato su modello, assicurati che il file delle norme includa l'accesso al progetto dataflow-service-producer-prod. Questo progetto Google Cloud contiene le immagini per i job dei modelli.

Accesso ai dati e sicurezza

Il servizio Dataflow funziona con due tipi di dati:

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

  • Dati operativi. Questi dati includono tutti i metadati necessari per gestire 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 un ID job.

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

  • Invio di una pipeline al servizio
  • Valutazione di una pipeline
  • Richiedere l'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

L'intera elaborazione dei dati di base 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 destinazioni in altre regioni. Tuttavia, l'elaborazione effettiva dei dati avviene solo nella regione specificata per l'esecuzione delle VM Dataflow.

La logica della pipeline viene valutata sulle singole istanze VM worker. Puoi specificare la zona in cui si trovano queste istanze e la rete privata su cui comunicano. I calcoli aggiuntivi 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à e sulle regioni dei dati, consulta Regioni di Dataflow.

Dati inviati in una pipeline

Le autorizzazioni IAM per il progetto Google Cloud controllano l'accesso al servizio Dataflow. Qualsiasi entità a cui sono stati assegnati diritti di editor o proprietario per il tuo progetto può 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 autenticarsi con le credenziali dell'account Google Cloud, consulta la guida rapida per la lingua che stai utilizzando.

Dati in una valutazione della pipeline

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

Java

Per impostazione predefinita, le VM Compute Engine vengono eliminate al termine del job Dataflow, indipendentemente dal fatto che il job vada a buon fine o meno. Di conseguenza, il disco rigido permanente associato e tutti i dati intermedi eventualmente memorizzati vengono eliminati. I dati intermedi archiviati in Cloud Storage si trovano nelle sottodirectory del percorso Cloud Storage che fornisci come --stagingLocation o --tempLocation. Se stai scrivendo l'output in un file Cloud Storage, potrebbero essere creati file temporanei nella posizione di output prima del completamento dell'operazione di scrittura.

Python

Per impostazione predefinita, le VM Compute Engine vengono eliminate al termine del job Dataflow, indipendentemente dal fatto che il job vada a buon fine o meno. Di conseguenza, il disco rigido permanente associato e tutti i dati intermedi eventualmente memorizzati vengono eliminati. I dati intermedi archiviati in Cloud Storage si trovano nelle sottodirectory del percorso Cloud Storage che fornisci come --staging_location o --temp_location. Se stai scrivendo l'output in un file Cloud Storage, nella posizione di output potrebbero essere creati file temporanei prima del completamento dell'operazione di scrittura.

Vai

Per impostazione predefinita, le VM Compute Engine vengono eliminate al termine del job Dataflow, indipendentemente dal fatto che il job vada a buon fine o meno. Di conseguenza, il disco rigido permanente associato e tutti i dati intermedi eventualmente memorizzati vengono eliminati. I dati intermedi archiviati in Cloud Storage si trovano nelle sottodirectory del percorso Cloud Storage che fornisci come --staging_location o --temp_location. Se stai scrivendo l'output in un file Cloud Storage, nella posizione di output potrebbero essere creati file temporanei prima del completamento dell'operazione di scrittura.

Dati nei log e nella telemetria della pipeline

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

I dati di telemetria e le metriche associate vengono criptati quando sono inattivi e l'accesso a questi dati è controllato dalle autorizzazioni di lettura del 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 le zone. Specifica invece la regione e imposta il valore su una delle regioni in cui è disponibile la riproduzione casuale o lo streaming. Dataflow seleziona automaticamente la zona nella regione specificata. I dati utente in transito rimangono all'interno delle VM worker e nella stessa zona. Questi job Dataflow possono comunque leggere e scrivere in origini e destinazioni esterne alla zona della VM. I dati in transito possono anche essere inviati ai servizi Dataflow Shuffle o Dataflow Streaming, ma 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 di origini dati e destinazioni come BigQuery e Cloud Storage. Inoltre, è preferibile non combinare diversi livelli di attendibilità in un singolo progetto.