1. Introduzione
Secure Web Proxy per Google Cloud
Cloud SWP è un servizio cloud-first che fornisce un proxy web sicuro per proteggere il traffico web in uscita (HTTP/S). Configura i client in modo che utilizzino esplicitamente Cloud SWG come proxy. Le richieste web possono provenire dalle seguenti origini:
- Istanze di macchine virtuali (VM)
- Container
- Un ambiente serverless che utilizza un connettore serverless
- Workload nel peering VPC
- Carichi di lavoro esterni a Google Cloud connessi tramite Cloud VPN o Cloud Interconnect
Cloud SWP consente di applicare criteri flessibili e granulari basati 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 la modifica manuale dei 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. Crei e identifichi le identità di workload o applicazioni, quindi applichi 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. Puoi quindi monitorare l'utilizzo di internet, scoprire le minacce alla tua rete e rispondere alle minacce.
Controlli granulari dei criteri per le API di Google
Puoi utilizzare Cloud SWP per fornire policy granulari per le API di Google. Ad esempio, puoi impostare criteri a livello di bucket/oggetto utilizzando Common Expression Language (CEL).
Funzionalità supportate
Cloud SWP supporta le seguenti funzionalità:
Servizio proxy esplicito
I client devono essere configurati in modo esplicito per utilizzare il 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, il che consente prestazioni coerenti durante i periodi di forte domanda al costo più basso.
Criteri di accesso modulari per il traffico in uscita
Cloud SWP supporta in modo specifico le seguenti policy di uscita:
- Identità di origine basata su tag sicuri, service account o indirizzi IP.
- 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 client-proxy 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.
Gli indirizzi IP pubblici statici manuali sono un'opzione anche per chi vuole avere IP di 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 correlate a Cloud SWP. Registrano anche 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 policy di sicurezza.
- Stretta integrazione con Certificate Authority Service (CAS), un repository scalabile e ad alta disponibilità per le CA private.
- La possibilità di utilizzare la tua radice di attendibilità, se necessario. Puoi anche utilizzare una CA radice esistente per firmare le CA subordinate detenute da CAS. Se preferisci, puoi generare un nuovo certificato radice in CAS.
- Criteri di decriptazione granulari utilizzando SessionMatcher e ApplicationMatcher all'interno delle regole dei criteri Secure Web Proxy. Questi criteri includono host corrispondenti presenti in elenchi di URL, espressioni regolari, intervalli di indirizzi IP ed espressioni simili. Se necessario, i criteri possono essere combinati con espressioni booleane.
- Ogni policy Secure Web Proxy può essere configurata con la propria policy di ispezione TLS e il proprio pool di CA. In alternativa, più policy Secure Web Proxy possono condividere una singola policy di ispezione TLS.
Obiettivi didattici
- Come eseguire il deployment e gestire Cloud SWP.
Che cosa ti serve
- Conoscenza del deployment delle istanze e della configurazione dei componenti di rete
- Conoscenza della configurazione del firewall VPC
2. Ambiente di test
Questo codelab utilizzerà un singolo VPC. Una risorsa di calcolo in questo ambiente eseguirà l'uscita utilizzando Cloud SWP, come mostrato nel diagramma seguente.
In questo lab avremo due VM di workload.
Il client A verrà configurato per inviare tutte le richieste HTTP/HTTPS al Cloud SWP.
Client B NON sarà configurato per inviare esplicitamente richieste HTTP/HTTPS al Cloud SWP, ma utilizzerà Cloud NAT per il traffico diretto a internet.
3. Prima di iniziare
Il codelab richiede un singolo progetto.
In 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 rete VPC, subnet e subnet solo proxy
Rete VPC
Crea il 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 applichi a tutte le istanze VM a cui vuoi accedere tramite IAP.
- Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP che utilizzati da IAP per l'inoltro TCP.
Da Cloud Shell:
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. Crea 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 cliente 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 una policy di sicurezza del gateway
Crea un file YAML che contenga le informazioni pertinenti per la policy:
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 la policy dal file YAML:
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. Crea una regola della policy di sicurezza del gateway
Crea un file YAML contenente le regole. Queste regole sono rappresentate in Common Expression Language (CEL). Questo lab utilizzerà 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 alla policy 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 del workload:
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 SWP possa farvi riferimento nella policy 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 SWP Gateway per fare riferimento alle informazioni precedenti, come certificato, policy 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. Crea istanze di Compute
Poiché Cloud SWP è un proxy esplicito, dobbiamo specificare esplicitamente l'IP del proxy per il traffico del workload. L'istanza di calcolo clientA avrà la variabile di ambiente impostata. Il cliente B non lo farà.
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 alla VM di Compute "clienta" creata di recente. Questa VM ha la variabile di ambiente impostata per utilizzare Cloud SWP.
Da Cloud Shell:
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 "completata". È previsto un reindirizzamento 301, poiché il sito web reindirizza a https://www.google.com.
L'esecuzione del seguente comando fornisce log dettagliati con informazioni sulla connessione:
curl https://google.com --proxy-insecure -v
Evidenzia 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! ...
Prova altri domini .com per verificare la funzionalità.
Ora proviamo 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
Analogamente, esamina la registrazione 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
Se vuoi, puoi provare anche altri domini per verificare il comportamento.
Esci dalla sessione SSH di "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 dovrebbe funzionare come previsto nella 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 rispetto a un dominio org:
curl https://wikipedia.org
Questo funziona come previsto perché clientb non utilizza 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>
Verifica l'invio esplicito del traffico tramite Cloud SWP:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
Ci risulta che questo traffico venga negato tramite le norme 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 utilizza Cloud SWP viene applicato in base al criterio di sicurezza configurato. Il traffico destinato a .com è consentito e tutte le altre destinazioni sono rifiutate.
Esci da clientb.
14. Aggiorna una regola della policy 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 a una VM di calcolo clienta. Questa VM ha la variabile di ambiente impostata per utilizzare Cloud SWP.
Da Cloud Shell:
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 non andrà a buon fine, anche se in precedenza era andata a buon fine.
Access denied
Qualsiasi percorso di richiesta diverso da "index.html" deve essere bloccato con un errore 403. Non esitare a testare ulteriormente questa funzionalità.
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 poiché il sito web reindirizza a http://www.google.com/index.html
Tieni presente che si tratta di una richiesta HTTP. Successivamente, dovrai abilitare SWP per disporre delle funzionalità di ispezione TLS.
Poi esegui la stessa query, ma tramite TLS:
curl -k https://google.com/index.html --proxy-insecure
Output previsto:
curl: (56) Received HTTP code 403 from proxy after CONNECT
Questa richiesta dovrebbe non andare a buon fine, poiché SWP non è configurato per ispezionare TLS e non può valutare il percorso in base alla regola applicationMatcher.
Esci da clenta.
16. Abilita l'ispezione TLS
Senza l'ispezione TLS, applicationMatcher non corrisponderà al traffico HTTPS.
"applicationMatcher" consente il filtraggio in base a quanto segue:
- Mappa delle intestazioni delle richieste
- Metodo di richiesta
- Richiedi host
- Percorso richiesta
- Query della richiesta
- Schema della richiesta
- URL di richiesta completo
- Richiedi useragent
Crea service account
Questo service account avrà le autorizzazioni per generare certificati per l'ispezione TLS SWP.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
Assicurati che CAS sia abilitato
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"
Creare un file di criteri di emissione di certificati
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
Crea il file YAML di 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 policy 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 di certificati
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
Concedi autorizzazioni
In questo modo, il service account può 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 della policy 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 la policy aggiornata
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
Aggiorna le regole in modo da includere l'ispezione TLS
Poi specifica quali regole devono avere il flag di ispezione TLS "enabtlsInspectionEnabled: true".
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. Testare l'ispezione TLS
Accedi tramite SSH a una VM di calcolo clienta. Questa VM ha la variabile di ambiente impostata per utilizzare Cloud SWP.
Da Cloud Shell:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
Esegui la query web precedente per verificare se SWP esegue l'ispezione TLS per recuperare il percorso
curl -k https://google.com/index.html --proxy-insecure
Questa volta dovrebbe avere esito positivo perché 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 correttamente Cloud SWP per ispezionare TLS e valutare la logica di applicationMatcher.
Esci da clienta.
18. Procedura di pulizia
Da Cloud Shell, rimuovi il gateway SWP, il criterio di sicurezza, i certificati, le istanze, Cloud NAT e Cloud Router:
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 firewall 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!
Congratulazioni per aver completato il codelab. Hai configurato e implementato correttamente Cloud Secure Web Proxy su Google Cloud.
Argomenti trattati
- SWP per Cloud e i vantaggi