Cloud NGFW Essentials per i bilanciatori del carico

1. Introduzione

Questo codelab esplora Cloud Next Generation Firewall (NGFW) Essentials per i bilanciatori del carico delle applicazioni (ALB) interni e i bilanciatori del carico di rete (NLB) proxy utilizzando le policy del firewall di rete regionali.

Cloud NGFW è un servizio firewall completamente distribuito con funzionalità avanzate di protezione dalle minacce e microsegmentazione per proteggere i workload Google Cloud. L'attivazione di Cloud NGFW a livello di bilanciatore del carico applica regole di policy del firewall coerenti a qualsiasi traffico TCP in entrata nei bilanciatori del carico basati su proxy interni. Semplifica il provisioning di una postura di sicurezza organizzativa offrendo un'applicazione più ampia delle policy per tutti i servizi.

In questo codelab vengono trattati i seguenti prodotti e funzionalità di Cloud NGFW e del bilanciamento del carico di Google Cloud:

Cloud NGFW Essentials
Criteri firewall di rete regionali
Bilanciatore del carico delle applicazioni interno regionale
Gruppo di istanze gestite (MIG) di backend e gruppo di endpoint di rete (NEG) Private Service Connect (PSC)

NOTA:consulta la documentazione di Cloud NFGW per le funzionalità supportate più recenti e le limitazioni delle regole delle policy del firewall per i target del bilanciatore del carico.

Cosa imparerai

Abilitazione delle regole di base della policy del firewall Cloud NGFW che hanno come target i bilanciatori del carico
Protezione di un servizio di bilanciatore del carico consumer interno con backend di istanze VM e PSC
Test dell'accesso client e verifica dei log firewall

Cosa serve

Un progetto Google Cloud
Familiarità con i concetti di networking di Google Cloud e con l'utilizzo di Google Cloud CLI
Autorizzazioni IAM: roles/compute.instanceAdmin.v1, roles/compute.networkAdmin, roles/compute.securityAdmin e roles/storage.admin

2. Concetti

Livelli delle funzionalità del firewall

Cloud NGFW ha tre livelli di funzionalità: Essentials, Standard ed Enterprise. Ogni livello progressivo offre ulteriori livelli di funzionalità di filtro e ispezione del traffico di rete.

Un riepilogo delle funzionalità di filtraggio di Cloud NGFW Essentials:

Livello	Capacità	Livelli di rete	Esempio di parametri delle regole
Essentials	Filtro indirizzo e intervallo IP	IP	`--src-ip-ranges=1.1.1.0/24,2.2.2.2/32`
Essentials	Gruppi di indirizzi	IP	`--src-address-groups=special-ranges`
Essentials	Filtro protocolli e porte	TCP	`--layer4-configs=tcp`
Essentials	Tag protetti	Metadati	`--src-secure-tags=tagValues/987654321098`
Essentials	Filtro per tipo di rete	IP / metadati	`--src-network-type=INTRA_VPC`

Le regole di forwarding del bilanciatore del carico definiscono esplicitamente la porta TCP di destinazione. Il parametro della regola firewall --layer4-configs= può specificare solo tcp. Il valore della porta è implicito nella regola di forwarding stessa.

I gruppi di indirizzi e i tipi di rete possono essere utili per rendere più efficienti le regole delle policy del firewall. I tipi di rete VPC_NETWORKS e INTRA_VPC sono supportati con le regole dei criteri del firewall per i bilanciatori del carico.

NOTA:le regole delle policy del firewall per i bilanciatori del carico supportano solo --direction=INGRESS. Queste regole sono progettate per controllare l'accesso ai servizi esposti dal bilanciatore del carico.

Filtro del piano dati

Le funzionalità di Cloud NFGW Essentials coprono le regole firewall stateful di base di livello 3 (indirizzo IP) e livello 4 (porta TCP). Tutte queste funzionalità delle regole dei criteri firewall vengono eseguite in modo efficiente nel piano dati del bilanciatore del carico senza la necessità di un'ispezione completa dei pacchetti.

Le regole delle policy Cloud NGFW Essentials che hanno come target le istanze VM vengono applicate nel fabric della rete VPC distribuita come parte della rete software-defined (Andromeda) di base di Google Cloud. Le regole di filtro dei pacchetti e delle policy firewall vengono applicate a livello di hypervisor di ogni singola istanza VM, prima che il pacchetto raggiunga l'interfaccia di rete dell'istanza VM.

Le regole delle policy Essentials di Cloud NGFW che hanno come target i bilanciatori del carico vengono applicate utilizzando le tecnologie sottostanti dei bilanciatori del carico Google Cloud, in particolare l'infrastruttura del proxy di servizio Envoy. Utilizzando lo stesso modello di risorse e la stessa struttura di regole di Cloud NFGW, il filtro dei pacchetti stateful viene applicato direttamente nel data plane del bilanciamento del carico basato su proxy.

