Sicurezza e autorizzazioni di Dataflow

Puoi eseguire le pipeline Dataflow localmente o su risorse gestite Google Cloud utilizzando Dataflow Runner. Indipendentemente dall'esecuzione delle pipeline in locale 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 Google Cloud identificatori di progetto nella Google Cloud panoramica. Questi identificatori includono il nome, l'ID e il numero del progetto.

Esegui l'upgrade e l'applicazione di patch delle VM Dataflow

Dataflow utilizza Container-Optimized OS. Anche a Dataflow si applicano le procedure di sicurezza di Container-Optimized OS.

Le pipeline batch sono vincolate al tempo e non richiedono manutenzione. Quando viene avviata una nuova pipeline batch, viene utilizzata l'ultima immagine Dataflow.

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'ultima immagine Dataflow.

Le immagini container Dataflow sono disponibili nella consoleGoogle Cloud .

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. Le risorse della pipeline vengono allocate in base al singolo job; non è prevista la 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 arrestato al termine della pipeline. L'ambiente di runtime può essere riavviato una o più volte durante l'esecuzione della pipeline.

Sicurezza e autorizzazioni per le pipeline locali

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

Per elencare l'account Google Cloud che hai selezionato come predefinito, esegui il comando gcloud 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 sul cloud come Cloud Storage, utilizza le credenziali del tuo 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 account di servizio Dataflow come parte della richiesta di creazione del job, ad esempio per controllare la quota del progetto e per creare istanze worker per tuo conto. Dataflow utilizza anche il account di servizio Dataflow durante l'esecuzione del job per gestire il job. Questo account è noto anche come agente di servizio Dataflow.

• L'account di servizio 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 l'account di servizio predefinito di Compute Engine associato al tuo progetto come service account worker. Come best practice, ti consigliamo di specificare un service account gestito dall'utente anziché utilizzare iaccount di serviziont worker predefinito.

Per rappresentare il account di servizio, l'account che avvia la pipeline deve avere il seguente ruolo: iam.serviceAccounts.actAs.

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

Best practice

• Se possibile, per l'account di servizio worker, specifica un service account gestito dall'utente anziché utilizzare l'account di servizio worker predefinito.
• Quando concedi autorizzazioni per le risorse, assegna il ruolo che contiene le autorizzazioni minime richieste per l'attività. Puoi creare un ruolo personalizzato che includa solo le autorizzazioni richieste.
• Quando concedi ruoli per accedere alle risorse, utilizza il livello di risorsa più basso possibile. Ad esempio, anziché concedere il ruolo roles/bigquery.dataEditor in un progetto o una cartella, concedi il ruolo nella tabella BigQuery.
• Crea un bucket di proprietà del tuo progetto da utilizzare come bucket di staging per Dataflow. Le autorizzazioni del bucket predefinito 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 hanno un service account 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 tuo 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 è 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 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 consoleGoogle Cloud o nella Google Cloud CLI.

gcloud iam roles describe roles/dataflow.serviceAgent

Poiché Google Cloud i servizi prevedono di avere accesso in lettura e scrittura al progetto e alle relative risorse, è consigliabile 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 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 associati alla pipeline. L'account di servizio worker viene utilizzato come identità per tutte le VM worker e tutte le richieste provenienti dalla VM utilizzano l'account di servizio worker. Questo account di servizio viene utilizzato anche per interagire con risorse come bucket Cloud Storage e argomenti Pub/Sub.

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

Inoltre, quando le pipeline Apache Beam accedono alle risorse, devi concedere i ruoli richiesti al account di servizio worker del progetto Dataflow. Google Cloud 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:

• Bucket Cloud Storage
• Set di dati BigQuery
• Argomenti e sottoscrizioni Pub/Sub
• Set di dati Firestore

Account di servizio worker predefinito

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

PROJECT_NUMBER-compute@developer.gserviceaccount.com

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 l'account di servizio predefinito di Compute Engine come service account worker Dataflow, ti consigliamo di creare un service account worker Dataflow dedicato che disponga solo dei ruoli e delle autorizzazioni necessari.

