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
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 progettiproject-1
eproject-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
eproject-2
.
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'ID987654321
. - Crea un perimetro normale, che chiameremo
perimeter-2
, e aggiungi il progettoproject-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 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
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
- Crea un set di dati BigQuery nel progetto
project-2
seguendo questi passaggi.- In ID set di dati, inserisci un nome univoco per il set di dati. Per questo codelab, utilizziamo:
codelab_bqtransfer_dataset
. - 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).
- In ID set di dati, inserisci un nome univoco per il set di dati. Per questo codelab, utilizziamo:
- Crea una tabella BigQuery nel set di dati
codelab_bqtransfer_dataset
creato seguendo questi passaggi.- Nella sezione Origine, seleziona Tabella vuota nell'elenco Crea tabella da.
- Nel campo Table (Tabella), inserisci il nome della tabella che vuoi creare. Per questo codelab, utilizziamo il nome
codelab-bqtransfer-table
. - Verifica che il campo Tipo di tabella sia impostato su Tabella nativa.
- 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.
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:
- Vai alla pagina BigQuery nella console Google Cloud di
project-2
. - Fai clic su Trasferimenti di 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:
- Fai clic su + Crea trasferimento.
- Nella sezione Tipo di origine, per Origine, scegli Google Cloud Storage.
- Nella sezione Nome configurazione di trasferimento, per Nome visualizzato, inserisci un nome per il trasferimento, ad esempio
Codelab Transfer
. - Nella sezione Opzioni di pianificazione:
- Seleziona una Frequenza di ripetizione, ad esempio 15 minuti.
- Assicurati di selezionare Inizia ora, altrimenti il trasferimento dei dati inizierà solo dopo la Frequenza di ripetizione configurata.
- 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
- Nella sezione Dettagli origine dati
- 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
- 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
- Per Preferenza di scrittura, mantieni
APPEND
(o scegliMIRROR
). - 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.
- Per Formato file, seleziona CSV.
- In Opzioni di trasferimento, in CSV, inserisci virgola(",") come Separatore di campi.
- 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:
- Nel menu Account di servizio, seleziona un account di servizio tra quelli associati al tuo progetto Google Cloud
- 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. - Per questo codelab, utilizzeremo un account di servizio creato in
project-2
comecodelab-sa@project-2.iam.gserviceaccount.com
.
- L'account di servizio selezionato deve disporre delle autorizzazioni richieste sia per Cloud Storage nel progetto che ospita il bucket di archiviazione;
- Fai clic su Salva.
Poiché abbiamo selezionato Inizia ora come opzione di pianificazione, il primo trasferimento inizierà non appena verrà selezionato Salva.
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 (
user@example.com
e user2@example.com
) 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.
- All'utente user@example.com 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.
- L'accesso dell'utente utente@example.com viene bloccato quando il suo indirizzo IP non corrisponde a quello consentito, nonostante il suo account sia quello configurato nella regola di ingresso.
- L'accesso all'utente user2@example.com è 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:
- Apri la pagina Gestore contesto accesso nella console Google Cloud.
- Se richiesto, seleziona la cartella
codelab-folder
.
- Se richiesto, seleziona la cartella
- Nella parte superiore della pagina Gestore contesto accesso, fai clic su CREA LIVELLO DI ACCESSO.
- Nel riquadro Nuovo livello di accesso, assegna un titolo al nuovo livello di accesso. Per questo codelab, lo chiameremo
project_2_al
. - Nella sezione Condizioni, fai clic su + davanti a Subnet IP.
- 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.
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:
- Vai alla pagina BigQuery nella console Google Cloud.
- Fai clic su Trasferimenti di dati.
- Seleziona il trasferimento dall'elenco: per questo codelab utilizziamo il trasferimento Codelab Transfer
- Fai clic su Esegui ora il trasferimento.
- 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: "codelab-sa@project-2.iam.gserviceaccount.com"
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.
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
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.