Destinazioni del bilanciatore del carico

Esistono alcune differenze fondamentali tra le norme Cloud NGFW che hanno come target i bilanciatori del carico e le norme che hanno come target le istanze VM.

Le regole delle policy del firewall possono essere applicate a un singolo bilanciatore del carico specificando --target-type=INTERNAL_MANAGED_LB insieme al riferimento specifico alla regola di forwarding del bilanciatore del carico --target-forwarding-rules=FR_NAME. Per scegliere come target tutte le regole di forwarding del bilanciatore del carico nella regione di rete VPC (dove la regione è definita dall'ambito della policy), il riferimento specifico deve essere omesso ed è necessaria solo l'opzione --target-type=INTERNAL_MANAGED_LB.

Se il parametro --target-type non è impostato nella configurazione della regola, la regola viene applicata automaticamente a tutte le istanze VM e non ai bilanciatori del carico.

Rete codelab

Questo codelab utilizza un singolo progetto con una rete VPC e le seguenti risorse:

Due subnet regionali
Un criterio firewall di rete a livello di regione
Tre bilanciatori del carico delle applicazioni interni regionali
- www Servizio HTTP con backend di gruppo di istanze VM
- api Servizio HTTP con backend di gruppo di istanze VM
- gcs Servizio HTTPS con backend NEG PSC per le API di Google
Due istanze VM per testare varie norme di autorizzazione e negazione

Fig. 1 Rete di codelab

Le regole delle policy del firewall che hanno come target i bilanciatori del carico sono collegate alle risorse delle regole di forwarding del bilanciatore del carico. I bilanciatori del carico sono costituiti da risorse definite singolarmente e configurate insieme per fornire un servizio di bilanciamento del carico completo. La definizione della regola di forwarding fa riferimento direttamente a una risorsa proxy di destinazione specifica definita per la regola.

Fig. 1 Cloud NFGW per le risorse del bilanciatore del carico

I filtri Cloud NGFW Essentials sono programmati nel data plane del bilanciatore del carico e implementati a livello del servizio proxy di destinazione definito, in modo analogo a un'interfaccia di istanza VM, utilizzando gli stessi meccanismi firewall distribuiti e coerenti per applicare i criteri.

3. Configurazione del progetto

Accedere al progetto

Questo codelab utilizza un singolo progetto cloud di Google. I passaggi di configurazione utilizzano i comandi della shell Linux e dell'interfaccia a riga di comando gcloud cli.

Inizia accedendo alla riga di comando del progetto Google Cloud:

Cloud Shell all'indirizzo shell.cloud.google.com o
Un terminale locale con gcloud CLI installata

Imposta l'ID progetto

gcloud config set project YOUR_PROJECT_ID_HERE

Abilitare i servizi API

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  compute.googleapis.com \
  dns.googleapis.com \
  networksecurity.googleapis.com \
  certificatemanager.googleapis.com

Imposta le variabili di ambiente della shell

# set your region preference
export REGION_1="us-west1"

# set your zone preference
export ZONE_1="us-west1-c"

# fetch project info and verify vars set
export PROJECT_ID=$(gcloud config list --format="value(core.project)")
export PROJECT_NO=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
echo ${REGION_1}
echo ${ZONE_1}
echo ${PROJECT_ID}
echo ${PROJECT_NO}

4. Fondamenti di rete

In questa sezione eseguirai il deployment di una base di rete con:

Rete VPC globale e subnet regionali
Policy del firewall di rete a livello di regione per proteggere la rete VPC
router Cloud e Cloud NAT per i server per recuperare i pacchetti software
Prenotazioni di indirizzi IP e record DNS per l'ingresso del bilanciatore del carico

Crea risorse di rete

# create vpc network
gcloud compute networks create vnet-foo --subnet-mode=custom

# create subnet for clients
gcloud compute networks subnets create subnet-foo-1 \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=10.0.0.0/24 \
  --enable-private-ip-google-access

# create subnet for backend servers
gcloud compute networks subnets create subnet-foo-2 \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=172.16.0.0/24 \
  --enable-private-ip-google-access

# create proxy subnet
gcloud compute networks subnets create subnet-foo-3 \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=172.16.128.0/23

Crea i componenti del firewall

La policy di base del firewall di rete regionale creata qui verrà utilizzata in un secondo momento quando aggiungerai target specifici del bilanciatore del carico. Il criterio deve trovarsi nella stessa regione del bilanciatore del carico.

Crea gruppo di indirizzi

Inizia creando un gruppo di indirizzi per identificare gli intervalli IP dei probe del controllo di integrità di origine che supportano la funzionalità del bilanciatore del carico. Questi intervalli devono essere consentiti affinché i backend del bilanciatore del carico siano considerati integri. Verrà utilizzato anche in un secondo momento con le regole delle policy del firewall che hanno come target i bilanciatori del carico.

# create address group
gcloud network-security address-groups create uhc-probes \
  --description="health check probes" \
  --type=IPv4 \
  --capacity=42 \
  --location=${REGION_1}

# add ip ranges to address group
gcloud network-security address-groups add-items uhc-probes \
  --items=35.191.0.0/16,130.211.0.0/22 \
  --location=${REGION_1}

Crea policy firewall

# create fw policy
gcloud compute network-firewall-policies create fw-policy-foo-${REGION_1} \
  --description="foo fw ${REGION_1}" \
  --region=${REGION_1}

# create fw policy rule to allow in iap
gcloud compute network-firewall-policies rules create 1001 \
  --description="allow iap for ssh" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:22 \
  --src-ip-ranges=35.235.240.0/20

# create fw policy rule to allow in health checks
gcloud compute network-firewall-policies rules create 1002 \
  --description="allow health checks to backends" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes

# create fw policy rule to allow in lb proxies
gcloud compute network-firewall-policies rules create 1003 \
  --description="allow lb proxy" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:80,tcp:443,tcp:8080 \
  --src-ip-ranges=172.16.128.0/23

# associate fw policy to vnet
gcloud compute network-firewall-policies associations create \
  --name=fw-policy-association-foo-${REGION_1} \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --network=vnet-foo \
  --firewall-policy-region=${REGION_1}

Configura i servizi di rete

Crea router Cloud e gateway NAT

# create router for nat
gcloud compute routers create cr-nat-foo \
  --network=vnet-foo \
  --asn=16550 \
  --region=${REGION_1}

# create nat gateway
gcloud compute routers nats create natgw-foo \
  --router=cr-nat-foo \
  --region=${REGION_1} \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

Prenota gli indirizzi IP

# reserve vip for lb www service
gcloud compute addresses create vip-foo-www \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.101

# reserve vip for lb api service
gcloud compute addresses create vip-foo-api \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.102

# reserve vip for lb gcs service
gcloud compute addresses create vip-foo-gcs \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.103

Crea record DNS

# create dns zone
gcloud dns managed-zones create zone-foo \
  --description="private zone for foo" \
  --dns-name=foo.com \
  --networks=vnet-foo \
  --visibility=private

# create dns record for www service
gcloud dns record-sets create www.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.101"

# create dns record for api service
gcloud dns record-sets create api.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.102"

# create dns record for gcs service
gcloud dns record-sets create gcs.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.103"

Con questo si conclude la parte relativa alla configurazione della rete. Ora passiamo alla configurazione dei bilanciatori del carico.

5. Servizi di bilanciamento del carico

In questa sezione, implementerai i componenti del bilanciatore del carico (servizi di backend, mappe URL, proxy di destinazione e regole di forwarding) per tre servizi:

Servizio www (ilb-foo-www) sulla porta 80
Servizio api (ilb-foo-api) sulla porta 8080
Servizio gcs (ilb-foo-gcs) sulla porta 443 con certificato TLS

Insieme alle risorse di backend di supporto:

Istanze VM che eseguono server HTTP in un gruppo di istanze gestite
Gruppo di endpoint di rete (NEG) Private Service Connect (PSC) per le API di Google
Bucket Google Cloud Storage (GCS)

Configurare le risorse di backend

Crea server del gruppo di istanze VM

Il bilanciatore del carico www utilizzerà i server di backend del gruppo di istanze VM che eseguono il server web Apache in ascolto sulla porta 80.

Il bilanciatore del carico api utilizzerà lo stesso gruppo di istanze VM in ascolto sulla porta 8080.

# create vm startup config with http server
cat > vm-server-startup.sh << 'OEOF'
#! /bin/bash
set -e
apt-get update
apt-get install apache2 -y
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone | cut -d/ -f4)"
echo "www served from: $vm_hostname in zone $vm_zone on port 80" | \
tee /var/www/html/index.html
echo "Listen 8080" | tee -a /etc/apache2/ports.conf
mkdir -p /var/www/api
echo "api served from: $vm_hostname in zone $vm_zone on port 8080" | \
tee /var/www/api/index.html
tee /etc/apache2/sites-available/api.conf << EOF
<VirtualHost *:8080>
    DocumentRoot /var/www/api
