Controlli di servizio VPC - Protezione di BigQuery Data Transfer Service

1. Introduzione

In questo lab impareremo a proteggere BigQuery Data Transfer Service utilizzando i controlli di servizio VPC durante il trasferimento dei dati da Cloud Storage a un set di dati BigQuery. Proteggiamo quindi 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 riuscito. Infine, 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 dell'ingresso di BigQuery Data Transfer. Gli obiettivi di questo codelab sono:

• Scopri come correggere le violazioni del traffico in entrata e in uscita utilizzando rispettivamente le regole di traffico in entrata e in uscita su diversi servizi, in particolare Cloud Storage, BigQuery e BigQuery Data Transfer Service.
• Comprendere il motivo di 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 una policy di accesso con ambito
• 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 sui Controlli di servizio VPC: Tutorial di base I sui Controlli di servizio VPC e Tutorial di base II sui Controlli di servizio VPC: risoluzione dei problemi relativi alla violazione del traffico in uscita.

Configurazione

La nostra configurazione iniziale è progettata nel seguente modo:

• Un'organizzazione Google Cloud.
• Una cartella nell'organizzazione. Per questo codelab, lo chiameremo codelab-folder.
• Due progetti Google Cloud nella cartella codelab-folder. Per questo codelab, i progetti si chiamano project-1 e project-2.
  • Se non hai ancora creato la cartella e i progetti, nella console Google Cloud, crea una cartella nell'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.

Ai fini di questo codelab, puoi concederti i seguenti ruoli predefiniti: Folder Admin e Project Creator (a livello di cartella), Proprietario (a livello di progetto), Amministratore BigQuery (a livello di progetto), Amministratore oggetti Storage (a livello di progetto) e Amministratore Gestore contesto accesso (a livello di organizzazione). In questo modo, avrai i ruoli necessari per configurare le risorse richieste per l'intero codelab.

Crea una policy con ambito e un perimetro di servizio regolare

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

• Crea una policy di accesso con ambito, il cui ambito è limitato al livello della cartella codelab-folder. Per questo codelab, supponiamo che la policy di accesso creata 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 dal contenuto. La limitazione principale riguarda il requisito di colocation, che impone quanto segue:

• Se il tuo set di dati BigQuery si trova in una regione multiregionale, il bucket Cloud Storage contenente i dati che stai trasferendo deve trovarsi nella stessa regione multiregionale o in una località contenuta all'interno della regione multiregionale
• Se il set di dati si trova in una regione, il bucket Cloud Storage deve trovarsi nella stessa regione.

D'ora 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 multiregione.

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 documentati per creare 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, la posizione del bucket, 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 comando seguente per caricare l'oggetto file nel bucket creato:

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

Per verificare che il file sia stato caricato nel bucket creato, elenca gli oggetti nel bucket o esegui il seguente comando:

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

Crea 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: Stati Uniti (più regioni negli Stati Uniti).
2. Crea una tabella BigQuery nel set di dati creato codelab_bqtransfer_dataset 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 sullo 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 risorse/API Cloud, devi abilitare la fatturazione nei progetti project-2 e project-1. Ti consigliamo di chiudere le risorse utilizzate per evitare addebiti oltre questo codelab.

I nuovi utenti di Google Cloud possono usufruire del programma di prova senza costi di 300 $.

Le risorse che comportano il costo sono BigQuery e Cloud Storage. Un costo stimato è disponibile nel Calcolatore prezzi di BigQuery e nel Calcolatore prezzi di Cloud Storage.

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