A seconda della configurazione della policy dell'organizzazione, al account di servizio predefinito potrebbe essere concesso automaticamente il ruolo Editor nel tuo progetto. Ti consigliamo vivamente di disattivare la concessione automatica dei ruoli applicando il vincolo iam.automaticIamGrantsForDefaultServiceAccounts del criterio 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 e poi concederli personalmente.

Se l'account di servizio predefinito dispone già del ruolo Editor, ti consigliamo di sostituirlo con ruoli meno permissivi.Per modificare in modo sicuro i ruoli dell'account di servizio, utilizza Policy Simulator per visualizzare l'impatto della modifica, quindi concedi e revoca i ruoli appropriati.

Specifica un account di servizio worker gestito dall'utente

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

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

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

   • Affinché il account di servizio worker possa eseguire un job, deve disporre del ruolo roles/dataflow.worker.
   • Affinché il account di servizio del worker possa creare o esaminare un job, deve disporre del ruolo roles/dataflow.admin.
   • In alternativa, crea un ruolo IAM personalizzato con le autorizzazioni richieste. Per un elenco delle autorizzazioni richieste, vedi Ruoli.
   • Il account di servizio potrebbe richiedere ruoli aggiuntivi per utilizzare le risorse Google Cloud come richiesto dal 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 account di servizio gestito dall'utente abbia accesso in lettura e scrittura alle posizioni di gestione temporanea e temporanee specificate nel job Dataflow.
   • Per rappresentare il account di servizio, il tuo account utente deve disporre dell'autorizzazione iam.serviceAccounts.actAs.

3. Nel progetto che contiene il 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.

   • Ruolo Creatore token service account (iam.serviceAccountTokenCreator)
   • Ruolo utente Service Account User (iam.serviceAccountUser)

   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 Concedere un singolo ruolo della pagina Gestire l'accesso ai service account.

4. 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 venga applicato al progetto proprietario del account di servizio worker gestito dall'utente. Per maggiori informazioni, vedi Consentire l'allegato di service account tra progetti.

5. Quando esegui il job della pipeline, specifica il 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.iam.gserviceaccount.com

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

   Python

   Utilizza l'opzione --service_account_email e specifica il tuo account di serviziot 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 serviziot quando esegui il job della pipeline: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

Il 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 tuo progetto, segui questi passaggi.

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:

• Repository Artifact Registry
• Bucket Cloud Storage
• Set di dati BigQuery
• Argomenti e sottoscrizioni Pub/Sub
• Set di dati Firestore

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 e assistenza UE con controlli di sovranità, tutti i connettori Cloud Storage, BigQuery, Pub/Sub, I/O e 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 a risorse in altri progetti, potrebbe essere necessaria un'azione aggiuntiva. I seguenti esempi presuppongono l'utilizzo delaccount di serviziot predefinito di Compute Engine, ma puoi utilizzare anche uaccount di serviziont worker gestito dall'utente.

Accedere 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 in scrittura ad Artifact Registry (role/artifactregistry.writer) all'account di servizio 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.

Accedere 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 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 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@developer.gserviceaccount.com" --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, vedi 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 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 tu non sia limitato da 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 dei domini, vedi Limitazione delle identità per dominio.

Se non hai un bucket, creane uno nuovo. Poi, concedi all'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 ulteriori informazioni, vedi Impostare le autorizzazioni del 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 tue 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 gli ACL per controllare l'accesso, assicurati che le autorizzazioni delaccount di serviziot 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 tuoi job Dataflow quando viene eseguita la migrazione dall'accesso granulare all'accesso uniforme a livello di bucket. Per saperne di più, vedi Indicazioni 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 progetto diverso. Affinché l'origine e il sink BigQuery funzionino correttamente, i due account seguenti devono avere accesso a tutti i set di dati BigQuery da cui il job Dataflow legge o in cui scrive:

• L' Google Cloud account che utilizzi per eseguire il job Dataflow
• L'account di servizio worker che esegue il job Dataflow