</VirtualHost>
EOF
a2ensite api.conf
systemctl restart apache2
OEOF

# create managed instance group template
gcloud compute instance-templates create mig-template-foo \
  --machine-type=e2-micro \
  --network=vnet-foo \
  --region=${REGION_1} \
  --subnet=subnet-foo-2 \
  --no-address \
  --shielded-secure-boot \
  --metadata-from-file=startup-script=vm-server-startup.sh

# create regional managed instance group
gcloud compute instance-groups managed create mig-foo \
  --region=${REGION_1} \
  --size=2 \
  --template=mig-template-foo \
  --base-instance-name=service-foo

# create named ports for instance group
gcloud compute instance-groups managed set-named-ports mig-foo \
  --named-ports=www-port:80,api-port:8080 \
  --region=${REGION_1}

Crea bucket di archiviazione

Il bilanciatore del carico gcs utilizzerà il backend NEG PSC per connettersi tramite il frontend delle API di Google al bucket Cloud Storage.

# create random bucket name
export BUCKET=$(openssl rand -hex 12)
echo ${BUCKET}

NOTA: le variabili di ambiente vengono perse una volta chiusa la sessione della shell. Se necessario, annota il nome del bucket per completarlo in una sessione futura.

# create bucket
gcloud storage buckets create gs://${BUCKET} --location=${REGION_1}