Ora proveremo a creare un servizio di trasferimento dei dati (in project-2) per trasferire i dati da Cloud Storage (che si trova in project-1) a BigQuery (che si trova in project-2), mentre i controlli di servizio VPC proteggono BigQuery Data Transfer Service in project-2. La protezione del solo BigQuery Data Transfer Service (senza proteggere anche BigQuery e Cloud Storage) limita le entità alla sola creazione e gestione dei trasferimenti di dati (ad esempio l'avvio manuale di un trasferimento di dati).

Configura 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.

Si verifica 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 dai 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 visualizzare l'identificatore univoco dei Controlli di servizio VPC. Utilizza lo stesso identificatore per filtrare i log e identificare i dettagli della violazione (sostituisci 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 è un NO_MATCHING_ACCESS_LEVEL, ovvero una violazione in entrata 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; pertanto, 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 in entrata configurata con l'identità utente negata, che consente l'accesso al servizio bigquerydatatransfer.googleapis.com e a tutti i metodi.

Una volta implementata 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

Dai passaggi precedenti, mentre ti trovi nella 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, per 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 che abbiamo creato 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. In 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 la virgola(",") come Delimitatore di campo.
7. Nel menu Service account, seleziona un service account tra quelli associati al tuo progetto Google Cloud
   .
   1. Il service account 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 service account 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 selezioneremo Salva.

Il service account specificato nella configurazione del trasferimento dei dati 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 del service account che effettua 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, vedrai che l'agente BigQuery Data Transfer Service è quello che scrive 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 corse effettuate finora.

L'esecuzione del trasferimento dei dati dovrebbe riuscire, senza violazioni dei Controlli di servizio VPC sia per il trasferimento dei dati attivato manualmente sia per quello pianificato. Tieni presente che solo il trasferimento attivato manualmente richiede che la regola di ingresso consenta l'accesso al principal 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, i Controlli di servizio VPC offrono la possibilità di limitare l'accesso consentito in base ad attributi specifici delle richieste API, in particolare:

• Subnet IP: verifica se la richiesta proviene da un indirizzo IP specifico.
• Regioni: verifica se la richiesta proviene da una regione specifica, determinata dalla geolocalizzazione dell'indirizzo IP.
• Soggetti: verifica 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 in entrata già configurata, dobbiamo creare un livello di accesso che consenta gli attributi desiderati e poi aggiungere il livello di accesso creato come origine nella regola in entrata.

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

1. All'utente [e-mail] è 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 in entrata.
2. L'utente [e-mail] ha l'accesso bloccato quando il suo indirizzo IP non corrisponde all'indirizzo IP consentito, nonostante il suo account sia quello configurato nella regola di ingresso.
3. L'utente [e-mail] ha l'accesso bloccato nonostante tenti 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 limiti 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 scegliere di utilizzare l'IP privato per utilizzare l'indirizzo IP interno nei livelli di accesso. Tuttavia, per questo codelab, utilizziamo un IP pubblico.
   • Inserisci uno o più intervalli IPv4 o IPv6 formattati come blocchi CIDR.

I log di violazione dei 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.

Aggiungi il livello di accesso nella regola in entrata

All'interno della regola in entrata, il livello di accesso viene indicato nel campo sources, che è un campo obbligatorio come documentato nel riferimento alla regola in entrata. Per consentire l'accesso in entrata alle risorse, i Controlli di servizio VPC valutano gli attributi sources e identityType come condizione AND. La regola di ingresso utilizza l'identità del principal che attiva manualmente il trasferimento dei dati, non il service account 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 gli scenari seguenti:

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

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

Un modo semplice per eseguire 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 questo comando per attivare manualmente un trasferimento, sostituendo RUN_TIME e 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 ai servizi protetti dai Controlli di servizio VPC e verifichiamo se il trasferimento continua a essere eseguito correttamente.

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 Storage, attendi il successivo 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, utilizzeremo 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 visualizzarlo. 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 gli audit log utilizzando vpcServiceControlsUniqueIdentifier come mostrato nel Riepilogo del trasferimento.

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

• L'entità è il service account configurato in Data Transfer Service (che venga attivato manualmente o che esegua il trasferimento dei dati pianificato, l'entità negata 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 da Cloud Storage

Per correggere la violazione del traffico in uscita, dobbiamo utilizzare una regola in uscita che consenta il traffico dal service account negato verso il progetto con gli oggetti Cloud Storage.

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

6. Copia del set di dati BigQuery dal progetto 2 al progetto 1

Dopo aver confermato 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, mentre 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, è necessario 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 località.

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 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 non andrà a buon fine e si verificherà una violazione dei Controlli di servizio VPC.

Per trovare i dettagli della violazione dei Controlli di servizio VPC corrispondente, controlla i log in project-2 (progetto del set di dati di origine) con la seguente query di log. I filtri della query dei log filtrano i log in base al servizio BigQuery e al nome risorsa del set di dati in fase di copia (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 del traffico 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 riavvia la copia del set di dati

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

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

Una volta implementata la regola di uscita, sul perimetro perimeter-2 esegui lo stesso comando per copiare il set di dati. Questa volta, la copia del set di dati dovrebbe riuscire 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, è una best practice liberare spazio nella 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, quindi fai clic su Elimina.
  • Nella finestra di overlay visualizzata, conferma che vuoi 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 al livello in cui è definita l'ambito della policy di accesso, in questo caso a livello di cartella.
  • Nella pagina Controlli di servizio VPC, nella riga della tabella corrispondente al perimetro che vuoi eliminare, seleziona Delete Icon.
• Per eliminare il livello di accesso, completa i seguenti passaggi:
  • Nella console Google Cloud, apri la pagina Gestore contesto accesso nell'ambito della cartella.
  • Nella griglia, individua la riga del livello di accesso che vuoi eliminare, seleziona il menu con tre puntini, quindi seleziona Elimina.
• Per chiudere i progetti, completa i seguenti passaggi:
  • Nella console Google Cloud, vai alla pagina Impostazioni di IAM e amministrazione del progetto che vuoi eliminare.
  • Nella pagina delle impostazioni IAM e amministrazione, seleziona Arresto.
  • 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 protegga anche BigQuery, BigQuery Data Transfer Service e Cloud Storage.
• Esegui il trasferimento dei dati 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.