Codelab su Cloud Secure Web Proxy (SWP)

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.

1264e30caa136365.png

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.

&quot;applicationMatcher&quot; 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