1. Introduzione
Il deployment del bilanciamento del carico di Google Cloud viene eseguito sul perimetro della rete Google, nei punti di presenza (POP) Google in tutto il mondo. Il traffico utente diretto a un bilanciatore del carico del proxy TCP entra nella rete POP più vicina all'utente. Quindi, il carico viene bilanciato sulla rete globale di Google e indirizzato al backend più vicino con capacità disponibile sufficiente.
Cloud Armor è il sistema di rilevamento WAF (Distributed Denial of Service) di Google. Cloud Armor è strettamente accoppiato al bilanciatore del carico proxy TCP di Google Cloud e ti consente di esaminare il traffico in entrata per rilevare eventuali richieste indesiderate. La funzionalità di limitazione della frequenza di questo servizio consente di ridurre il traffico alle risorse di backend in base al volume di richieste e impedisce al traffico indesiderato di consumare risorse sulla tua rete Virtual Private Cloud (VPC).
I bilanciatori del carico proxy TCP/SSL di Google Cloud ti consentono di usare il proxy per il traffico di tipo TCP/ SSL tra i tuoi servizi di backend.
In questo codelab, creerai un bilanciatore del carico proxy TCP/SSL con un servizio di backend e utilizzerai Cloud Armor per limitare l'accesso al bilanciatore del carico solo a un insieme specifico di client utente.
Obiettivi didattici
- Come creare un bilanciatore del carico per il proxy TCP/SSL
- Come creare un criterio di sicurezza di Cloud Armor
- Come creare una regola per la lista bloccata IP per il bilanciatore del carico del proxy TCP/SSL in Cloud Armor
- Creare una regola di limitazione della frequenza per il bilanciatore del carico proxy TCP in Cloud Armor
- Aggiungere il criterio di sicurezza a un servizio di backend di bilanciamento del carico TCP/SSL
Che cosa ti serve
- Conoscenza di base di Google Compute Engine ( codelab)
- Conoscenza di base del networking e di TCP/IP
- Conoscenza di base della riga di comando Unix/Linux
- È utile aver completato un tour del networking in Google Cloud con Networking in Google Cloud
2. Requisiti
Configurazione dell'ambiente autogestito
- Accedi alla console Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.
Nota: puoi accedere facilmente alla console Cloud memorizzando il relativo URL, che è console.cloud.google.com.
Ricorda l'ID progetto, un nome univoco in tutti i progetti Google Cloud (il nome precedente è già stato utilizzato e non funzionerà correttamente). Verrà indicato più avanti in questo codelab come PROJECT_ID.
Nota: se utilizzi un account Gmail, puoi lasciare la posizione predefinita impostata su Nessuna organizzazione. Se utilizzi un account Google Workspace, scegli una località adatta alla tua organizzazione.
- Successivamente, dovrai abilitare la fatturazione in Cloud Console per utilizzare le risorse Google Cloud.
Eseguire questo codelab non dovrebbe costare molto. Assicurati di seguire le istruzioni nella sezione "Pulizia" in cui viene spiegato come arrestare le risorse in modo da non incorrere in fatturazione oltre questo tutorial. I nuovi utenti di Google Cloud sono idonei al programma prova senza costi di 300$.
Avvia Cloud Shell
Anche se Google Cloud può essere utilizzato da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.
Dalla console di Google Cloud, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:
Dovrebbe richiedere solo qualche istante per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere una schermata simile al seguente:
Questa macchina virtuale viene caricata con tutti gli strumenti di sviluppo necessari. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni di rete e l'autenticazione. Tutto il lavoro in questo lab può essere svolto semplicemente con un browser.
Prima di iniziare
All'interno di Cloud Shell, assicurati che l'ID progetto sia configurato
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] PROJECT_ID=[YOUR-PROJECT-NAME] echo $PROJECT_ID
Abilita API
Abilita tutti i servizi necessari
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. Crea servizi di backend
Crea due istanze come segue: crea instance1-b1 nella zona us-central1-b
gcloud compute instances create vm-1-b1 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b1 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
Crea l'istanza 1-b2 nella zona us-central1-b
gcloud compute instances create vm-1-b2 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b2 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
Crea un gruppo di istanze vm-ig1
gcloud compute instance-groups unmanaged create vm-ig1 --zone us-central1-b
Crea una porta denominata per il gruppo di istanze. Per questo lab utilizzeremo la porta 110
gcloud compute instance-groups set-named-ports vm-ig1 \ --named-ports tcp 110:110 --zone us-central1-b
Aggiungi le istanze al gruppo di istanze
gcloud compute instance-groups unmanaged add-instances vm-ig1 \ --instances vm-1-b1,vm-1-b2 --zone us-central1-b
4. Configurazione del bilanciatore del carico
Ora creeremo un controllo di integrità.
gcloud compute health-checks create tcp my-tcp-health-check --port 110
Crea un servizio di backend
gcloud compute backend-services create my-tcp-lb --global-health-checks --global \ --protocol TCP --health-checks my-tcp-health-check --timeout 5m --port-name tcp110
Aggiungi il gruppo di istanze al servizio di backend
gcloud compute backend-services add-backend my-tcp-lb --global --instance-group \ vm-ig1 --instance-group-zone us-central1-b --balancing-mode UTILIZATION \ --max-utilization 0.8
configura un proxy TCP di destinazione
gcloud compute target-tcp-proxies create my-tcp-lb-target-proxy --backend-service \ my-tcp-lb --proxy-header NONE
Prenota indirizzi IPv4 statici globali
Utilizzerai questo indirizzo IP per raggiungere il servizio con bilanciamento del carico.
gcloud compute addresses create tcp-lb-static-ipv4 --ip-version=IPV4 --global
Configura le regole di forwarding globali per l'indirizzo IP LB.
gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
--global --target-tcp-proxy my-tcp-lb-target-proxy --address LB_STATIC_IPV4 \ --ports 110
5. Creazione di una regola firewall per il bilanciatore del carico del proxy TCP
gcloud compute firewall-rules create allow-tcplb-and-health \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --target-tags tcp-lb \ --allow tcp:110
Dopo aver creato il bilanciatore del carico, testalo con il seguente comando
Curl LB_IP:110
Poi crea delle VM per la convalida del rifiuto dell'accesso all'LB
Devi creare due istanze, ciascuna con un indirizzo IP pubblico e denominate test-server1 e test-server2
6. Crea un criterio di sicurezza in Cloud Armor
In questa sezione creerai un criterio di sicurezza del backend e due regole nel criterio in Cloud Armor.
La prima regola impedisce a un insieme limitato di IP di accedere al bilanciatore del carico TCP, impostando un criterio di sicurezza per negare determinati IP e la seconda regola limiterà la frequenza.
- In Cloud Shell(fai riferimento a "Avvia Cloud Shell" in "Configurazione e requisiti" per istruzioni su come utilizzare Cloud Shell), crea un criterio di sicurezza del servizio di backend chiamato rate-limit-and-deny-tcp come segue
gcloud compute security-policies create rate-limit-and-deny-tcp \
--description "policy for tcp proxy rate limiting and IP deny"
Aggiungi regole al criterio di sicurezza
Poi aggiungi una regola della lista bloccata al criterio di Cloud Armor "rate-limit-and-deny-tcp".
gcloud compute security-policies rules create 1000 --action deny --security-policy \ rate-limit-and-deny-tcp --description "deny test-server1" --src-ip-ranges \ "enter-test-server-1ip-here"
Aggiungi una regola di limitazione di frequenza al criterio di sicurezza di Cloud Armor "rate-limit-and-deny-tcp"
gcloud compute security-policies rules create 3000 \ --security-policy=rate-limit-and-deny-tcp \ --expression="true" --action=rate-based-ban --rate-limit-threshold-count=5 \ --rate-limit-threshold-interval-sec=60 --ban-duration-sec=300 \ --conform-action=allow --exceed-action=deny-404 --enforce-on-key=IP
Collega il criterio al servizio di backend del proxy TCP:
Esegui questo comando per assicurarti che il criterio di sicurezza sia collegato al servizio di backend del proxy TCP.
gcloud compute backend-services update my-tcp-lb --security-policy \ rate-limit-and-deny-tcp
Abilita il logging sul bilanciatore del carico del proxy TCP
gcloud beta compute backend-services update my-tcp-lb \ --enable-logging --logging-sample-rate=1
7. Convalida regola lista bloccata
Convalida la regola dell'elenco di elementi bloccati accedendo al server di test il cui IP è stato specificato nella regola dell'elenco di elementi bloccati ed esegui il comando seguente
Curl LB_IP:110
Le richieste immediate possono fornire una risposta da LB, ma attendere che la richiesta curl venga rifiutata o abbandonata, quindi esamina i log in Cloud Logging per verificare la voce di log relativa alla regola di negazione IP che viene attivata.
Vai a Cloud Logging e, in Risorse, seleziona il tipo di risorsa "tcp_ssl_proxy_rule" e imposta la destinazione del backend come "my-tcp-lb".
Dopo avere definito le risorse per l'applicazione dei filtri, possiamo verificare che la regola di negazione IP sia attiva dal valore PRIORITY pari a 1000 nella voce di log e che l'azione configurata "DENY" sia applicata poiché entrambe sono state indicate dalla regola di negazione e che l'IP è negato, come mostrato di seguito
8. Convalida la regola di limitazione di frequenza
Verifica che la regola per la limitazione di frequenza sia applicata inviando molte richieste in un breve periodo di tempo che supera la soglia definita (5 richieste al minuto).
Al termine, fai clic su Visualizza log nel servizio Cloud Armor per accedere a Cloud Logging, dove potrai filtrare i log in base al bilanciatore del carico per vedere i log di Cloud Armor man mano che arrivano.
Una voce relativa alla limitazione di frequenza deve essere quella riportata nello screenshot di seguito. Possiamo verificare che la regola per la limitazione di frequenza sia effettiva dal valore PRIORITY 3000 nella voce di log e dall'azione configurata, l'azione "RATE BASED BAN" è applicata come indicato dalla regola di limitazione della frequenza.
9. Pulizia dell'ambiente
Assicurati di pulire l'infrastruttura creata per evitare costi di esecuzione dell'infrastruttura inutilizzata.
Il modo più rapido è eliminare l'intero progetto in Google Cloud per assicurarti che non ci siano risorse in sospeso inutilizzate.Tuttavia, elimina le singole risorse con i comandi seguenti
Il bilanciatore del carico del proxy TCP
gcloud compute target-tcp-proxies delete my-tcp-lb
Il gruppo di istanze
gcloud compute instance-groups unmanaged delete vm-ig1
Le 2 istanze VM di test sono state create
gcloud compute instances delete Instance_name --zone=instance_zone
Il servizio di backend
gcloud compute backend-services delete BACKEND_SERVICE_NAME
Le regole di Cloud Armor all'interno del criterio
gcloud compute security-policies rules delete 1000 \ --security-policy=rate-limit-and-deny-tcp && gcloud compute security-policies rules delete 3000 \ --security-policy=rate-limit-and-deny-tcp
Il criterio di sicurezza di Cloud Armor
gcloud compute security-policies delete rate-limit-and-deny-tcp