1. Introduzione
Secure Web Proxy per Google Cloud
Cloud SWP è un servizio cloud-first che fornisce un proxy web sicuro per aiutarti a proteggere il traffico web in uscita (HTTP/S). Configura i tuoi client in modo che utilizzino esplicitamente Cloud SWP come proxy. Le richieste web possono provenire dalle seguenti fonti:
- Istanze di macchine virtuali (VM)
- Container
- Un ambiente serverless che utilizza un connettore serverless
- Carichi di lavoro nel peering VPC
- Carichi di lavoro esterni a Google Cloud connessi da Cloud VPN o Cloud Interconnect
Cloud SWP consente policy flessibili e granulari basate su identità cloud-first e applicazioni web.
Vantaggi
Di seguito sono riportati alcuni esempi di vantaggi che Cloud SWP potrebbe fornire a un'organizzazione:
Migrazione a Google Cloud
Cloud SWP ti aiuta a eseguire la migrazione a Google Cloud mantenendo i criteri di sicurezza e i requisiti esistenti per il traffico web in uscita. Puoi evitare di utilizzare soluzioni di terze parti che richiedono un'altra console di gestione o modificare manualmente i file di configurazione.
Accesso a servizi web esterni attendibili
Cloud SWP consente di applicare criteri di accesso granulari al traffico web in uscita in modo da proteggere la rete. Devi creare e identificare le identità delle applicazioni o dei carichi di lavoro e quindi applicare i criteri.
Accesso monitorato a servizi web non attendibili
Puoi utilizzare Cloud SWP per fornire l'accesso monitorato a servizi web non attendibili. Cloud SWP identifica il traffico non conforme ai criteri e lo registra in Cloud Logging (Logging). Puoi quindi monitorare l'utilizzo di internet, scoprire le minacce per la tua rete e rispondere alle minacce.
Controlli granulari dei criteri per le API di Google
Puoi utilizzare Cloud SWP per fornire criteri granulari per le API di Google. Ad esempio, puoi impostare criteri a livello di bucket/oggetto sfruttando Common Expression Language (CEL).
Funzionalità supportate
Cloud SWP supporta le seguenti funzionalità:
Servizio proxy esplicito
I client devono essere configurati esplicitamente per l'utilizzo del server proxy. Il proxy Cloud SWP isola i client da internet creando nuove connessioni TCP per conto del client.
Scalabilità automatica dei proxy Envoy Cloud SWP
Supporta la regolazione automatica delle dimensioni del pool di proxy Envoy e della capacità del pool in una regione, al fine di garantire prestazioni costanti durante i periodi di maggiore richiesta al costo più basso.
Criteri di accesso modulari in uscita
Cloud SWP supporta specificamente i seguenti criteri in uscita:
- Identità di origine basata su tag, account di servizio o indirizzi IP protetti.
- Destinazioni basate su URL e nomi host.
- Richieste basate su metodi, intestazioni o URL. Gli URL possono essere specificati utilizzando elenchi, caratteri jolly o pattern.
- Crittografia end-to-end: i tunnel proxy-client potrebbero transitare su TLS. Cloud SWP supporta anche HTTP/S CONNECT per le connessioni TLS end-to-end avviate dal client al server di destinazione.
Integrazione semplificata di Cloud NAT
Cloud NAT esegue automaticamente il provisioning di indirizzi IP pubblici aggiuntivi quando aumenta il set di proxy che gestiscono il traffico Cloud SWP.
Anche gli indirizzi IP pubblici statici manuali sono un'opzione per chi vuole avere IP in uscita noti.
Integrazione di Cloud Audit Logs e della suite operativa di Google Cloud
Cloud Audit Logs e la suite operativa di Google Cloud registrano le attività amministrative e le richieste di accesso per le risorse relative a Cloud SWP. Registra inoltre le metriche e i log delle transazioni per le richieste gestite dal proxy.
Ispezione TLS
Secure Web Proxy offre un servizio di ispezione TLS che consente di intercettare il traffico TLS, ispezionare la richiesta criptata e applicare criteri di sicurezza.
- Stretta integrazione con Certificate Authority Service (CAS), che è un repository scalabile e ad alta disponibilità per CA private.
- La possibilità di utilizzare la propria radice di attendibilità, se necessario. Puoi anche utilizzare una CA radice esistente per firmare le CA subordinate detenute dalle CA. Se preferisci, puoi generare un nuovo certificato radice all'interno delle CA.
- Criteri di decrittografia granulari utilizzando SessionMatcher e ApplicationMatcher all'interno delle regole dei criteri di Secure Web Proxy. Questi criteri includono gli host corrispondenti presenti negli elenchi di URL, le espressioni regolari, gli intervalli di indirizzi IP ed espressioni simili. Se necessario, i criteri possono essere combinati con espressioni booleane.
- Ogni criterio di Secure Web Proxy può essere configurato con i propri criteri di ispezione TLS e pool di CA. In alternativa, più criteri di Secure Web Proxy possono condividere un singolo criterio di ispezione TLS.
Obiettivi didattici
- Come eseguire il deployment e gestire Cloud SWP.
Che cosa ti serve
- Conoscenza della distribuzione delle istanze e della configurazione dei componenti di networking
- Conoscenza della configurazione dei firewall VPC
2. Ambiente di test
Questo codelab sfrutterà un singolo VPC. Una risorsa di computing in questo ambiente eseguirà il traffico in uscita utilizzando Cloud SWP, come illustrato nel diagramma seguente.
In questo lab avremo 2 VM dei carichi di lavoro.
Il client A verrà configurato per inviare tutte le richieste HTTP/HTTPS a Cloud SWP.
Il client B NON verrà configurato per inviare esplicitamente richieste HTTP/HTTPS a Cloud SWP, ma sfrutterà Cloud NAT per il traffico associato a internet.
3. Prima di iniziare
Il codelab richiede un singolo progetto.
All'interno di Cloud Shell, assicurati che l'ID progetto sia configurato
export project_id=`gcloud config list --format="value(core.project)"` export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"` export region=us-west1 export zone=us-west1-a export prefix=codelab-swp export member="serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com"
4. Abilita API
Abilita le API per utilizzare i prodotti
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. Crea una rete VPC, una subnet e una subnet solo proxy
Rete VPC
Crea un VPC codelab-swp-vpc:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
Subnet
Crea le rispettive subnet nella regione selezionata:
gcloud compute networks subnets create $prefix-vpc-subnet \ --range=10.10.10.0/24 --network=$prefix-vpc --region=$region
Subnet solo proxy
Crea una subnet solo proxy nella regione selezionata:
gcloud compute networks subnets create $prefix-proxy-only-subnet --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE --region=$region --network=$prefix-vpc --range=172.16.0.0/23
6. Crea regole firewall
Per consentire a IAP di connettersi alle tue istanze VM, crea una regola firewall che:
- Si applica a tutte le istanze VM a cui vuoi rendere accessibile tramite IAP.
- Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP utilizzati da IAP per l'inoltro TCP.
Da Cloudshell:
gcloud compute firewall-rules create $prefix-allow-iap-proxy \ --direction=INGRESS \ --priority=1000 \ --network=$prefix-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20
7. Creazione di router Cloud e Cloud NAT
Crea il router Cloud per Cloud NAT.
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
Crea il gateway Cloud NAT per il client B.
gcloud compute routers nats create $prefix-nat-gw-$region \ --router=$prefix-cr \ --router-region=$region \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges
8. Crea un criterio di sicurezza del gateway
Crea un file YAML che contiene informazioni pertinenti per il criterio:
cat > /tmp/policy.yaml << EOF
description: Policy to allow .com traffic, then (/index.html), and finally TLS.
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
EOF
Esegui il comando gcloud per creare il criterio dal file YAML:
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. Crea una regola del criterio di sicurezza del gateway
Creare un file YAML che contiene le regole. Queste regole sono rappresentate nel linguaggio CEL (Common Expression Language). In questo lab viene utilizzata una semplice regola che consentirà il traffico verso i domini .com e bloccherà tutti gli altri:
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
EOF
Ora possiamo associare la regola al criterio di sicurezza del gateway:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
10. Crea un certificato e caricalo in Cloud Certificate Manager
Crea un certificato per terminare il traffico dei carichi di lavoro:
openssl req -x509 -newkey rsa:2048 -keyout /tmp/key.pem -out /tmp/cert.pem -days 365 -subj '/CN=www.codelab-swp.com' -nodes -addext \ "subjectAltName = DNS:www.codelab-swp.com"
Carica il certificato in Cloud Certificate Manager in modo che l'SWP possa farvi riferimento nel criterio del gateway di sicurezza.
gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem
11. Crea il gateway SWP
Crea il file YAML per il gateway SWP per fare riferimento alle informazioni precedenti, come certificato, criterio di sicurezza del gateway, rete e subnet.
cat > /tmp/gateway.yaml << EOF
name: projects/${project_id}/locations/${region}/gateways/${prefix}-gateway
type: SECURE_WEB_GATEWAY
addresses: [10.10.10.50]
ports: [443]
certificateUrls: [projects/${project_id}/locations/${region}/certificates/${prefix}-cert]
gatewaySecurityPolicy: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
network: projects/${project_id}/global/networks/${prefix}-vpc
subnetwork: projects/${project_id}/regions/${region}/subnetworks/${prefix}-vpc-subnet
EOF
Crea il gateway:
gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}
Verifica che il gateway sia stato creato:
gcloud network-services gateways describe ${prefix}-swp --location ${region}
12. Creazione di istanze di calcolo
Poiché Cloud SWP è un proxy esplicito, è necessario specificare esplicitamente l'IP proxy per il traffico dei carichi di lavoro. La variabile di ambiente del client A dell'istanza Compute sarà impostata. ClientB no.
Crea le istanze di calcolo ClientA e ClientB:
gcloud compute instances create clienta \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.10 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update sudo echo http_proxy=https://10.10.10.50:443/ >> /etc/environment sudo echo https_proxy=https://10.10.10.50:443/ >> /etc/environment '
gcloud compute instances create clientb \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.200 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update '
13. Test della corrispondenza delle sessioni
Accedi tramite SSH a "clienta" di Compute Engine creata di recente. In questa VM è impostata la variabile di ambiente per l'utilizzo di Cloud SWP.
Da Cloudshell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Esegui alcune query web per convalidare la funzionalità. Abbiamo bisogno di –proxy-insecure perché abbiamo creato un certificato autofirmato per questo lab:
curl https://google.com --proxy-insecure
Output previsto:
davidtu@clienta:~$ curl https://google.com --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
Come puoi vedere, la richiesta è stata "riuscita". È previsto un reindirizzamento 301 perché il sito web a https://www.google.com.
L'esecuzione di questo comando fornisce log dettagliati con i dettagli della connessione:
curl https://google.com --proxy-insecure -v
Evidenziazione di alcuni output per mostrare i dettagli della connessione proxy, i certificati e la destinazione.
davidtu@clienta:~$ curl https://google.com --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to google.com:443 > CONNECT google.com:443 HTTP/1.1 > Host: google.com:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 200 OK < date: Mon, 12 Dec 2022 19:22:04 GMT < * Proxy replied 200 to CONNECT request * CONNECT phase completed! ...
Non esitare a provare altri domini .com per verificarne la funzionalità.
Proviamo ora con altri domini non .com per verificare il comportamento di blocco predefinito:
curl https://wikipedia.org --proxy-insecure
Output previsto:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Allo stesso modo, osserva il logging dell'output dettagliato e verifica che Cloud SWP blocchi questo traffico:
curl https://wikipedia.org --proxy-insecure -v
davidtu@clienta:~$ curl https://wikipedia.org --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to wikipedia.org:443 > CONNECT wikipedia.org:443 HTTP/1.1 > Host: wikipedia.org:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 403 Forbidden < content-length: 13 < content-type: text/plain < date: Mon, 12 Dec 2022 19:35:09 GMT < connection: close < * Received HTTP code 403 from proxy after CONNECT * CONNECT phase completed! * Closing connection 0 curl: (56) Received HTTP code 403 from proxy after CONNECT
Non esitare a provare anche altri domini per verificare il comportamento.
Esci dalla sessione SSH per "clienta" e avvia una nuova connessione SSH a "clientb".
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
Esegui alcuni comandi curl per verificare il comportamento:
curl https://google.com
Questo comando dovrebbe funzionare come previsto dalla VM clientb:
davidtu@clientb:~$ curl https://google.com <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
Test su un dominio dell'organizzazione:
curl https://wikipedia.org
Questo funziona come previsto, dato che Clientb non sfrutta Cloud SWP:
davidtu@clientb:~$ curl https://wikipedia.org <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.wikipedia.org/">here</a>.</p> </body></html>
Testa l'invio del traffico in modo esplicito tramite Cloud SWP:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Vediamo che questo traffico viene negato tramite il criterio Cloud SWP:
davidtu@clientb:~$ curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure curl: (56) Received HTTP code 403 from proxy after CONNECT
Come hai verificato, il traffico che sfrutta Cloud SWP viene applicato in base al criterio di sicurezza configurato. Il traffico destinato a .com è consentito, mentre tutte le altre destinazioni sono rifiutate.
Esci dal clientb.
14. Aggiorna una regola del criterio di sicurezza del gateway per ApplicationMatching
Aggiorniamo la regola in modo che corrisponda ai dettagli a livello di applicazione. Creeremo una regola per esaminare il percorso della richiesta e consentirlo solo se corrisponde a index.html.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
EOF
Ora possiamo associare la regola aggiornata al criterio di sicurezza del gateway:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
15. Test della regola ApplicationMatcher
Accedi tramite SSH alla VM Clienta Compute. In questa VM è impostata la variabile di ambiente per l'utilizzo di Cloud SWP.
Da Cloudshell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Esegui alcune query web per convalidare la funzionalità. Abbiamo bisogno di –proxy-insecure perché abbiamo creato un certificato autofirmato per questo lab:
curl http://google.com --proxy-insecure
Tieni presente che questa query avrà esito negativo una volta passata in precedenza.
Access denied
Qualsiasi percorso di richiesta diverso da "index.html" dovrebbe essere bloccato con un errore 403. Non esitare a effettuare ulteriori test.
Modifica la query in modo da includere il percorso /index.html
curl http://google.com/index.html --proxy-insecure
Questa richiesta dovrebbe andare a buon fine:
davidtu@clienta:~$ curl http://google.com/index.html --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
È previsto un reindirizzamento 301 perché il sito web reindirizza a http://www.google.com/index.html
Tieni presente che questa è una richiesta HTTP. Successivamente, dovrai abilitare le funzionalità di ispezione TLS in SWP.
Poi esegui la stessa query, ma su TLS:
curl -k https://google.com/index.html --proxy-insecure
Output previsto:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Questa richiesta non dovrebbe riuscire perché SWP non è configurato per ispezionare TLS e non può valutare il percorso in base alla regola applicationMatcher.
Esci da clenta.
16. Abilita ispezione TLS
Senza l'ispezione TLS, applicationMatcher non corrisponderà al traffico HTTPS.
"applicationMatcher" consente di applicare un filtro in base a:
- Mappa intestazioni delle richieste
- Metodo di richiesta
- Host richiesta
- Percorso richiesta
- Richiedi query
- Schema della richiesta
- URL richiesta completo
- Richiedi user agent
Crea account servizio
Questo account di servizio avrà le autorizzazioni necessarie per generare certificati per l'ispezione TLS SWP.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
Assicurati che le CA siano abilitate
gcloud services enable privateca.googleapis.com
Crea un pool di CA
gcloud privateca pools create $prefix-ca-pool \
--tier=devops \
--project=$project_id \
--location=$region
Crea CA radice
CA utilizzata per la firma del certificato.
gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \ --location=$region \ --auto-enable \ --subject="CN=my-swp-ca, O=SWP LLC"
Crea un file dei criteri di emissione dei certificati
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
Crea file YAML dell'ispezione TLS
cat > /tmp/tls-inspection-policy.yaml << EOF caPool: projects/$project_id/locations/$region/caPools/$prefix-ca-pool name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-inspection EOF
Crea criterio di ispezione TLS
gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
--source=/tmp/tls-inspection-policy.yaml \
--location=$region
Aggiorna il pool di CA per utilizzare il criterio di emissione dei certificati
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
Concedi autorizzazioni
Ciò consente al tuo account di servizio di utilizzare il pool di CA per generare certificati.
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
Aggiorna il file YAML dei criteri per includere l'ispezione TLS
cat > /tmp/policy.yaml << EOF
description: some policy description
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
tlsInspectionPolicy: projects/${project_id}/locations/${region}/tlsInspectionPolicies/${prefix}-tls-inspection
EOF
Esegui il comando per applicare il criterio aggiornato
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
Aggiorna le regole per includere l'ispezione TLS
Poi specifica quali regole devono avere l'ispezione TLS "enabtlsEsaminaionEnabled: true" flag.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
tlsInspectionEnabled: true
EOF
Esegui il comando per applicare la regola aggiornata
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
17. Testa l'ispezione TLS
Accedi tramite SSH alla VM Clienta Compute. In questa VM è impostata la variabile di ambiente per l'utilizzo di Cloud SWP.
Da Cloudshell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Esegui la query web precedente per verificare se SWP sta eseguendo l'ispezione TLS per recuperare il percorso
curl -k https://google.com/index.html --proxy-insecure
Questa volta dovrebbe avere esito positivo poiché SWP può valutare ApplicationMatcher.
Output previsto:
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
Abbiamo configurato Cloud SWP per ispezionare TLS e valutare la logica applicationMatcher.
Esci da client.
18. Passaggi per la pulizia
Da Cloud Shell, rimuovi il gateway SWP, il criterio di sicurezza, i certificati, le istanze, Cloud NAT e il router Cloud:
gcloud -q network-services gateways delete ${prefix}-swp --location=${region}
gcloud -q network-security gateway-security-policies rules delete rule-com --location=${region} --gateway-security-policy=${prefix}-policy
gcloud -q network-security gateway-security-policies delete ${prefix}-policy --location=${region}
gcloud -q certificate-manager certificates delete ${prefix}-cert --location=${region}
gcloud -q network-security tls-inspection-policies delete $prefix-tls-inspection --location=$region
gcloud -q privateca roots disable $prefix-root-ca --pool=$prefix-ca-pool --location=$region
gcloud -q privateca roots delete $prefix-root-ca --pool=$prefix-ca-pool --location=$region --ignore-active-certificates --skip-grace-period
gcloud -q privateca pools delete $prefix-ca-pool --location=$region
gcloud -q compute instances delete clienta --zone=$zone
gcloud -q compute instances delete clientb --zone=$zone
gcloud -q compute routers nats delete ${prefix}-nat-gw-${region} \
--router=$prefix-cr --router-region=$region
gcloud -q compute routers delete `gcloud compute routers list --regions=$region --format="value(NAME)" | grep -e swg-autogen -e codelab-swp` --region=$region
Rimuovi le subnet, le regole FW e i VPC:
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks subnets delete $prefix-proxy-only-subnet \
--region=$region
gcloud -q compute firewall-rules delete $prefix-allow-iap-proxy
gcloud -q compute networks delete $prefix-vpc
19. Complimenti
Complimenti per aver completato il codelab. Hai configurato ed eseguito correttamente il deployment di Cloud Secure Web Proxy su Google Cloud.
Argomenti trattati
- Cloud SWP e i relativi vantaggi