# give compute sa object admin role on bucket
gcloud storage buckets add-iam-policy-binding gs://${BUCKET} \
  --member=serviceAccount:${PROJECT_NO}-compute@developer.gserviceaccount.com \
  --role=roles/storage.objectAdmin

Crea certificato

Il bilanciatore del carico gcs terminerà le richieste HTTPS del client con un certificato autofirmato di cui è stato eseguito il deployment sul proxy HTTPS di destinazione.

# create cert
openssl req -x509 -newkey rsa:2048 \
  -nodes \
  -days 365 \
  -keyout foo-gcs-key.pem \
  -out foo-gcs-cert.pem \
  -subj "/CN=Foo, Inc." \
  -addext "subjectAltName=DNS:gcs.foo.com"

# upload to certificate manager
gcloud certificate-manager certificates create cert-foo-gcs \
  --private-key-file=foo-gcs-key.pem \
  --certificate-file=foo-gcs-cert.pem \
  --location=${REGION_1}

Creare i componenti del bilanciatore del carico

Utilizza il seguente script per automatizzare il deployment dei componenti del bilanciatore del carico. Ciò contribuirà a migliorare la velocità e l'accuratezza di tutti gli elementi di configurazione coinvolti.

Esegui il deployment dello script di creazione del bilanciatore del carico

# create script file
cat > create_lbs.sh << EOF
#!/bin/bash
set -e

# --- Create load balancer for www service port 80 ---
echo "--- Creating Load Balancer for WWW Service (ilb-foo-www) on port 80 ---"

echo "ilb-foo-www: creating health check (hc-foo-www)"
gcloud compute health-checks create http hc-foo-www \
  --use-serving-port \
  --region=${REGION_1}

echo "ilb-foo-www: creating backend service (bes-foo-www)"
gcloud compute backend-services create bes-foo-www \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --port-name=www-port \
  --health-checks=hc-foo-www \
  --health-checks-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: adding managed instance group (mig-foo) to backend service (bes-foo-www)"
gcloud compute backend-services add-backend bes-foo-www \
  --balancing-mode=UTILIZATION \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: creating url map (ilb-foo-www)"
gcloud compute url-maps create ilb-foo-www \
  --default-service=bes-foo-www \
  --region=${REGION_1}

echo "ilb-foo-www: creating target http proxy (proxy-foo-www)"
gcloud compute target-http-proxies create proxy-foo-www \
  --url-map=ilb-foo-www \
  --url-map-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: creating forwarding rule (fr-foo-www)"
gcloud compute forwarding-rules create fr-foo-www \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-www \
  --ports=80 \
  --target-http-proxy=proxy-foo-www \
  --target-http-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for WWW Service (ilb-foo-www) ---"
echo

# --- Create load balancer for api service port 8080 ---
echo "--- Creating Load Balancer for API Service (ilb-foo-api) on port 8080 ---"

echo "ilb-foo-api: creating health check (hc-foo-api)"
gcloud compute health-checks create http hc-foo-api \
  --use-serving-port \
  --region=${REGION_1}

echo "ilb-foo-api: creating backend service (bes-foo-api)"
gcloud compute backend-services create bes-foo-api \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --port-name=api-port \
  --health-checks=hc-foo-api \
  --health-checks-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: adding managed instance group (mig-foo) to backend service (bes-foo-api)"
gcloud compute backend-services add-backend bes-foo-api \
  --balancing-mode=UTILIZATION \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: creating url map (ilb-foo-api)"
gcloud compute url-maps create ilb-foo-api \
  --default-service=bes-foo-api \
  --region=${REGION_1}

echo "ilb-foo-api: creating target http proxy (proxy-foo-api)"
gcloud compute target-http-proxies create proxy-foo-api \
  --url-map=ilb-foo-api \
  --url-map-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: creating forwarding rule (fr-foo-api)"
gcloud compute forwarding-rules create fr-foo-api \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-api \
  --ports=8080 \
  --target-http-proxy=proxy-foo-api \
  --target-http-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for API Service (ilb-foo-api) ---"
echo

