Controlli di servizio VPC - Protezione di BigQuery Data Transfer Service

1. Introduzione

In questo lab apprenderemo come proteggere BigQuery Data Transfer Service utilizzando Controlli di servizio VPC durante il trasferimento dei dati da Cloud Storage a un set di dati BigQuery. Poi proteggiamo Cloud Storage e ripetiamo la procedura per trasferire i dati da Cloud Storage a BigQuery. La protezione di Cloud Storage causa una violazione dei Controlli di servizio VPC, che deve essere corretta per il trasferimento. Alla fine, proteggiamo anche BigQuery e poi tentiamo di copiare il set di dati tra i progetti, il che causa anche una violazione che deve essere corretta.

In questo lab vedremo come correggere le violazioni in entrata e in uscita utilizzando rispettivamente le regole in entrata e in uscita. Utilizzeremo anche un livello di accesso per correggere la violazione di BigQuery Data Transfer in entrata. Gli obiettivi di questo codelab sono:

• Scopri come correggere le violazioni in entrata e in uscita utilizzando rispettivamente le regole in entrata e in uscita su diversi servizi, in particolare Cloud Storage, BigQuery e BigQuery Data Transfer Service.
• Scopri perché si è verificata una violazione specifica.

2. Configurazione e requisiti delle risorse

Prima di iniziare

In questo codelab, presupponiamo che tu sappia già:

• Come creare una cartella
• Come creare un progetto in una cartella o spostare un progetto esistente in una cartella
• Come creare un criterio di accesso basato sugli ambiti
• Come creare e configurare un perimetro di servizio dalla console Google Cloud
• Come trovare i log delle violazioni dagli audit log

Questi prerequisiti sono stati trattati in altri codelab di VPC Service Controls: Tutorial di base sui Controlli di servizio VPC I e Tutorial di base sui Controlli di servizio VPC II - Risoluzione dei problemi di violazione di uscita.

Configurazione

La nostra configurazione iniziale è progettata come segue:

• Un'organizzazione Google Cloud.
• Una cartella in Organizzazione. Per questo codelab, lo chiameremo codelab-folder.
• Due progetti Google Cloud nella cartella codelab-folder. Per questo codelab, chiamiamo i progetti project-1 e project-2.
  • Se la cartella e i progetti non sono già stati creati, nella console Google Cloud, crea una cartella in Organizzazione e crea due nuovi progetti.
• Le autorizzazioni richieste: ruoli IAM per la gestione delle cartelle, ruoli IAM per la gestione dei progetti, ruoli IAM necessari per configurare i Controlli di servizio VPC, ruoli IAM per la gestione di BigQuery e ruoli IAM per la gestione di Cloud Storage.
• Account di fatturazione per entrambi i progetti project-1 e project-2.

Per questo codelab, puoi concederti i seguenti ruoli predefiniti: Amministratore cartelle e Creator di progetti (a livello di cartella), Proprietario (a livello di progetto), Amministratore BigQuery (a livello di progetto), Amministratore oggetti archiviazione (a livello di progetto) e Amministratore Gestore contesto accesso (a livello di organizzazione). Avrai i ruoli necessari per configurare le risorse necessarie per l'intero codelab.

Crea un criterio basato su ambito e un perimetro di servizio regolare

In questo codelab utilizzeremo un perimetro di servizio regolare che protegge project-2.

• Crea un criterio di accesso basato sugli ambiti, che ha come ambito il livello della cartella codelab-folder. Per questo codelab, assumiamo che il criterio di accesso creato abbia l'ID 987654321.
• Crea un perimetro normale, che chiameremo perimeter-2, e aggiungi il progetto project-2.

Nel perimetro perimeter-2, limita BigQuery Data Transfer API.

Creazione del bucket Cloud Storage e del set di dati BigQuery

Ai fini di questo codelab, è sufficiente qualsiasi file CSV, indipendentemente dai contenuti. La limitazione principale riguarda il requisito di co-locazione che impone che:

• Se il set di dati BigQuery si trova in una regione multipla, il bucket Cloud Storage contenente i dati che stai trasferendo deve trovarsi nella stessa regione multipla o in una posizione inclusa nella regione multipla
• Se il set di dati si trova in una regione, il bucket Cloud Storage deve trovarsi nella stessa regione.

