Puoi eseguire pipeline Dataflow in locale o su risorse Google Cloud gestite utilizzando Servizio gestito Dataflow. Sia in esecuzione in locale che nel cloud, la pipeline e i suoi worker utilizzano un sistema di autorizzazioni per mantenere sicuro l'accesso ai file e alle risorse della pipeline. Le autorizzazioni per Dataflow vengono assegnate in base al ruolo utilizzato per l'accesso alle risorse della pipeline. Questo documento illustra i seguenti concetti:
- Upgrade delle VM di Dataflow
- Ruoli e autorizzazioni necessari per eseguire pipeline locali e Google Cloud
- Ruoli e autorizzazioni necessari per accedere alle risorse della pipeline
- Tipi di dati utilizzati in un servizio Dataflow e nella sicurezza dei dati
Prima di iniziare
Per saperne di più sugli identificatori di progetto Google Cloud, consulta Panoramica di Google Cloud. Questi identificatori includono il nome del progetto, l'ID progetto e il numero del progetto.
Esegui l'upgrade e le patch delle VM Dataflow
Dataflow utilizza Container-Optimized OS. Pertanto, i processi di sicurezza di Container-Optimized OS si applicano anche a Dataflow.
Le pipeline in modalità batch sono vincolate al tempo e non richiedono manutenzione. Quando viene avviata una nuova pipeline batch, viene utilizzata l'immagine Dataflow più recente.
Per le pipeline in modalità flusso, se è necessaria
immediatamente una patch di sicurezza,
Google Cloud ti invia una notifica utilizzando i bollettini sulla sicurezza. Per le pipeline in modalità flusso,
ti consigliamo di utilizzare l'opzione --update
per riavviare il job con l'immagine Dataflow più recente.
Le immagini container Dataflow sono disponibili Console Google Cloud.
Sicurezza e autorizzazioni per le pipeline locali
Quando esegui in locale, la pipeline Apache Beam viene eseguita come Account Google Cloud che hai configurato con l'eseguibile Google Cloud CLI. Quindi, esegui localmente le operazioni dell'SDK Apache Beam e il server hanno accesso agli stessi file e alle stesse risorse.
Per elencare l'account Google Cloud selezionato come predefinito, esegui
Comando gcloud config list
.
Le pipeline locali possono inviare dati a destinazioni locali, come o verso destinazioni cloud come Cloud Storage o BigQuery. Se le tue la pipeline eseguita localmente scrive file in risorse basate su cloud come Cloud Storage, utilizza il tuo le credenziali dell'account Google Cloud Progetto Google Cloud che hai configurato come l'impostazione predefinita di Google Cloud CLI. Per istruzioni su come eseguire l'autenticazione con le credenziali del tuo account Google Cloud, consulta guida rapida per la lingua che stai utilizzando: Guida rapida di Java, guida rapida di Python, oppure Guida rapida di Go.
Sicurezza e autorizzazioni per le pipeline su Google Cloud
Quando esegui la pipeline, Dataflow utilizza due account di servizio gestire sicurezza e autorizzazioni:
L'account di servizio Dataflow. Il servizio Dataflow utilizza Account di servizio 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 l'account di servizio Dataflow durante l'esecuzione per gestire il job. Questo account è anche noto come Agente di servizio Dataflow.
L'account di servizio del worker. Le istanze worker utilizzano account di servizio worker per accedere alle risorse di input e di output dopo aver inviato il job. Per impostazione predefinita, i worker utilizzano Account di servizio predefinito Compute Engine associati al tuo progetto come account di servizio worker. Come best practice, ti consigliamo di specificare un account di servizio gestito dall'utente anziché utilizzare l'account di servizio del worker predefinito.
Per rubare l'identità
l'account di servizio, l'account che avvia la pipeline deve avere il seguente ruolo:
iam.serviceAccounts.actAs
.
In base ad altre autorizzazioni del progetto,
il tuo account utente potrebbe richiedere anche il ruolo roles/dataflow.developer
. Se
sei proprietario o editor del progetto, disponi già delle autorizzazioni contenute
Ruolo roles/dataflow.developer
.
Best practice
- Se possibile, per l'account di servizio worker, specifica un account di servizio gestito dall'utente anziché utilizzare l'account di servizio del worker predefinito.
- Quando concedi le autorizzazioni sulle risorse, concedi il ruolo che contiene le autorizzazioni minime richieste per l'attività. Puoi crea un ruolo personalizzato che includa solo i le autorizzazioni necessarie.
- Quando concedi ruoli per accedere alle risorse, utilizza la risorsa più bassa possibile.
livello. Ad esempio, invece di concedere il ruolo
roles/bigquery.dataEditor
assegna il ruolo nella tabella BigQuery su un progetto o una cartella. - Crea un bucket di proprietà del tuo progetto da usare come bucket gestione temporanea per Dataflow. Il bucket predefinito consentono a Dataflow di usare il bucket per lo stage i file eseguibili della pipeline.
Account di servizio Dataflow
Tutti i progetti che hanno utilizzato la risorsa Dataflow Job
disporre di un account di servizio Dataflow,
noto anche come agente di servizio Dataflow,
che contiene il seguente indirizzo email:
service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com
Questo account di servizio è stato creato e gestito da Google e assegnato al tuo
automaticamente al primo utilizzo
la risorsa Dataflow Job
.
Nell'esecuzione della pipeline Dataflow, Il servizio Dataflow manipola le risorse per tuo conto. Per crea VM aggiuntive. Quando esegui la pipeline Servizio Dataflow, il servizio utilizza questo account di servizio.
A questo account è assegnato il Dataflow Ruolo di Agente di servizio per il progetto. Dispone delle autorizzazioni necessarie per eseguire Job Dataflow nel progetto, tra cui l'avvio Worker Compute Engine. Questo account è utilizzato esclusivamente da servizio Dataflow ed è per il tuo progetto.
Puoi rivedere le autorizzazioni dell'account di servizio Dataflow nella nella console Google Cloud Google Cloud CLI.
Console
Vai alla pagina Ruoli.
Se applicabile, seleziona il progetto.
Nell'elenco, fai clic sul titolo Agente di servizio Cloud Dataflow. Si apre una pagina 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 di avere accesso in lettura e scrittura progetto e le relative risorse, è consigliabile non modificare il valore predefinito automaticamente le autorizzazioni stabilite per il tuo progetto. Se un account di servizio Dataflow perde le autorizzazioni per un progetto, Dataflow avviare VM o eseguire altre attività di gestione.
Se rimuovi le autorizzazioni per l'account di servizio da Identity and Access Management (IAM) alle norme, l'account rimane presente perché è di proprietà del dal 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 ai file e ad altre risorse associate alla pipeline. L'account di servizio worker è utilizzata come identità per tutte le VM worker e per tutte le richieste provenienti una VM utilizza l'account di servizio worker. Questo account di servizio viene utilizzato anche interagire con risorse come bucket Cloud Storage e argomenti Pub/Sub.
- Affinché l'account di servizio worker sia in grado di eseguire un job, deve avere
Ruolo
roles/dataflow.worker
. - Affinché l'account di servizio worker sia in grado di creare o esaminare un job, deve
hanno il ruolo
roles/dataflow.admin
.
Inoltre, quando le pipeline Apache Beam accedono alle risorse Google Cloud,
devi concedere i ruoli richiesti al tuo progetto Dataflow
di account di servizio per il worker. L'account di servizio worker deve poter
accedere alle risorse durante l'esecuzione
del job Dataflow. Ad esempio, se il tuo job scrive
BigQuery, il tuo account di servizio deve inoltre includere almeno
ruolo roles/bigquery.dataEditor
nella tabella BigQuery. Esempi di risorse includono:
Account di servizio worker predefinito
Per impostazione predefinita, i worker utilizzano Account di servizio predefinito Compute Engine del progetto come account di servizio worker. Questo account di servizio ha il seguente indirizzo email:
PROJECT_NUMBER-compute@developer.gserviceaccount.com
Questo account di servizio è vengono creati automaticamente quando abiliti l'API Compute Engine per progetto dal Libreria API nella console Google Cloud.
Sebbene sia possibile utilizzare l'account di servizio predefinito l'account di servizio worker Dataflow, crei un account di servizio worker Dataflow dedicato che solo i ruoli e le autorizzazioni di cui hai bisogno.
A seconda della configurazione dei criteri dell'organizzazione, l'account di servizio predefinito potrebbe
automaticamente il ruolo Editor
progetto. Ti consigliamo vivamente di disabilitare la concessione automatica del ruolo entro il giorno
applicazione del criterio dell'organizzazione iam.automaticIamGrantsForDefaultServiceAccounts
di blocco. Se hai creato la tua organizzazione dopo il 3 maggio 2024,
viene applicato per impostazione predefinita.
Se disabiliti la concessione automatica del ruolo, devi decidere quali ruoli concedere a quelli predefiniti account di servizio e poi concedi ruoli.
Se l'account di servizio predefinito ha già il ruolo Editor, ti consigliamo di sostituire il valore Ruolo Editor con ruoli meno permissivi. Per modificare in modo sicuro i ruoli dell'account di servizio, utilizza il Simulatore di criteri per vedere l'impatto dei la modifica e quindi concedere e revocare ruoli appropriati.
Specifica un account di servizio per il worker gestito dall'utente
Se vuoi creare e utilizzare risorse con un controllo dell'accesso granulare, possono creare un account di servizio gestito dall'utente. Utilizza questo account come servizio worker .
Se non hai un account di servizio gestito dall'utente, crea un account di servizio.
Imposta i ruoli IAM richiesti per l'account di servizio.
- Affinché l'account di servizio worker sia in grado di eseguire un job, deve avere
Ruolo
roles/dataflow.worker
. - Affinché l'account di servizio worker sia in grado di creare o esaminare un job, deve
hanno il ruolo
roles/dataflow.admin
. - In alternativa, crea un ruolo IAM personalizzato con autorizzazioni aggiuntive. Per un elenco delle autorizzazioni necessarie, vedi Ruoli.
- Il tuo account di servizio
potrebbero aver bisogno di ruoli aggiuntivi per utilizzare le risorse Google Cloud, come richiesto
del 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 inoltre includere almeno
ruolo
roles/bigquery.dataViewer
nella tabella BigQuery. - Assicurati che il tuo account di servizio gestito dall'utente dispone dell'accesso in lettura e scrittura alle posizioni di gestione temporanea e temporanea specificate nel job Dataflow.
- Per impersonare l'account di servizio, l'account utente deve avere il campo
Autorizzazione
iam.serviceAccounts.actAs
.
- Affinché l'account di servizio worker sia in grado di eseguire un job, deve avere
Ruolo
Nel progetto che contiene l'account di servizio worker gestito dall'utente, Account di servizio Dataflow (
service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com
) e ai 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. Entrambe le opzioni sono agenti di servizio.- Ruolo Creatore token account di servizio
(
iam.serviceAccountTokenCreator
) - Ruolo Utente account di servizio
(
iam.serviceAccountUser
)
Nel progetto in cui Il job Dataflow viene eseguito. Gli account hanno questi ruoli per impostazione predefinita. Se l'account di servizio per il worker gestito dall'utente e il job si trovano in progetti diversi, assegna questi ruoli anche agli account di servizio gestiti da Google utilizzati account di servizio dall'utente. Per concedere questi ruoli, segui i passaggi nella Assegna un singolo ruolo della pagina Gestisci l'accesso agli account di servizio.
- Ruolo Creatore token account di servizio
(
Quando l'account di servizio per il worker gestito dall'utente e il job si trovano in in diversi progetti, assicurati che Il vincolo booleano
iam.disableCrossProjectServiceAccountUsage
non è e applicato per il progetto proprietario dell'account di servizio gestito dall'utente. Per maggiori informazioni le informazioni, vedi Abilita il collegamento degli account di servizio tra progetti.Quando esegui il job della pipeline, specifica il tuo account di servizio.
Java
Utilizza l'opzione
--serviceAccount
e specifica il 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 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 l'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 l'account di servizio quando esegui il job della pipeline:--service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
Puoi ottenere un elenco degli account di servizio associati al tuo progetto dal Pagina Autorizzazioni nella console Google Cloud.
L'account di servizio gestito dall'utente può trovarsi nello stesso progetto del tuo job o in una 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 nel progetto, segui questi passaggi.
Console
Nella console Google Cloud, vai alla pagina IAM.
Seleziona il progetto.
Nella riga contenente il tuo account utente, fai clic su
Modifica entità, e fai clic su Aggiungi un altro ruolo.Nell'elenco a discesa, seleziona il ruolo Utente account di servizio.
Nella riga contenente il tuo account di servizio worker, fai clic su
Modifica entità, e fai clic su Aggiungi un altro ruolo.Nell'elenco a discesa, seleziona il ruolo Worker Dataflow.
Se il tuo account di servizio worker richiede il ruolo Amministratore Dataflow, ripeti la procedura per Amministratore Dataflow.
Ripeti la procedura 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.
Interfaccia a riga di comando gcloud
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.
- Sostituisci
Concedi i ruoli al tuo account di servizio worker. Esegui l' questo comando per il ruolo IAM
roles/dataflow.worker
e per tutti i ruoli richiesti dalle risorse usate nel tuo job. Se il tuo account di servizio worker richiede il ruolo Amministratore Dataflow, ripeti questa operazione per il ruolo IAMroles/dataflow.admin
. Questo 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 comandogcloud projects describe
. - Sostituisci
SERVICE_ACCOUNT_ROLE
con ogni singolo ruolo.
- Sostituisci
Accesso 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, utilizzare le risorse rispettivi meccanismi di controllo dell'accesso per concedere esplicitamente l'accesso al progetto Dataflow account di servizio worker.
Se utilizzi le funzionalità di Assured Workloads con Dataflow, come Regioni e assistenza nell'UE con controlli di sovranità, tutto Cloud Storage, BigQuery, Pub/Sub, I/O i connettori e le altre risorse a cui accede la pipeline devono trovarsi della tua organizzazione Progetto o cartella Assured Workloads.
Se utilizzi un account di servizio per i lavoratori gestiti dall'utente o accedi risorse in altri progetti, potrebbero essere necessarie ulteriori azioni. Le seguenti presuppongono che venga utilizzato l'account di servizio predefinito puoi anche usare un account di servizio per il worker gestito dall'utente.
Accedi ai repository Artifact Registry
Quando usare container personalizzati con Dataflow, puoi caricare gli artefatti in un repository Artifact Registry.
Per utilizzare Artifact Registry con Dataflow, devi concedere almeno
Accesso in Writer ad 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à e gestite da Google oppure e chiavi di crittografia gestite dal cliente. Artifact Registry utilizza Chiavi di proprietà di Google e gestite da Google 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 tuo progetto Dataflow account di servizio worker. Come minimo, il tuo servizio account deve disporre delle autorizzazioni di lettura e scrittura sia per il bucket che per il relativo contenuti. Puoi utilizzare la modalità Autorizzazioni IAM per Cloud Storage per concedere l'accesso richiesto.
Per concedere al tuo account di servizio worker le autorizzazioni necessarie per leggere da
e scrivere in un bucket, utilizza
gcloud storage buckets add-iam-policy-binding
. Questo comando aggiunge l'account di servizio del tuo progetto Dataflow
in un criterio 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 tuo bucket Cloud Storage
- PROJECT_NUMBER: il numero del tuo progetto Dataflow. Per trovare il numero del tuo progetto,
consulta Identificare i progetti.
o utilizza
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
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 dai criteri dell'organizzazione che limitano la condivisione delle risorse, puoi accedere a un bucket che risiede in un progetto diverso da quello Dataflow. Per ulteriori informazioni sulle limitazioni dei domini, vedi Limitazione delle identità in base al dominio.
Se non hai un bucket, crea un nuovo bucket. Quindi, concedi al tuo account di servizio worker le autorizzazioni necessarie per leggere da e scrivere nel bucket.
Puoi anche impostare le autorizzazioni del bucket dalla console Google Cloud. Per maggiori informazioni le informazioni, vedi Impostazione delle autorizzazioni del bucket.
Cloud Storage offre due sistemi per concedere agli utenti l'accesso ai tuoi bucket e gli 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 diversi. Per un elenco di ruoli IAM associati per Cloud Storage e le 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 ACL per controllare l'accesso, assicurati che le autorizzazioni dell'account di servizio del worker siano coerenti con le tue impostazioni IAM. A causa dell'incoerenza tra IAM e ACL, il bucket Cloud Storage potrebbe diventano inaccessibili ai tuoi job Dataflow quando Viene eseguita la migrazione del bucket Cloud Storage dall'accesso granulare all'uniforme a livello di bucket. Per ulteriori informazioni, vedi Linee guida sugli errori comuni.
Accedi ai set di dati BigQuery
Puoi utilizzare l'API BigQueryIO
per accedere ai set di dati BigQuery, in
nello stesso progetto in cui stai usando Dataflow o in
progetto. Per BigQuery
origine e sink per funzionare correttamente, i due account seguenti devono disporre dell'accesso
a qualsiasi set di dati BigQuery che il tuo job Dataflow
legge o scrive su:
- L'account Google Cloud che utilizzi per eseguire Dataflow offerta di lavoro
- L'account di servizio worker che esegue Job Dataflow
Potresti dover configurare BigQuery in modo da concedere esplicitamente l'accesso a questi account. Vedi Controllo degli accessi BigQuery per ulteriori informazioni su come concedere l'accesso ai set di dati BigQuery usando la pagina BigQuery o l'API BigQuery.
Tra le autorizzazioni BigQuery richieste,
la pipeline richiede l'autorizzazione IAM bigquery.datasets.get
per accedere a un set di dati BigQuery. In genere, la maggior parte
I ruoli IAM di BigQuery includono
bigquery.datasets.get
, ma il ruolo roles/bigquery.jobUser
è un'eccezione.
Accedere ad argomenti e sottoscrizioni Pub/Sub
Per accedere a un nell'argomento o nella sottoscrizione Pub/Sub, utilizza Funzionalità di Identity and Access Management di Pub/Sub per configurare autorizzazioni per l'account di servizio worker.
Autorizzazioni dagli utenti che seguono I ruoli Pub/Sub sono pertinenti:
roles/pubsub.subscriber
è obbligatorio per consumare dati.roles/pubsub.editor
è obbligatorio per creare un sottoscrizione Pub/Sub.roles/pubsub.viewer
è consigliato per Dataflow può eseguire query sulle configurazioni argomenti e sottoscrizioni. Questa configurazione presenta due vantaggi:- Dataflow può controllare le impostazioni non supportate sugli abbonamenti che potrebbero non funzionare come previsto.
- Se l'abbonamento non utilizza la scadenza ACK predefinita
di 10 secondi, le prestazioni migliorano. Dataflow: più volte
estende la scadenza di conferma per un messaggio mentre viene elaborato
una pipeline o un blocco note personalizzato. Senza autorizzazioni
pubsub.viewer
, Dataflow non è in grado di eseguire query sulla scadenza di conferma e deve quindi presupporre un la scadenza del periodo di conservazione. Questa configurazione determina un aumento dei problemi di Dataflow modifyAckDeadline più richieste del dovuto. - Se i Controlli di servizio VPC sono abilitati nel progetto proprietario un abbonamento o un argomento, le regole di traffico in entrata basate su indirizzi IP non consentono Dataflow per eseguire query sulle configurazioni. In questo caso, È necessaria una regola in entrata basata sull'account di servizio worker.
Per ulteriori informazioni e alcuni esempi di codice che dimostrano come utilizzare le funzionalità di Identity and Access Management di Pub/Sub, Caso d'uso di esempio: comunicazione tra progetti.
Accedi a Firestore
Per accedere a un database Firestore (in modalità Native o
modalità Datastore), aggiungi il tuo account di servizio worker Dataflow
(ad es. 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.
Accedi alle immagini per i progetti con un criteri per l'utilizzo di immagini attendibili
Se hai norme relative alle immagini attendibili
per il tuo progetto e l'immagine di avvio si trova in un'altra
assicurati che il criteri per l'utilizzo di immagini attendibili sia configurato per avere accesso all'immagine.
Ad esempio, se esegui un job Dataflow basato su modelli, assicurati che
il file del criterio include l'accesso al progetto dataflow-service-producer-prod
.
Questo progetto Google Cloud contiene le immagini per i job modello.
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. R la pipeline tipica legge i dati da una o più origini, implementa trasformazioni dei dati e scrive i risultati in uno o più sink. Tutti le origini e i sink sono servizi di archiviazione e Dataflow.
Dati operativi. Questi dati includono tutti i metadati necessari per la gestione di una pipeline Dataflow. Questi dati includono i metadati forniti dall'utente come il nome di un job o le opzioni della pipeline, nonché metadati generati dal sistema come un ID job.
Il servizio Dataflow utilizza diversi meccanismi di sicurezza per la privacy e la sicurezza dei dati. Questi meccanismi si applicano ai seguenti scenari:
- Invio di una pipeline al servizio
- Valutazione di una pipeline
- Richiesta di accesso a telemetria e metriche durante e dopo una pipeline esecuzione
- Utilizzo di un servizio Dataflow come Shuffle o Streaming Engine
Località di dati
L'elaborazione dei dati principali per il servizio Dataflow avviene in
la regione specificata nel codice della pipeline. Se non viene specificata una regione,
viene utilizzata la regione predefinita us-central1
. Se specifichi questa opzione nel
il codice della pipeline, il job della pipeline può facoltativamente leggere e scrivere da origini
in altre regioni. Tuttavia, l'elaborazione effettiva dei dati avviene solo nella regione
specificato per eseguire le VM Dataflow.
La logica della pipeline viene valutata su singole istanze VM worker. Puoi specificare in cui le istanze e la rete privata su cui comunicare. I calcoli accessori per la piattaforma dipendono come posizioni o dimensioni dei file di Cloud Storage.
Dataflow è un servizio a livello di regione. Per ulteriori informazioni sui dati località e regioni, consulta Regioni di Dataflow.
Dati nell'invio di una pipeline
Le autorizzazioni IAM per il tuo progetto Google Cloud controllano l'accesso dal servizio Dataflow. Tutte le entità a cui è stato assegnato un editor o un proprietario per il tuo progetto possono inviare pipeline al servizio. Per inviare pipeline, devi utilizzando Google Cloud CLI. Una volta eseguita l'autenticazione, le pipeline vengono inviate usando il protocollo HTTPS. Per istruzioni su come eseguire l'autenticazione con le credenziali del tuo account Google Cloud, consulta guida rapida per la lingua che stai utilizzando.
Valutazione dei dati in una pipeline
Nell'ambito della valutazione di una pipeline, potrebbero essere generati e archiviati dati temporanei localmente nelle istanze VM worker o in Cloud Storage. Dati temporanei è criptato at-rest e non persiste al termine della valutazione della pipeline. Questi dati possono essere archiviati anche nel servizio Shuffle o Streaming Engine (se hai scelto il servizio) nella stessa regione specificata nelle Dataflow.
Java
Per impostazione predefinita, le VM di Compute Engine vengono eliminate quando
Il job Dataflow viene completato, indipendentemente dal fatto che
il job ha esito positivo o negativo. Di conseguenza, gli elementi associati
Persistent Disk ed eventuali dati intermedi che potrebbero essere archiviati
vengono eliminati. I dati intermedi archiviati in Cloud Storage possono essere trovati in località secondarie di
il percorso Cloud Storage che fornisci come --stagingLocation
--tempLocation
. Se stai scrivendo l'output in un file Cloud Storage, i file temporanei
potrebbe essere creato nel percorso di output prima che l'operazione di scrittura venga finalizzata.
Python
Per impostazione predefinita, le VM di Compute Engine vengono eliminate quando
Il job Dataflow viene completato, indipendentemente dal fatto che
il job ha esito positivo o negativo. Di conseguenza, gli elementi associati
Persistent Disk ed eventuali dati intermedi che potrebbero essere archiviati
vengono eliminati. I dati intermedi archiviati in Cloud Storage possono essere trovati in località secondarie di
il percorso Cloud Storage che fornisci come --staging_location
--temp_location
. Se stai scrivendo l'output in un file Cloud Storage, i file temporanei
potrebbe essere creato nel percorso di output prima che l'operazione di scrittura venga finalizzata.
Vai
Per impostazione predefinita, le VM di Compute Engine vengono eliminate quando
Il job Dataflow viene completato, indipendentemente dal fatto che
il job ha esito positivo o negativo. Di conseguenza, gli elementi associati
Persistent Disk ed eventuali dati intermedi che potrebbero essere archiviati
vengono eliminati. I dati intermedi archiviati in Cloud Storage possono essere trovati in località secondarie di
il percorso Cloud Storage che fornisci come --staging_location
--temp_location
. Se stai scrivendo l'output in un file Cloud Storage, i file temporanei
potrebbe essere creato nel percorso di output prima che l'operazione di scrittura venga finalizzata.
Dati nei log e nella telemetria della pipeline
Le informazioni archiviate in Cloud Logging sono principalmente generati dal codice nel tuo programma Dataflow. La Il servizio Dataflow può anche generare dati di avviso ed errore in Cloud Logging, ma questi sono gli unici dati intermedi che il servizio vengono aggiunte ai log. Cloud Logging è un servizio globale.
I dati di telemetria e le metriche associate sono criptati at-rest e l'accesso a questo i dati sono controllati 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 di zona. Specifica invece la regione e imposta il valore su una delle regioni in cui vengono disponibili. Dataflow seleziona automaticamente la zona nella regione da te specificati. I dati in transito dell'utente finale rimangono all'interno delle VM worker nella stessa zona. Questi job Dataflow possono ancora leggere e scrivere di origini e sink che si trovano all'esterno della zona VM. I dati in transito possono anche essere inviati a Dataflow Shuffle o Dataflow Streaming servizi, ma i dati rimangono sempre nella regione specificata del codice della pipeline.
Pratica consigliata
Ti consigliamo di utilizzare i meccanismi di sicurezza disponibili nel alle risorse cloud sottostanti della tua pipeline. Questi meccanismi includono il monitoraggio Funzionalità di sicurezza di origini dati e sink come BigQuery e Cloud Storage. Inoltre, è meglio non combinare diversi livelli di attendibilità un singolo progetto.