# --- Create load balancer for gcs service port 443 ---
echo "--- Creating Load Balancer for GCS Service (ilb-foo-gcs) on port 443 ---"

echo "ilb-foo-gcs: creating network endpoint group (neg-psc-gcs)"
gcloud compute network-endpoint-groups create neg-psc-gcs \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=storage.${REGION_1}.rep.googleapis.com \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating backend service (bes-foo-gcs)"
gcloud compute backend-services create bes-foo-gcs \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTPS \
  --region=${REGION_1}

echo "ilb-foo-gcs: adding network endpoint group (neg-psc-gcs) to backend service (bes-foo-gcs)"
gcloud compute backend-services add-backend bes-foo-gcs \
  --network-endpoint-group=neg-psc-gcs \
  --network-endpoint-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating url map (ilb-foo-gcs)"
gcloud compute url-maps create ilb-foo-gcs \
  --default-service=bes-foo-gcs \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating target https proxy (proxy-foo-gcs)"
gcloud compute target-https-proxies create proxy-foo-gcs \
  --url-map=ilb-foo-gcs \
  --url-map-region=${REGION_1} \
  --certificate-manager-certificates=cert-foo-gcs \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating forwarding rule (fr-foo-gcs)"
gcloud compute forwarding-rules create fr-foo-gcs \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-gcs \
  --ports=443 \
  --target-https-proxy=proxy-foo-gcs \
  --target-https-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for GCS Service (ilb-foo-gcs) ---"
echo

echo "All load balancers created successfully."
EOF

# make script executable
chmod +x create_lbs.sh

# run script
./create_lbs.sh

NOTA: il completamento di questo script richiede alcuni minuti.

Verifica la creazione del bilanciatore del carico

Verifica che le regole di forwarding e i servizi di backend siano stati implementati.

# check forwarding rules
gcloud compute forwarding-rules list

# check backend services
gcloud compute backend-services list

Con questo si conclude la parte di configurazione del bilanciatore del carico. Ora passiamo alla configurazione delle istanze VM client.

6. Accesso client

Crea risorse client VM

In questa sezione, eseguirai il deployment dei client e verificherai la connettività end-to-end.

crea istanze VM

# set variables for client ip addresses
export VM_ALLOW_IP="10.0.0.11"
export VM_DENY_IP="10.0.0.12"
echo ${VM_ALLOW_IP}
echo ${VM_DENY_IP}

# create client 1 vm
gcloud compute instances create vm-allow \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-foo-1 \
  --no-address \
  --private-network-ip=${VM_ALLOW_IP} \
  --scopes=cloud-platform \
  --shielded-secure-boot

# create client 2 vm
gcloud compute instances create vm-deny \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-foo-1 \
  --no-address \
  --private-network-ip=${VM_DENY_IP} \
  --scopes=cloud-platform \
  --shielded-secure-boot

Testa servizio di base

Test dal client `vm-allow`

NOTA:le istanze VM verranno attivate e saranno accessibili tramite ssh utilizzando IAP poco dopo l'emissione dei comandi instances create. Se la richiesta non va a buon fine al primo tentativo, potresti dover attendere un attimo.

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

Prova a caricare un file su Google Cloud Storage tramite il bilanciatore del carico.

# send request to foo gcs service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  echo 'test one on the way' > test-upload-1.txt
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k -X POST \"https://gcs.foo.com/upload/storage/v1/b/${BUCKET}/o?uploadType=media&name=test-upload-object-1.txt\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -H \"Content-Type: text/plain\" \
  --data-binary @test-upload-1.txt"

La risposta dell'API Storage di Cloud Storage conferma che il percorso di rete funziona correttamente.

Test dal client `vm-deny`

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

# send request to foo gcs service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  echo 'test two on the way' > test-upload-2.txt
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k -X POST \"https://gcs.foo.com/upload/storage/v1/b/${BUCKET}/o?uploadType=media&name=test-upload-object-2.txt\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -H \"Content-Type: text/plain\" \
  --data-binary @test-upload-2.txt"

NOTA:anche questi test dovrebbero riuscire perché nessuna regola firewall ha ancora preso di mira il bilanciatore del carico.

Con questo si concludono tutte le sezioni principali della configurazione. Ora passiamo alla creazione delle regole firewall del bilanciatore del carico.

7. Firewall del bilanciatore del carico

In questa sezione, eseguirai il deployment delle regole dei criteri firewall destinate ai bilanciatori del carico. La sequenza di configurazioni creerà una postura di sicurezza che consente l'accesso a vm-allow e blocca il traffico vm-deny a tutti i servizi.

Consenti il traffico selezionato a `fr-foo-www`

Aggiungi una nuova regola del criterio firewall al criterio firewall esistente fw-policy-foo-${REGION_1}