Da questo momento in poi, per questo codelab ci assicureremo che sia il bucket Cloud Storage sia il set di dati BigQuery si trovino nella stessa regione o nella stessa località a più regioni.

Crea un nuovo bucket Cloud Storage nel progetto project-1

Per questo codelab, utilizzeremo Cloud Storage come origine dati, che è un'origine dati supportata per BigQuery Data Transfer Service.

Per creare un nuovo bucket Cloud Storage, segui i passaggi descritti per la creazione di un nuovo bucket.

• Per il nome del bucket, inserisci un nome che soddisfi i requisiti per i nomi dei bucket. Per questo codelab, chiameremo il bucket codelab-bqtransfer-bucket.
• Per la posizione in cui archiviare i dati, seleziona un Tipo di località e una Località in cui i dati del bucket verranno archiviati in modo permanente. Per questo codelab, utilizzeremo us (più regioni negli Stati Uniti).

Creare un file CSV

Se hai già un file CSV di esempio, puoi saltare questo passaggio.

Dalla tua macchina locale o utilizzando Cloud Shell, possiamo utilizzare il comando echo per creare un file CSV di esempio, codelab-test-file.csv, utilizzando i seguenti comandi:

echo "name,age" > codelab-test-file.csv; \
echo "Alice,10" >> codelab-test-file.csv; \
echo "Bob,20" >> codelab-test-file.csv; \
echo "Carol,30" >> codelab-test-file.csv; \
echo "Dan,40" >> codelab-test-file.csv; \
echo "Eve,50" >> codelab-test-file.csv; \
echo "Frank,60" >> codelab-test-file.csv; \
echo "Grace,70" >> codelab-test-file.csv; \
echo "Heidi,80" >> codelab-test-file.csv;

Carica il file CSV nel bucket Cloud Storage

Una volta creato il file CSV, esegui il seguente comando per caricare l'oggetto file nel bucket creato:

gcloud storage cp codelab-test-file.csv gs://codelab-bqtransfer-bucket

Puoi verificare che il file sia stato caricato nel bucket creato elencando gli oggetti nel bucket o eseguendo il seguente comando:

gcloud storage ls --recursive gs://codelab-bqtransfer-bucket/**

Creare un set di dati e una tabella BigQuery in project-2

1. Crea un set di dati BigQuery nel progetto project-2 seguendo questi passaggi.
   1. In ID set di dati, inserisci un nome univoco per il set di dati. Per questo codelab, utilizziamo: codelab_bqtransfer_dataset.
   2. Per Tipo di località, scegli una località geografica per il set di dati. Per questo codelab, utilizziamo la stessa località del bucket Cloud Storage: US (più regioni negli Stati Uniti).
2. Crea una tabella BigQuery nel set di dati codelab_bqtransfer_dataset creato seguendo questi passaggi.
   1. Nella sezione Origine, seleziona Tabella vuota nell'elenco Crea tabella da.
   2. Nel campo Table (Tabella), inserisci il nome della tabella che vuoi creare. Per questo codelab, utilizziamo il nome codelab-bqtransfer-table.
   3. Verifica che il campo Tipo di tabella sia impostato su Tabella nativa.
   4. Nella sezione Schema, inserisci la definizione dello schema. Puoi inserire le informazioni dello schema facendo clic su Modifica come testo e inserendo lo schema seguente, conforme al formato del file CSV creato.

   [{
   "name": "name",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The name"
   },
   {
   "name": "age",
   "type": "INTEGER",
   "mode": "NULLABLE",
   "description": "The age"
   }]
   

Costo

Per utilizzare le API/risorse Cloud, devi attivare la fatturazione nei progetti project-2 e project-1. Ti consigliamo di arrestare le risorse utilizzate per evitare di incorrere in fatturazione oltre questo codelab.

I nuovi utenti di Google Cloud sono idonei al programma di prova senza costi di 300 $.

Le risorse che generano il costo sono BigQuery e Cloud Storage. Puoi trovare un costo stimato nel Calcolatore prezzi di BigQuery e nel Calcolatore di Cloud Storage.

3. Configurare il trasferimento dei dati dall'oggetto Cloud Storage alla tabella BigQuery