Potrebbe essere necessario configurare BigQuery per concedere esplicitamente l'accesso a questi account. Per saperne di più 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 è necessaria alla pipeline per accedere a un set di dati BigQuery. In genere, la maggior parte dei ruoli IAM BigQuery include l'autorizzazione bigquery.datasets.get, ma il ruolo roles/bigquery.jobUser è un'eccezione.

Accedere a sottoscrizioni e argomenti Pub/Sub

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

Sono pertinenti le autorizzazioni dei seguenti ruoli Pub/Sub:

• roles/pubsub.subscriber è obbligatorio per utilizzare 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 l'abbonamento non utilizza il termine di riconoscimento predefinito di 10 secondi, le prestazioni migliorano. Dataflow estende ripetutamente la scadenza di riconoscimento per un messaggio mentre viene elaborato dalla pipeline. Senza le autorizzazioni pubsub.viewer, Dataflow non è in grado di eseguire query sulla scadenza di riconoscimento e pertanto deve presupporre una scadenza predefinita. Questa configurazione fa sì che Dataflow emetta più richieste modifyAckDeadline del necessario.
  • Se Controlli di servizio VPC è abilitato nel progetto proprietario dell'abbonamento o dell'argomento, le regole di ingresso basate su indirizzi IP non consentono a Dataflow di eseguire query sulle configurazioni. In questo caso, è necessaria una regola di ingresso basata sul 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 Scenario di utilizzo di esempio: comunicazione tra progetti.

Accedere a Firestore

Per accedere a un database Firestore (in modalità nativa o Datastore), aggiungi l'account di servizio worker Dataflow (ad esempio PROJECT_NUMBER-compute@developer.gserviceaccount.com) come editor del progetto proprietario del database o utilizza un ruolo Datastore più restrittivo, ad esempio 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 una criteri per l'utilizzo di immagini attendibili

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

Accesso ai dati e sicurezza

Il servizio Dataflow funziona con due tipi di dati:

• Dati dell'utente finale. 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 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 a telemetria e metriche durante e dopo l'esecuzione di una pipeline
• Utilizzo di un servizio Dataflow come Shuffle o Streaming Engine

Località dei dati

Tutta l'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 sink 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 ausiliari 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ù su località e regioni dei dati, consulta Regioni Dataflow.

Dati in un invio della pipeline

Le autorizzazioni IAM per il tuo progetto Google Cloud controllano l'accesso al servizio Dataflow. Qualsiasi entità a cui vengono concessi i diritti di editor o proprietario per il tuo progetto può inviare pipeline al servizio. Per inviare pipeline, devi autenticarti utilizzando Google Cloud CLI. Una volta eseguita l'autenticazione, le pipeline vengono inviate utilizzando il protocollo HTTPS. Per istruzioni su come autenticarti con le credenziali del tuo 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, potrebbero essere generati e archiviati dati temporanei localmente nelle istanze VM worker o in Cloud Storage. I dati temporanei vengono criptati at-rest e non vengono conservati al termine della valutazione di una pipeline. Questi dati possono essere archiviati anche nel servizio Shuffle o nel servizio Streaming Engine (se hai attivato il servizio) nella stessa regione specificata nella pipeline Dataflow.

Dati nei log e nella telemetria della pipeline

Le informazioni archiviate in Cloud Logging vengono generate principalmente dal codice nel 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 vengono 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 pipeline, non specificare le opzioni della pipeline per zona. Specifica invece la regione e imposta il valore su una delle regioni in cui sono disponibili Shuffle o Streaming. Dataflow seleziona automaticamente la zona nella regione che specifichi. I dati dell'utente finale in transito rimangono all'interno delle VM worker e nella stessa zona. Questi job Dataflow possono comunque leggere e scrivere in origini e sink esterni 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.

Prassi consigliata

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 e sink come BigQuery e Cloud Storage. Inoltre, è preferibile non combinare diversi livelli di attendibilità in un unico progetto.