Consenti un intervallo IP di origine che includa vm-allow ed escluda gli indirizzi IP vm-deny
Aggiungi un filtro di origine aggiuntivo INTRA_VPC per utilizzare il tipo di rete in una regola della policy del firewall che ha come target il bilanciatore del carico.

Il tipo di rete di origine di INTRA_VPC e VPC_NETWORKS è supportato nelle regole delle policy firewall che hanno come target i bilanciatori del carico se utilizzato in combinazione con un altro parametro di origine. La logica di valutazione è un AND tra i due parametri di origine. In questo caso, il traffico deve soddisfare i criteri per INTRA_VPC e --src-ip-ranges=${VM_ALLOW_IP}/32 per essere consentito.

Crea una regola per consentire il `vm-allow`targeting`fr-foo-www`

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2001 \
  --description="allow vm traffic to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-network-type=INTRA_VPC \
  --src-ip-ranges=${VM_ALLOW_IP}/32 \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

Test dal client `vm-allow`

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

Test dal client `vm-deny`

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

NOTA:questa operazione va a buon fine perché il comportamento della regola della policy del firewall predefinita implicita per i bilanciatori del carico è --action=allow. Per modificare questa impostazione, è necessaria una regola di negazione predefinita (catchall).

Nega il traffico predefinito a `fr-foo-www`

Aggiungi una nuova regola della policy del firewall con priorità inferiore (numero di priorità più elevato).

Nega tutto il traffico da qualsiasi indirizzo IP di origine
Il traffico da vm-allow a fr-foo-www sarà consentito prima di raggiungere la regola di negazione

Crea una regola per negare il targeting del traffico `fr-foo-www`

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2999 \
  --description="allow vm traffic to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=deny \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-ip-ranges=0.0.0.0/0 \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

Considerazioni per i controlli di integrità

Come per le regole delle policy firewall che hanno come target le istanze VM, la regola di negazione in entrata catch-all (implicita) predefinita blocca il traffico proveniente dagli intervalli di probe del controllo di integrità destinato ai backend del bilanciatore del carico. Pertanto, è stata configurata una regola di autorizzazione esplicita per consentire gli intervalli di probe del controllo di integrità in entrata (vedi regola 1002).

IMPORTANTE: allo stesso modo, quando crei una regola di negazione in entrata generica (esplicita) per le destinazioni del bilanciatore del carico, devi creare un'altra regola con priorità più elevata (numero di priorità inferiore) per consentire l'ingresso dall'intervallo di probe di controllo di integrità. Questa regola deve avere come target i bilanciatori del carico.

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2002 \
  --description="allow health checks to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

Test dal client `vm-deny`

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

Ora dovrebbe non riuscire perché la regola firewall 2999 nega tutto il traffico proveniente dalla rete VPC. La regola con priorità più elevata (numero di priorità inferiore) 2001 consentiva solo un intervallo di origine che include vm-allow.

Interrompi il processo curl premendo Ctrl+C.

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

vm-deny può ancora accedere al servizio API. L'operazione è riuscita perché la regola firewall è stata applicata solo in modo specifico alla regola di forwarding fr-foo-www e non ha interessato fr-foo-api.

Aggiorna le regole in modo che abbiano come target tutti i bilanciatori del carico

NOTA:le regole dei criteri firewall possono essere applicate a tutti i bilanciatori del carico in una rete VPC omettendo --target-forwarding-rules=FR_NAME.

Modifica le regole dei criteri firewall in modo che ora si applichino a tutti i target delle regole di forwarding del bilanciatore del carico nella rete VPC.

Crea una nuova regola consenti in entrata 2003 che ha come target tutte le regole di forwarding per consentire il traffico VM (intervallo IP vm-allow)
Crea una nuova regola consenti in entrata 2004 che abbia come target tutte le regole di forwarding per consentire il traffico dei controlli di integrità (gruppo di indirizzi uhc-probes).
Crea una nuova regola di negazione in entrata 2998 che ha come target tutte le regole di forwarding come negazione catch-all per tutto il resto del traffico

Modifica le regole firewall in modo che abbiano come target tutti i bilanciatori del carico

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2003 \
  --description="allow vm traffic to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp  \
  --src-ip-ranges=${VM_ALLOW_IP}/32 \
  --target-type=INTERNAL_MANAGED_LB

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2004 \
  --description="allow health checks to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes \
  --target-type=INTERNAL_MANAGED_LB

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2998 \
  --description="deny all vnet traffic to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=deny \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-ip-ranges=0.0.0.0/0 \
  --target-type=INTERNAL_MANAGED_LB

Le regole dei criteri firewall precedenti che hanno come target regole di forwarding del bilanciatore del carico esplicite possono essere rimosse, in quanto ora sono ridondanti con le regole che hanno come target tutte le regole di forwarding nella rete VPC.