Ora proveremo a creare un servizio di trasferimento dati (in project-2) per trasferire i dati da Cloud Storage (in project-1) a BigQuery (in project-2), mantenendo al contempo VPC Service Controls per proteggere BigQuery Data Transfer Service in project-2. La protezione solo di BigQuery Data Transfer Service (senza proteggere anche BigQuery e Cloud Storage) limita i principali a creare e gestire solo i trasferimenti di dati (ad esempio l'avvio manuale di un trasferimento di dati).

Configurare il trasferimento dei dati da Cloud Storage

Per creare un trasferimento di dati:

1. Vai alla pagina BigQuery nella console Google Cloud di project-2.
2. Fai clic su Trasferimenti di dati.

Dovrebbe verificarsi una violazione dei Controlli di servizio VPC, poiché il perimetro perimeter-2 protegge BigQuery Data Transfer Service in project-2. L'accesso deve essere consentito da Controlli di servizio VPC prima di poter configurare il trasferimento dei dati.

Esaminare la violazione durante l'accesso alla pagina Trasferimenti di dati

Nella console Google Cloud, possiamo vedere l'identificatore univoco di Controlli di servizio VPC. Utilizza lo stesso identificatore per filtrare i log e identificare i dettagli della violazione (sostitui OBSERVED_VPCSC_DENIAL_UNIQUE_ID con l'ID rifiuto osservato):

protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="OBSERVED_VPCSC_DENIAL_UNIQUE_ID"

La violazione osservata è una NO_MATCHING_ACCESS_LEVEL, ovvero una violazione di accesso con dettagli simili ai seguenti:

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
}]
violationReason: "NO_MATCHING_ACCESS_LEVEL"
callerIp: "USER_PUBLIC_IP_ADDRESS"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.ListTransferConfigs"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}

L'accesso alla pagina Trasferimenti di dati tenta di elencare tutti i trasferimenti di dati configurati; di conseguenza, si verifica la violazione del metodo ListTransferConfigs.

Correggere la violazione per il servizio bigquerydatatransfer.googleapis.com

Per correggere una violazione in entrata, puoi utilizzare un livello di accesso o una regola in entrata. In questo codelab, utilizziamo una regola di ingresso configurata con l'identità utente negata, che consente l'accesso al servizio bigquerydatatransfer.googleapis.com e a tutti i metodi.

Una volta impostata la regola di ingresso, l'accesso alla pagina Trasferimenti di dati dovrebbe funzionare senza problemi.

Riprendi la configurazione del trasferimento dei dati da Cloud Storage

Dalla pagina Trasferimenti di dati (dopo aver fatto clic su Trasferimenti di dati), continua con i seguenti passaggi:

1. Fai clic su + Crea trasferimento.
2. Nella sezione Tipo di origine, per Origine, scegli Google Cloud Storage.
3. Nella sezione Nome configurazione di trasferimento, per Nome visualizzato, inserisci un nome per il trasferimento, ad esempio Codelab Transfer.
4. Nella sezione Opzioni di pianificazione:
   1. Seleziona una Frequenza di ripetizione, ad esempio 15 minuti.
   2. Assicurati di selezionare Inizia ora, altrimenti il trasferimento dei dati inizierà solo dopo la Frequenza di ripetizione configurata.
5. Nella sezione Impostazioni destinazione, in Set di dati di destinazione, scegli il set di dati che hai creato per archiviare i dati: codelab_bqtransfer_dataset
6. Nella sezione Dettagli origine dati
   1. In Tabella di destinazione, inserisci il nome della tabella di destinazione. La tabella di destinazione deve rispettare le regole di denominazione delle tabelle. Per questo codelab, utilizzeremo la tabella creata in precedenza: codelab-bqtransfer-table
   2. In URI Cloud Storage, inserisci l'URI Cloud Storage. Per questo codelab, utilizziamo il bucket e il file creati: codelab-bqtransfer-bucket/codelab-test-file.csv
   3. Per Preferenza di scrittura, mantieni APPEND (o scegli MIRROR).
   4. NON selezionare l'eliminazione dei file dopo il trasferimento, perché riutilizzeremo lo stesso file più volte. Tuttavia, puoi utilizzare più file ed eliminare i file di origine dopo il trasferimento.
   5. Per Formato file, seleziona CSV.
   6. In Opzioni di trasferimento, in CSV, inserisci virgola(",") come Separatore di campi.