# delete redundant fw policy rules
gcloud beta compute network-firewall-policies rules delete 2001 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud beta compute network-firewall-policies rules delete 2002 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud beta compute network-firewall-policies rules delete 2999 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

Test dal client `vm-deny`

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

Ora dovrebbe non riuscire perché fr-foo-api è anche il target di tutte le regole dei criteri del firewall con --target-type=INTERNAL_MANAGED_LB.

Interrompi il processo curl premendo Ctrl+C.

Prova a scaricare un file da Google Cloud Storage tramite il bilanciamento del carico.

# send request to foo gcs service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k \"https://gcs.foo.com/storage/v1/b/${BUCKET}/o/test-upload-object.txt?alt=media\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -o test-download.txt"

Interrompi il processo curl premendo Ctrl+C.

Test dal client `vm-allow`

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

# send request to foo gcs service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k \"https://gcs.foo.com/storage/v1/b/${BUCKET}/o/test-upload-object-1.txt?alt=media\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -o test-download-1.txt"

Verificare i contenuti del download

# send request from vm
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  cat test-download-1.txt"

Tutti i servizi di bilanciamento del carico sono disponibili per vm-allow e sono bloccati correttamente per vm-deny.

Con questo si conclude la parte relativa ai test. Vediamo ora brevemente il logging.

8. Logging delle regole firewall

Il formato dei log firewall ha campi e record per le regole che hanno come target i bilanciatori del carico (--target-type=INTERNAL_MANAGED_LB).

I log conterranno un campo aggiuntivo denominato load_balancer_details con ulteriori informazioni sul bilanciatore del carico a cui è stata indirizzata la regola della policy del firewall. Ciò è analogo al formato del campo InstanceDetails quando le istanze VM sono prese di mira nelle regole delle policy del firewall.

load_balancer_details.forwarding_rule_name mostra la regola di forwarding di destinazione della policy del firewall
load_balancer_details.type indica la variante del bilanciatore del carico basato su proxy di destinazione
load_balancer_details.url_map_name registra la risorsa della mappa URL utilizzata quando il tipo è un bilanciatore del carico delle applicazioni

Visualizza i log

Esegui query sui log del firewall per visualizzare i risultati delle regole dei criteri firewall.

gcloud logging read \
  "logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Ffirewall \
  AND (jsonPayload.connection.src_ip=\"${VM_ALLOW_IP}\" OR jsonPayload.connection.src_ip=\"${VM_DENY_IP}\")" \
  --project=${PROJECT_ID} \
  --freshness=30m \
  --limit=50 \
  --format="table(
    timestamp:label=TIMESTAMP,
    jsonPayload.connection.src_ip:label=SRC_IP,
    jsonPayload.connection.src_port:label=SRC_PORT,
    jsonPayload.connection.dest_ip:label=DEST_IP,
    jsonPayload.connection.dest_port:label=DEST_PORT,
    jsonPayload.disposition:label=ACTION,
    jsonPayload.rule_details.priority:label=PRIORITY,
    jsonPayload.load_balancer_details.forwarding_rule_name:label=FWD_RULE
  )"

L'output del log mostra le regole effettive applicate dal criterio:

Tutto il traffico vm-allow verso tutti i bilanciatori del carico è consentito dalla regola 2011
Tutto il traffico destinato ai bilanciatori del carico viene negato dalla regola 2998

TIMESTAMP                       SRC_IP     SRC_PORT  DEST_IP     DEST_PORT  ACTION   PRIORITY  FWD_RULE
YYYY-MM-DDTHH:MM:SS.850967068Z  10.0.0.11  48480     10.0.0.103  443        ALLOWED  2003      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.418613380Z  10.0.0.11  37340     10.0.0.101  80         ALLOWED  2003      fr-foo-www
YYYY-MM-DDTHH:MM:SS.213234118Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.981484412Z  10.0.0.11  41738     10.0.0.101  80         ALLOWED  2003      fr-foo-www
YYYY-MM-DDTHH:MM:SS.189358071Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.061463883Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.965498098Z  10.0.0.12  53284     10.0.0.102  8080       DENIED   2998      fr-foo-api

I log sono visualizzabili anche nella console Google Cloud utilizzando Esplora log. Vai a console.cloud.google.com/logs/query e utilizza il log firewall VPC standard compute.googleapis.com/firewall.

logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Ffirewall

La parte relativa alla registrazione termina qui. Passiamo a liberare spazio.

9. Esegui la pulizia

# delete client compute resources
gcloud -q compute instances delete vm-deny --zone=${ZONE_1}

gcloud -q compute instances delete vm-allow --zone=${ZONE_1}

# next

# delete load balancer resources for gcs
gcloud -q compute forwarding-rules delete fr-foo-gcs --region=${REGION_1}

gcloud -q compute target-https-proxies delete proxy-foo-gcs --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-gcs --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-gcs --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-gcs --region=${REGION_1}

# next

# delete load balancer resources for api
gcloud -q compute forwarding-rules delete fr-foo-api --region=${REGION_1}

gcloud -q compute target-http-proxies delete proxy-foo-api --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-api --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-api --region=${REGION_1}

gcloud -q compute health-checks delete hc-foo-api --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-api --region=${REGION_1}

# next

# delete load balancer resources for www
gcloud -q compute forwarding-rules delete fr-foo-www --region=${REGION_1}

gcloud -q compute target-http-proxies delete proxy-foo-www --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-www --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-www --region=${REGION_1}

gcloud -q compute health-checks delete hc-foo-www --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-www --region=${REGION_1}

# next

# delete service backend resources
gcloud -q storage rm --recursive gs://${BUCKET}

gcloud -q certificate-manager certificates delete cert-foo-gcs --location=${REGION_1}

gcloud -q compute network-endpoint-groups delete neg-psc-gcs --region=${REGION_1}

gcloud -q compute instance-groups managed delete mig-foo --region=${REGION_1}

gcloud -q compute instance-templates delete mig-template-foo --global

# next

# delete dns, nat, fw resources
gcloud -q dns record-sets delete gcs.foo.com --type=A --zone=zone-foo

gcloud -q dns record-sets delete api.foo.com --type=A --zone=zone-foo

gcloud -q dns record-sets delete www.foo.com --type=A --zone=zone-foo

gcloud -q dns managed-zones delete zone-foo

gcloud -q compute routers delete cr-nat-foo --region=${REGION_1}

gcloud -q compute network-firewall-policies associations delete \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --name=fw-policy-association-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud -q compute network-firewall-policies delete fw-policy-foo-${REGION_1} --region=${REGION_1}

gcloud -q network-security address-groups delete uhc-probes --location=${REGION_1}

# next

# delete network resources
gcloud -q compute networks subnets delete subnet-foo-3 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-foo-2 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-foo-1 --region=${REGION_1}

gcloud -q compute networks delete vnet-foo

# next

# delete shell variables and local files
unset PROJECT_ID REGION_1 ZONE_1 VM_ALLOW_IP VM_DENY_IP BUCKET

rm vm-server-startup.sh create_lbs.sh foo-gcs-key.pem foo-gcs-cert.pem

# end

10. Conclusione

Complimenti! Hai configurato correttamente Cloud NGFW Essentials per i bilanciatori del carico.

Non esitare a inviare commenti, domande o correzioni utilizzando questo modulo di feedback.

Grazie.

Cloud NGFW Essentials per i bilanciatori del carico

1. Introduzione

Cosa imparerai

Cosa serve

2. Concetti

Livelli delle funzionalità del firewall

Filtro del piano dati

Destinazioni del bilanciatore del carico

Rete codelab

3. Configurazione del progetto

Accedere al progetto

Imposta l'ID progetto

Abilitare i servizi API

Imposta le variabili di ambiente della shell

4. Fondamenti di rete

Crea risorse di rete

Crea i componenti del firewall

Crea gruppo di indirizzi

Crea policy firewall

Configura i servizi di rete

Crea router Cloud e gateway NAT

Prenota gli indirizzi IP

Crea record DNS

5. Servizi di bilanciamento del carico

Configurare le risorse di backend

Crea server del gruppo di istanze VM

Crea bucket di archiviazione

Crea certificato

Creare i componenti del bilanciatore del carico

Esegui il deployment dello script di creazione del bilanciatore del carico

Verifica la creazione del bilanciatore del carico

6. Accesso client

Crea risorse client VM

crea istanze VM

Testa servizio di base

Test dal client vm-allow

Test dal client vm-deny

7. Firewall del bilanciatore del carico

Consenti il traffico selezionato a fr-foo-www

Crea una regola per consentire il vm-allowtargetingfr-foo-www

Test dal client vm-allow

Test dal client vm-deny

Nega il traffico predefinito a fr-foo-www

Crea una regola per negare il targeting del traffico fr-foo-www

Considerazioni per i controlli di integrità

Test dal client vm-deny

Aggiorna le regole in modo che abbiano come target tutti i bilanciatori del carico

Modifica le regole firewall in modo che abbiano come target tutti i bilanciatori del carico

Test dal client vm-deny

Test dal client vm-allow

8. Logging delle regole firewall

Visualizza i log

9. Esegui la pulizia

10. Conclusione

Test dal client `vm-allow`

Test dal client `vm-deny`

Consenti il traffico selezionato a `fr-foo-www`

Crea una regola per consentire il `vm-allow`targeting`fr-foo-www`

Test dal client `vm-allow`

Test dal client `vm-deny`

Nega il traffico predefinito a `fr-foo-www`

Crea una regola per negare il targeting del traffico `fr-foo-www`

Test dal client `vm-deny`

Test dal client `vm-deny`

Test dal client `vm-allow`