7. Nel menu Account di servizio, seleziona un account di servizio tra quelli associati al tuo progetto Google Cloud
   1. L'account di servizio selezionato deve disporre delle autorizzazioni richieste sia per Cloud Storage nel progetto che ospita il bucket di archiviazione; project-1 in questo codelab.
   2. Per questo codelab, utilizzeremo un account di servizio creato in project-2 come [e-mail].
8. Fai clic su Salva.

Poiché abbiamo selezionato Inizia ora come opzione di pianificazione, il primo trasferimento inizierà non appena verrà selezionato Salva.

L'account di servizio specificato nella configurazione di Data Transfer verrà utilizzato per accedere all'oggetto bucket Cloud Storage. Per ogni tentativo di trasferimento dei dati, i log in project-1 (il progetto di origine) devono mostrare una voce di log dell'account di servizio che esegue la chiamata storage.objects.get (serviceName: "storage.googleapis.com") sull'oggetto in fase di trasferimento. D'altra parte, quando controlli i log in project-2, che ospita la tabella BigQuery di destinazione, scoprirai che è l'agente BigQuery Data Transfer Service a scrivere i dati (serviceName: 'bigquery.googleapis.com') dall'oggetto di archiviazione alla tabella BigQuery specificata.

Verificare lo stato del servizio di trasferimento dei dati

Per verificare lo stato del trasferimento di dati configurato:

• Vai alla pagina BigQuery nella console Google Cloud.
• Fai clic su Trasferimenti di dati.
• Viene visualizzato l'elenco dei trasferimenti configurati

Fai clic su Codelab Transfer (sotto Nome visualizzato) per visualizzare un elenco di tutte le esecuzioni eseguite fino a quel momento.

L'esecuzione del trasferimento dei dati dovrebbe essere riuscita, senza violazioni di VPC Service Controls sia per il trasferimento dei dati pianificato sia per quello attivato manualmente. Tieni presente che solo il trasferimento attivato manualmente richiede la regola di ingresso per consentire l'accesso al principale, che avvia il trasferimento manualmente.

4. Limitazioni degli indirizzi IP per i trasferimenti di dati attivati manualmente

Le regole di ingresso attualmente configurate consentono all'identità configurata di attivare manualmente il trasferimento dei dati da qualsiasi indirizzo IP.

Con l'utilizzo del livello di accesso, Controlli di servizio VPC offre la possibilità di limitare l'accesso consentito in base a attributi specifici della richiesta API, in particolare:

• Sottoreti IP: controlla se la richiesta proviene da un indirizzo IP specifico.
• Regioni: controlla se la richiesta proviene da una regione specifica, determinata dalla geolocalizzazione dell'indirizzo IP.
• Principali: controlla se la richiesta proviene da un account specifico.
• Criteri relativi ai dispositivi: controlla se la richiesta proviene da un dispositivo che soddisfa requisiti specifici.

Per applicare la verifica di questi attributi insieme alla regola di ingresso già configurata, dobbiamo creare un livello di accesso che consenta gli attributi desiderati, quindi aggiungere il livello di accesso creato come origine nella regola di ingresso.

Questo diagramma illustra l'accesso avviato dai due principali ([e-mail] e [e-mail]) in tre scenari, dimostrando in che modo i Controlli di servizio VPC valutano le origini (livello di accesso in entrata) e gli attributi di identità come una condizione AND in cui entrambi devono corrispondere.

1. All'utente [e-mail] viene consentito l'accesso quando tenta di accedere da un indirizzo IP consentito dal livello di accesso, perché il suo indirizzo IP e il suo account utente corrispondono alle configurazioni nella regola di ingresso.
2. L'accesso dell'utente [e-mail] viene bloccato quando il suo indirizzo IP non corrisponde a quello consentito, nonostante il suo account sia quello configurato nella regola di ingresso.
3. L'accesso all'utente [e-mail] è bloccato nonostante abbia tentato di accedere da un indirizzo IP consentito, perché il suo account non è consentito dalla regola di ingresso.

Crea livello di accesso

Per creare un livello di accesso che limita l'accesso in base all'indirizzo IP:

1. Apri la pagina Gestore contesto accesso nella console Google Cloud.
   • Se richiesto, seleziona la cartella codelab-folder.
2. Nella parte superiore della pagina Gestore contesto accesso, fai clic su CREA LIVELLO DI ACCESSO.
3. Nel riquadro Nuovo livello di accesso, assegna un titolo al nuovo livello di accesso. Per questo codelab, lo chiameremo project_2_al.
4. Nella sezione Condizioni, fai clic su + davanti a Subnet IP.
5. Nella casella Subnet IP, seleziona IP pubblico.
   • In alternativa, puoi selezionare l'utilizzo di IP privato per utilizzare l'indirizzo IP interno nei livelli di accesso. Tuttavia, per questo codelab utilizziamo un indirizzo IP pubblico.
   • Inserisci uno o più intervalli IPv4 o IPv6 formattati come blocchi CIDR.

I log delle violazioni di Controlli di servizio VPC mostreranno l'indirizzo IP pubblico dell'utente, a meno che l'accesso non sia stato eseguito da un'istanza Compute Engine senza indirizzo IP esterno.

Aggiungere il livello di accesso nella regola in entrata

All'interno della regola di ingresso, il livello di accesso viene fatto riferimento nel campo sources, che è un campo obbligatorio come descritto nella sezione Riferimento alla regola di ingresso. Per consentire l'accesso alle risorse, i Controlli di servizio VPC valutano gli attributi sources e identityType come una condizione AND. La regola di ingresso utilizza l'identità del principale che attiva manualmente il trasferimento dei dati, non l'account di servizio specificato nella configurazione del trasferimento dei dati.

Esegui di nuovo il trasferimento con le configurazioni che limitano l'accesso in base all'indirizzo IP

Per valutare l'efficacia delle configurazioni applicate, attiva di nuovo il trasferimento utilizzando i seguenti scenari:

• utilizzando l'indirizzo IP nell'intervallo consentito nel livello di accesso a cui fa riferimento la regola di ingresso.
• utilizzo di un indirizzo IP non consentito dalle configurazioni

L'accesso dall'indirizzo IP consentito dovrebbe essere corretto, mentre l'accesso dagli indirizzi IP non consentiti dovrebbe non riuscire e comportare una violazione dei Controlli di servizio VPC.

Un modo semplice per eseguire il test utilizzando un indirizzo IP diverso è consentire l'indirizzo IP assegnato durante l'utilizzo della console Google Cloud e poi eseguire il test utilizzando Cloud Shell.

In Cloud Shell, esegui il seguente comando per attivare manualmente un trasferimento, sostituendo sia RUN_TIME che RESOURCE_NAME:

bq mk \
  --transfer_run \
  --run_time='RUN_TIME' \
  RESOURCE_NAME

Ad esempio, il seguente comando di esempio viene eseguito immediatamente per una configurazione di trasferimento 12345678-90ab-cdef-ghij-klmnopqrstuv nel progetto 1234567890.

NOW=$(TZ=GMT date +"%Y-%m-%dT%H:%M:%SZ");
bq mk \
  --transfer_run \
  --run_time=$NOW \
  projects/1234567890/locations/us/transferConfigs/12345678-90ab-cdef-ghij-klmnopqrstuv

L'output osservato mostra una violazione dei Controlli di servizio VPC, come previsto, poiché l'indirizzo IP non è consentito.

La violazione osservata riguarda il metodo DataTransferService.StartManualTransferRuns.

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
targetResourcePermissions: [0: "vpcsc.permissions.unavailable"]
}]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.StartManualTransferRuns"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"

5. Avvio del trasferimento dei dati durante la protezione del servizio Cloud Storage

Poiché stiamo eseguendo un trasferimento da Cloud Storage a BigQuery, aggiungiamo Cloud Storage tra i servizi protetti da Controlli di servizio VPC e vediamo se il trasferimento continua a essere riuscito.

Nella configurazione perimeter-2, aggiungi l'API Cloud Storage come uno dei servizi con limitazioni, insieme all'API BigQuery Data Transfer.

Dopo aver protetto l'API Cloud Storage, attendi il prossimo trasferimento di dati pianificato o attiva manualmente un trasferimento seguendo questi passaggi:

1. Vai alla pagina BigQuery nella console Google Cloud.
2. Fai clic su Trasferimenti di dati.
3. Seleziona il trasferimento dall'elenco: per questo codelab utilizziamo il trasferimento Codelab Transfer
4. Fai clic su Esegui ora il trasferimento.
5. Fai clic su OK.

Verrà avviato un altro trasferimento. Potresti dover aggiornare la pagina per visualizzarla. Questa volta il trasferimento non andrà a buon fine a causa di una violazione dei Controlli di servizio VPC.

Esaminare la violazione dei Controlli di servizio VPC di Cloud Storage

Filtra i log di controllo utilizzando vpcServiceControlsUniqueIdentifier come indicato nel riepilogo del trasferimento.

La violazione osservata è una violazione di RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER in uscita con i seguenti dettagli:

• L'entità è l'account di servizio configurato nel servizio di trasferimento dati (indipendentemente dal fatto che sia stato attivato manualmente o che sia in esecuzione il trasferimento pianificato dei dati, l'entità rifiutata sarà la stessa).
• Il servizio interessato è Cloud Storage
• L'origine della richiesta è il progetto in cui è configurato Data Transfer Service: project-2
• Il progetto di destinazione è il progetto in cui si trova l'oggetto Cloud Storage: project-1

principalEmail: "[e-mail]"
egressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
source: "projects/[PROJECT2_NUMBER]"
sourceType: "Resource"
targetResource: "projects/[PROJECT1_NUMBER]"
targetResourcePermissions: [0: "storage.objects.get"]
}]
labels: {
method: "google.storage.objects.get"
project_id: "project-2"
service: "storage.googleapis.com"
}

Correggere la violazione del traffico in uscita di Cloud Storage

Per correggere la violazione in uscita, dobbiamo utilizzare una regola in uscita che consenta il traffico dall'account di servizio negato al progetto con oggetti Cloud Storage.

Dopo aver modificato il perimetro del servizio perimeter-2, ripeti la procedura per attivare di nuovo il trasferimento. Il trasferimento non mostrerà un errore.

6. Copia il set di dati BigQuery da project-2 a project-1

Dopo aver verificato che possiamo trasferire i dati dal bucket Cloud Storage in project-1 al set di dati BigQuery in project-2, copiamo il set di dati BigQuery da project-2 a project-1. L'API BigQuery è protetta dai Controlli di servizio VPC.

Per creare e copiare il set di dati, utilizzeremo il comando bq mk, che utilizza lo strumento bq.

BigQuery utilizza BigQuery Data Transfer Service nel backend per copiare i set di dati.

Crea il set di dati di destinazione in project-1

Prima di copiare il set di dati, devi creare il set di dati di destinazione. Per creare il set di dati di destinazione, possiamo eseguire il seguente comando, che crea un set di dati denominato copied_dataset nel progetto project-1 con us come posizione.

bq mk \
  --dataset \
  --location=us \
  project-1:copied_dataset

Proteggere il servizio BigQuery in project-2 con i Controlli di servizio VPC

Modifica la configurazione del perimetro perimeter-2 e aggiungi l'API BigQuery come servizio protetto, insieme ai servizi BigQuery Data Transfer e Cloud Storage.

Avvia la copia del set di dati

Per copiare il set di dati, esegui il seguente comando bq mk, che copia il set di dati codelab_bqtransfer_dataset nel progetto project-2 nel set di dati copied_dataset in project-1 e sovrascrive i contenuti del set di dati, se presenti.

bq mk \
  --transfer_config \
  --project_id=project-1 \
  --target_dataset=copied_dataset \
  --data_source=cross_region_copy \
  --display_name='Dataset from project-2 to project-1' \
  --params='{
     "source_dataset_id":"codelab_bqtransfer_dataset",
     "source_project_id":"project-2",
     "overwrite_destination_table":"true"
     }'

Il comando verrà eseguito correttamente. Nel frattempo, la configurazione del trasferimento viene creata correttamente per avviare l'operazione di copia del set di dati. La copia del set di dati stesso non andrà a buon fine, con una violazione dei Controlli di servizio VPC.

Per trovare i dettagli della violazione di VPC Service Controls corrispondenti, controlla i log in project-2 (progetto del set di dati di origine) con la seguente query sul log. La query sui log filtra i log in base al servizio BigQuery e al nome della risorsa del set di dati da copiare (codelab_bqtransfer_dataset).

resource.labels.service="bigquery.googleapis.com"
protoPayload.metadata.resourceNames:"datasets/codelab_bqtransfer_dataset"

La violazione dei Controlli di servizio VPC osservata è una violazione in uscita da project-2 a project-1.

egressViolations: [
  0: {
   servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
   source: "projects/[PROJECT-2-NUMBER]"
   sourceType: "Resource"
   targetResource: "projects/[PROJECT-1-NUMBER]"
   targetResourcePermissions: [
     0: "bigquery.transfers.update"
     1: "bigquery.transfers.get"
     2: "bigquery.jobs.create"
     ]
   }
]
method: "bigquery.tables.getData"
service: "bigquery.googleapis.com"

Correggi tutte le violazioni di BigQuery e avvia di nuovo la copia del set di dati

Quando esegui una copia di un set di dati BigQuery tra progetti che non si trovano nello stesso perimetro di servizio, la regola di entrata/uscita deve attualmente consentire tutti i metodi per il funzionamento del processo. Questo comportamento potrebbe cambiare in futuro; gli aggiornamenti possono essere monitorati nello issue tracker pubblico.

Per correggere la violazione in uscita, dobbiamo creare una regola in uscita che consenta il principale negato. L'entità negata è quella che esegue il comando mk.

Una volta impostata la regola di uscita, esegui lo stesso comando sul perimetro perimeter-2 per copiare il set di dati. Questa volta, il set di dati dovrebbe essere copiato correttamente senza violazioni dei Controlli di servizio VPC.

7. Esegui la pulizia

Sebbene non siano previsti addebiti separati per l'utilizzo dei Controlli di servizio VPC quando il servizio non è in uso, è buona prassi ripulire la configurazione utilizzata in questo laboratorio. Puoi anche eliminare l'istanza VM e/o i progetti Cloud per evitare addebiti. L'eliminazione del progetto Cloud interrompe la fatturazione per tutte le risorse utilizzate al suo interno.

• Per eliminare il bucket Cloud Storage, completa i seguenti passaggi:
  • Nella console Google Cloud, vai alla pagina Bucket Cloud Storage.
  • Seleziona la casella di controllo del bucket da eliminare e poi fai clic su Elimina.
  • Nella finestra in overlay visualizzata, conferma di voler eliminare il bucket e i relativi contenuti.
• Per eliminare il set di dati BigQuery, completa i seguenti passaggi:
  • Nella console Google Cloud, vai alla pagina BigQuery.
  • Nel riquadro Explorer, espandi il progetto e seleziona un set di dati.
  • Espandi il menu con tre puntini e fai clic su Elimina.
  • Nella finestra di dialogo Elimina set di dati, digita delete nel campo e fai clic su Elimina.
• Per eliminare il perimetro di servizio, completa i seguenti passaggi:
  • Nella console Google Cloud, seleziona Sicurezza e poi Controlli di servizio VPC a livello di ambito del criterio di accesso, in questo caso a livello di cartella.
  • Nella pagina Controlli di servizio VPC, seleziona Delete Icon nella riga della tabella corrispondente al perimetro che vuoi eliminare.
• Per eliminare il livello di accesso, completa i seguenti passaggi:
  • Nella console Google Cloud, apri la pagina Gestore contesto accesso a livello di ambito Cartella.
  • Nella griglia, identifica la riga del livello di accesso che vuoi eliminare, seleziona il menu con tre puntini e poi Elimina.
• Per arrestare i progetti, completa i seguenti passaggi:
  • Nella console Google Cloud, vai alla pagina IAM e amministrazione > Impostazioni del progetto che vuoi eliminare.
  • Nella pagina Impostazioni IAM e amministrazione, seleziona Chiudi.
  • Inserisci l'ID progetto e seleziona Chiudi comunque.

8. Complimenti!

In questo codelab hai creato un perimetro dei Controlli di servizio VPC, lo hai applicato e ne hai risolto i problemi.

Scopri di più

Puoi anche esplorare i seguenti scenari:

• Aggiungi project-1 in un perimetro diverso che protegge anche BigQuery, BigQuery Data Transfer Service e Cloud Storage.
• Esegui il trasferimento dei dati di BigQuery da altre origini supportate.
• Limita l'accesso degli utenti in base ad altri attributi, come la posizione o i criteri del dispositivo.

Licenza

Questo lavoro è concesso in licenza ai sensi di una licenza Creative Commons Attribution 2.0 Generic.