Cloud NGFW Essentials für Load Balancer

1. Einführung

In diesem Codelab wird die Cloud NGFW (Next Generation Firewall) Essentials für interne Application Load Balancer (ALB) und Proxy-Network Load Balancer (NLB) mit regionalen Netzwerk-Firewallrichtlinien untersucht.

Cloud NGFW ist ein vollständig verteilter Firewalldienst mit erweiterten Funktionen für den Schutz vor Bedrohungen und die Mikrosegmentierung, um Google Cloud-Arbeitslasten zu schützen. Wenn Sie Cloud NGFW auf Load-Balancer-Ebene aktivieren, werden einheitliche Firewallregeln auf TCP-Traffic angewendet, der in interne proxybasierte Load Balancer eingeht. Der Dienst vereinfacht die Bereitstellung eines Sicherheitsstatus für die Organisation, da Richtlinien für alle Dienste umfassender erzwungen werden.

In diesem Codelab werden die folgenden Cloud NGFW- und Cloud Load Balancing-Produkte und ‑Funktionen behandelt:

Cloud NGFW Essentials
Regionale Netzwerk-Firewallrichtlinien
Regionaler interner Application Load Balancer
Verwaltete Instanzgruppe (Managed Instance Group, MIG) als Backend und Netzwerk-Endpunktgruppe (Network Endpoint Group, NEG) von Private Service Connect (PSC)

HINWEIS:In der Cloud NFGW-Dokumentation finden Sie die neuesten unterstützten Funktionen und Einschränkungen von Firewallrichtlinienregeln für Load-Balancer-Ziele.

Lerninhalte

Einfache Cloud NGFW-Firewallrichtlinienregeln für Load Balancer aktivieren
Internen Nutzer-Load-Balancer-Dienst mit VM-Instanz- und PSC-Back-Ends schützen
Clientzugriff testen und Firewalllogs prüfen

Voraussetzungen

Ein Google Cloud-Projekt
Vertrautheit mit Google Cloud-Netzwerkkonzepten und der Verwendung der Google Cloud CLI
IAM-Berechtigungen: roles/compute.instanceAdmin.v1, roles/compute.networkAdmin, roles/compute.securityAdmin und roles/storage.admin

2. Konzepte

Firewall-Feature-Ebenen

Cloud NGFW bietet drei Funktionsstufen: Essentials, Standard und Enterprise. Jede progressive Stufe bietet zusätzliche Funktionen zum Filtern und Überprüfen des Netzwerkverkehrs.

Zusammenfassung der Filterfunktionen von Cloud NGFW Essentials:

Stufe	Funktion	Netzwerkschichten	Beispiel für Regelparameter
Essentials	Filtern nach IP-Adresse und ‑Bereich	IP	`--src-ip-ranges=1.1.1.0/24,2.2.2.2/32`
Essentials	Adressgruppen	IP	`--src-address-groups=special-ranges`
Essentials	Protokoll- und Portfilterung	TCP	`--layer4-configs=tcp`
Essentials	Sichere Tags	Metadaten	`--src-secure-tags=tagValues/987654321098`
Essentials	Filtern nach Netzwerktyp	IP / Metadaten	`--src-network-type=INTRA_VPC`

In Load-Balancer-Weiterleitungsregeln wird der Ziel-TCP-Port explizit definiert. Für den Parameter --layer4-configs= der Firewallregel kann nur tcp angegeben werden. Der Portwert ergibt sich aus der Weiterleitungsregel selbst.

Adressgruppen und Netzwerktypen können hilfreich sein, um Firewallrichtlinienregeln effizienter zu gestalten. Die Netzwerktypen VPC_NETWORKS und INTRA_VPC werden mit Firewallrichtlinienregeln für Load-Balancer unterstützt.

HINWEIS:Firewallrichtlinienregeln für Load-Balancer unterstützen nur --direction=INGRESS. Mit diesen Regeln soll der Zugriff auf Dienste gesteuert werden, die vom Load Balancer bereitgestellt werden.

Filterung auf Datenebene

Die Cloud NFGW Essentials-Funktionen umfassen grundlegende zustandsorientierte Firewallregeln für Layer 3 (IP-Adresse) und Layer 4 (TCP-Port). Diese Funktionen für Firewallrichtlinienregeln werden alle effizient in der Datenebene des Load Balancers ausgeführt, ohne dass eine vollständige Paketprüfung erforderlich ist.

Cloud NGFW Essentials-Richtlinienregeln, die auf VM-Instanzen ausgerichtet sind, werden in der verteilten VPC-Netzwerkstruktur als Teil des softwaredefinierten Kernnetzwerks von Google Cloud (Andromeda) erzwungen. Paketfilterung und Firewallrichtlinienregeln werden auf der Hypervisor-Ebene jeder einzelnen VM-Instanz durchgesetzt, bevor das Paket die Netzwerkschnittstelle der VM-Instanz erreicht.

Cloud NGFW-Richtlinienregeln für Load-Balancer werden mit den zugrunde liegenden Technologien von Google Cloud Load Balancing, insbesondere der Envoy-Serviceproxy-Infrastruktur, erzwungen. Mit demselben Cloud NFGW-Ressourcenmodell und derselben Regelstruktur wird die zustandsbehaftete Paketfilterung direkt in der Datenebene des proxybasierten Load Balancers erzwungen.

Load-Balancer-Ziele

Es gibt einige wichtige Unterschiede zwischen Cloud NGFW-Richtlinien, die auf Load Balancer ausgerichtet sind, und Richtlinien, die auf VM-Instanzen ausgerichtet sind.

Firewallrichtlinienregeln können auf einen einzelnen Load Balancer angewendet werden, indem Sie --target-type=INTERNAL_MANAGED_LB zusammen mit dem spezifischen Verweis auf die Weiterleitungsregel des Load Balancers --target-forwarding-rules=FR_NAME angeben. Wenn Sie alle Weiterleitungsregeln für Load-Balancer in der VPC-Netzwerkregion (wobei die Region durch die Richtlinie begrenzt wird) als Ziel festlegen möchten, sollte der spezifische Verweis weggelassen werden. Es ist nur das Flag --target-type=INTERNAL_MANAGED_LB erforderlich.

Wenn der Parameter --target-type in der Regelkonfiguration nicht festgelegt ist, wird die Regel standardmäßig automatisch auf alle VM-Instanzen angewendet, nicht jedoch auf die Load Balancer.

Codelab-Netzwerk

In diesem Codelab wird ein einzelnes Projekt mit einem VPC-Netzwerk und den folgenden Ressourcen verwendet:

Zwei regionale Subnetze
Eine regionale Netzwerk-Firewallrichtlinie
Drei regionale interne Application Load Balancer
- www HTTP-Dienst mit VM-Instanzgruppen-Back-End
- api HTTP-Dienst mit VM-Instanzgruppen-Back-End
- gcs HTTPS-Dienst mit PSC-NEG-Backend für Google APIs
Zwei VM-Instanzen zum Testen verschiedener Zulassungs- und Ablehnungsrichtlinien

Abbildung 1. Codelab-Netzwerk

Firewallrichtlinienregeln, die auf Load-Balancer ausgerichtet sind, sind mit den Weiterleitungsregelressourcen des Load-Balancers verknüpft. Load-Balancer bestehen aus individuell definierten Ressourcen, die zusammen konfiguriert werden, um einen vollständigen Load-Balancing-Dienst bereitzustellen. Die Definition der Weiterleitungsregel verweist direkt auf eine bestimmte Zielproxy-Ressource, die für sie definiert ist.

Abbildung 1. Cloud NGFW für Load-Balancer-Ressourcen

Cloud NGFW Essentials-Filter werden in die Data Plane des Load Balancers programmiert und auf der definierten Zielproxyschicht implementiert – analog zu einer VM-Instanzschnittstelle –. Dabei werden dieselben verteilten und konsistenten Firewallmechanismen verwendet, um Richtlinien zu erzwingen.

3. Projekt einrichten

Auf Ihr Projekt zugreifen

In diesem Codelab wird ein einzelnes Google Cloud-Projekt verwendet. Für die Konfigurationsschritte werden die gcloud cli-Befehlszeile und Linux-Shell-Befehle verwendet.

Rufen Sie zuerst die Befehlszeile Ihres Google Cloud-Projekts auf:

Cloud Shell unter shell.cloud.google.com oder
Ein lokales Terminal mit installiertem gcloud CLI

Projekt-ID festlegen

gcloud config set project YOUR_PROJECT_ID_HERE

API-Dienste aktivieren

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

Shell-Umgebungsvariablen festlegen

# 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. Netzwerkgrundlage

In diesem Abschnitt stellen Sie eine Netzwerkbasis mit Folgendem bereit:

Globales VPC-Netzwerk und regionale Subnetze
Regionale Netzwerk-Firewallrichtlinie zum Sichern des VPC-Netzwerks
Cloud Router und Cloud NAT für Server zum Abrufen von Softwarepaketen
IP-Adressreservierungen und DNS-Einträge für Load-Balancer-Ingress

Netzwerkressourcen erstellen

# 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

Firewallkomponenten erstellen

Die hier erstellte einfache regionale Netzwerk-Firewallrichtlinie wird später verwendet, wenn Load-Balancer-spezifische Ziele hinzugefügt werden. Die Richtlinie muss sich in derselben Region wie der Load Balancer befinden.

Adressgruppe erstellen

Erstellen Sie zuerst eine Adressgruppe, um die IP-Bereiche für Systemdiagnoseprüfungen zu identifizieren, die die Load-Balancer-Funktionalität unterstützen. Diese Bereiche müssen zugelassen werden, damit die Load-Balancer-Back-Ends als fehlerfrei gelten. Es wird später auch mit Firewallrichtlinienregeln verwendet, die auf Load Balancer ausgerichtet sind.

# 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}

Firewallrichtlinie erstellen

# 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}

Netzwerkdienste konfigurieren

Cloud Router und NAT-Gateway erstellen

# 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

IP-Adressen reservieren

# 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

DNS-Einträge erstellen

# 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"

Damit ist die Netzwerkeinrichtung abgeschlossen. Als Nächstes konfigurieren wir die Load-Balancer.

5. Load-Balancer-Dienste

In diesem Abschnitt stellen Sie Load-Balancer-Komponenten (Backend-Dienste, URL-Zuordnungen, Zielproxys und Weiterleitungsregeln) für drei Dienste bereit:

www-Dienst (ilb-foo-www) auf Port 80
api-Dienst (ilb-foo-api) auf Port 8080
gcs-Dienst (ilb-foo-gcs) auf Port 443 mit TLS-Zertifikat

Zusammen mit den unterstützenden Backend-Ressourcen:

VM-Instanzen, auf denen HTTP-Server in einer verwalteten Instanzgruppe ausgeführt werden
Netzwerk-Endpunktgruppe (NEG) von Private Service Connect (PSC) für Google APIs
Google Cloud Storage-Bucket (GCS)

Backend-Ressourcen einrichten

Server für VM-Instanzgruppe erstellen

Der www-Load Balancer verwendet die Backend-Server der VM-Instanzgruppe, auf denen der Apache-Webserver ausgeführt wird, der auf Port 80 lauscht.

Der api-Load-Balancer verwendet dieselbe VM-Instanzgruppe, die auf Port 8080 wartet.

# 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}

Storage-Bucket erstellen

Der gcs-Load Balancer verwendet das PSC-NEG-Backend, um über das Google APIs-Frontend eine Verbindung zum Cloud Storage-Bucket herzustellen.

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

HINWEIS:Umgebungsvariablen gehen verloren, sobald die Shell-Sitzung geschlossen wird. Notieren Sie sich den Bucket-Namen, falls Sie die Aufgabe in einer späteren Sitzung abschließen möchten.

# 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

Zertifikat erstellen

Der gcs-Load-Balancer beendet Client-HTTPS-Anfragen mit einem selbstsignierten Zertifikat, das auf dem Ziel-HTTPS-Proxy bereitgestellt wird.

# 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}

Load-Balancer-Komponenten erstellen

Verwenden Sie das folgende Skript, um die Bereitstellung der Load-Balancer-Komponenten zu automatisieren. Das trägt zu einer höheren Geschwindigkeit und Genauigkeit bei allen beteiligten Konfigurationselementen bei.

Skript zum Erstellen von Load Balancern bereitstellen

# 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

HINWEIS:Die Ausführung dieses Skripts dauert einige Minuten.

Erstellung des Load Balancers prüfen

Prüfen Sie, ob Weiterleitungsregeln und Backend-Dienste bereitgestellt wurden.

# check forwarding rules
gcloud compute forwarding-rules list

# check backend services
gcloud compute backend-services list

Damit ist die Einrichtung des Load-Balancers abgeschlossen. Als Nächstes werden die Client-VM-Instanzen konfiguriert.

6. Clientzugriff

VM-Clientressourcen erstellen

In diesem Abschnitt stellen Sie Clients bereit und prüfen die End-to-End-Verbindung.

VM-Instanzen erstellen

# 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

Referenzdienst testen

Test von Client `vm-allow`

HINWEIS:Die VM-Instanzen werden kurz nach Ausführung der instances create-Befehle online geschaltet und sind über ssh mit IAP zugänglich. Wenn die Anfrage beim ersten Versuch fehlschlägt, müssen Sie möglicherweise einen Moment warten.

# 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"

Laden Sie eine Datei über den Load Balancer in Google Cloud Storage hoch.

# 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"

Die Cloud Storage API-Antwort bestätigt, dass der Netzwerkpfad ordnungsgemäß funktioniert.

Test von 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"

HINWEIS:Diese Tests sollten ebenfalls erfolgreich sein, da noch keine Firewallregeln auf den Load-Balancer ausgerichtet sind.

Damit ist die Einrichtung abgeschlossen. Als Nächstes erstellen wir Firewallregeln für den Load-Balancer.

7. Load Balancer-Firewall

In diesem Abschnitt stellen Sie Firewallrichtlinienregeln für Load-Balancer bereit. Die Konfigurationsreihenfolge führt zu einem Sicherheitsstatus, der den vm-allow-Zugriff zulässt und den vm-deny-Traffic zu allen Diensten blockiert.

Bestimmten Traffic für `fr-foo-www` zulassen

Fügen Sie der vorhandenen Firewallrichtlinie fw-policy-foo-${REGION_1} eine neue Firewallrichtlinien-Regel hinzu.

Einen Quell-IP-Bereich zulassen, der vm-allow enthält und vm-deny-IP-Adressen ausschließt
Fügen Sie einen zusätzlichen Quellfilter INTRA_VPC hinzu, um den Netzwerktyp in einer Firewallrichtlinienregel zu verwenden, die auf den Load Balancer ausgerichtet ist.

Der Netzwerktyp der Quelle von INTRA_VPC und VPC_NETWORKS wird in Firewallrichtlinienregeln unterstützt, die auf Load Balancer ausgerichtet sind, wenn er in Kombination mit einem anderen Quellparameter verwendet wird. Die Auswertungslogik ist ein AND zwischen den beiden Quellparametern. Der Traffic muss die Kriterien für INTRA_VPC und --src-ip-ranges=${VM_ALLOW_IP}/32 erfüllen, damit er zugelassen wird.

Regel erstellen, um `vm-allow`-Targeting auf `fr-foo-www` zuzulassen

# 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 von Client `vm-allow`

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

Test von Client `vm-deny`

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

HINWEIS:Dies funktioniert, weil das implizite Standardverhalten von Firewallrichtlinienregeln für Load Balancer --action=allow ist. Dazu ist eine standardmäßige (Catchall) „deny“-Regel erforderlich.

Standard-Traffic für `fr-foo-www` ablehnen

Fügen Sie eine neue Firewallrichtlinien-Regel mit niedrigerer Priorität (höhere Prioritätsnummer) hinzu.

Den gesamten Traffic von beliebigen Quell-IP-Adressen ablehnen
Traffic von vm-allow nach fr-foo-www ist zulässig, bevor die Ablehnungsregel angewendet wird.

Regel zum Ablehnen von Traffic für `fr-foo-www` erstellen

# 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

Überlegungen zu Systemdiagnosen

Wie bei Firewallrichtlinienregeln, die auf VM-Instanzen ausgerichtet sind, blockiert die Standardregel zum Ablehnen von eingehendem Traffic (implizit) Traffic aus den Systemdiagnoseprüfungsbereichen, der für Load-Balancer-Back-Ends bestimmt ist. Daher wurde eine explizite Regel zum Zulassen von eingehendem Traffic konfiguriert, um die Bereiche der Systemdiagnoseprüfungen zuzulassen (siehe Regel 1002).

WICHTIG: Wenn Sie eine Catch-all-Regel (explizite Regel) zum Ablehnen von eingehendem Traffic für Load-Balancer-Ziele erstellen, muss eine weitere Regel mit höherer Priorität (niedrigere Prioritätsnummer) erstellt werden, um eingehenden Traffic aus dem Bereich der Systemdiagnose-Prüfungen zuzulassen. Diese Regel muss auf den oder die Load-Balancer ausgerichtet sein.

# 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 von Client `vm-deny`

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

Dies sollte jetzt fehlschlagen, da mit der Firewallregel 2999 der gesamte Traffic aus dem VPC-Netzwerk abgelehnt wird. Die Regel 2001 mit der höheren Priorität (niedrigere Prioritätsnummer) hat nur einen Quellbereich zugelassen, der vm-allow enthält.

Beenden Sie den Prozess curl durch Drücken von 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 kann weiterhin auf den API-Dienst zugreifen. Das hat funktioniert, weil die Firewallregel nur speziell auf die Weiterleitungsregel fr-foo-www angewendet wurde und nicht auf fr-foo-api.

Regeln so aktualisieren, dass sie auf alle Load-Balancer ausgerichtet sind

HINWEIS:Firewallrichtlinienregeln können auf alle Load-Balancer in einem VPC-Netzwerk angewendet werden, indem --target-forwarding-rules=FR_NAME weggelassen wird.

Ändern Sie die Firewallrichtlinienregeln so, dass sie jetzt für alle Ziele von Load Balancer-Weiterleitungsregeln im VPC-Netzwerk gelten.

Erstellen Sie eine neue allow-Eingangsregel 2003, die auf alle Weiterleitungsregeln ausgerichtet ist, um VM-Traffic (IP-Bereich vm-allow) zuzulassen.
Erstellen Sie eine neue allow-Regel für eingehenden Traffic 2004, die auf alle Weiterleitungsregeln ausgerichtet ist, um Traffic für Systemdiagnosen (Adressengruppe uhc-probes) zuzulassen.
Erstellen Sie eine neue deny-Regel für eingehenden Traffic 2998, die auf alle Weiterleitungsregeln ausgerichtet ist, um den gesamten anderen Traffic abzulehnen.

Firewallregeln so ändern, dass sie auf alle Load-Balancer ausgerichtet sind

# 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

Die vorherigen Firewallrichtlinienregeln, die auf explizite Load-Balancer-Weiterleitungsregeln ausgerichtet waren, können entfernt werden, da sie jetzt durch die Regeln, die auf alle Weiterleitungsregeln im VPC-Netzwerk ausgerichtet sind, überflüssig sind.

# 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 von Client `vm-deny`

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

Dies sollte jetzt fehlschlagen, da fr-foo-api auch von allen Firewallrichtlinienregeln mit --target-type=INTERNAL_MANAGED_LB betroffen ist.

Beenden Sie den Prozess curl durch Drücken von Ctrl+C.

Testen Sie, ob Sie eine Datei aus Google Cloud Storage über den Load Balancer herunterladen können.

# 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"

Beenden Sie den Prozess curl durch Drücken von Ctrl+C.

Test von 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"

Downloadinhalte überprüfen

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

Alle Load-Balancer-Dienste sind für vm-allow verfügbar und für vm-deny erfolgreich blockiert.

Damit ist der Testteil abgeschlossen. Als Nächstes sehen wir uns kurz die Protokollierung an.

8. Logging von Firewallregeln

Das Firewall-Logformat enthält Felder und Datensätze für Regeln, die auf Load-Balancer ausgerichtet sind (--target-type=INTERNAL_MANAGED_LB).

Die Logs enthalten ein zusätzliches Feld mit dem Label load_balancer_details, das weitere Informationen zum Load Balancer enthält, auf den die Firewallrichtlinien-Regel ausgerichtet war. Dies entspricht dem Feldformat InstanceDetails, wenn VM-Instanzen in Firewallrichtlinienregeln als Ziel angegeben werden.

load_balancer_details.forwarding_rule_name zeigt die Zielweiterleitungsregel der Firewallrichtlinienregel.
load_balancer_details.type gibt an, welche Variante des proxybasierten Load-Balancers verwendet wird.
load_balancer_details.url_map_name protokolliert die URL-Zuordnungsressource, die verwendet wird, wenn der Typ ein Application Load Balancer ist.

Logs ansehen

Fragen Sie die Firewall-Logs ab, um die Ergebnisse der Firewallrichtlinienregeln zu sehen.

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
  )"

Die Logausgabe zeigt die effektiven Regeln, die von der Richtlinie erzwungen werden:

Der gesamte vm-allow-Traffic zu allen Load-Balancern wird durch die Regel 2011 zugelassen.
Der gesamte Traffic, der für Load Balancer bestimmt ist, wird durch die Regel 2998 abgelehnt.

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

Logs können auch im Log-Explorer der Google Cloud Console aufgerufen werden. Rufen Sie console.cloud.google.com/logs/query auf und verwenden Sie das Standard-VPC-Firewalllog compute.googleapis.com/firewall.

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

Damit ist der Logging-Teil abgeschlossen. Jetzt geht es ans Aufräumen.

9. Bereinigen

# 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. Fazit

Glückwunsch! Sie haben Cloud NGFW Essentials für Load Balancer erfolgreich konfiguriert.

Wenn Sie Kommentare, Fragen oder Korrekturen haben, können Sie uns diese gern über dieses Feedbackformular mitteilen.

Vielen Dank!

Cloud NGFW Essentials für Load Balancer

1. Einführung

Lerninhalte

Voraussetzungen

2. Konzepte

Firewall-Feature-Ebenen

Filterung auf Datenebene

Load-Balancer-Ziele

Codelab-Netzwerk

3. Projekt einrichten

Auf Ihr Projekt zugreifen

Projekt-ID festlegen

API-Dienste aktivieren

Shell-Umgebungsvariablen festlegen

4. Netzwerkgrundlage

Netzwerkressourcen erstellen

Firewallkomponenten erstellen

Adressgruppe erstellen

Firewallrichtlinie erstellen

Netzwerkdienste konfigurieren

Cloud Router und NAT-Gateway erstellen

IP-Adressen reservieren

DNS-Einträge erstellen

5. Load-Balancer-Dienste

Backend-Ressourcen einrichten

Server für VM-Instanzgruppe erstellen

Storage-Bucket erstellen

Zertifikat erstellen

Load-Balancer-Komponenten erstellen

Skript zum Erstellen von Load Balancern bereitstellen

Erstellung des Load Balancers prüfen

6. Clientzugriff

VM-Clientressourcen erstellen

VM-Instanzen erstellen

Referenzdienst testen

Test von Client vm-allow

Test von Client vm-deny

7. Load Balancer-Firewall

Bestimmten Traffic für fr-foo-www zulassen

Regel erstellen, um vm-allow-Targeting auf fr-foo-www zuzulassen

Test von Client vm-allow

Test von Client vm-deny

Standard-Traffic für fr-foo-www ablehnen

Regel zum Ablehnen von Traffic für fr-foo-www erstellen

Überlegungen zu Systemdiagnosen

Test von Client vm-deny

Regeln so aktualisieren, dass sie auf alle Load-Balancer ausgerichtet sind

Firewallregeln so ändern, dass sie auf alle Load-Balancer ausgerichtet sind

Test von Client vm-deny

Test von Client vm-allow

8. Logging von Firewallregeln

Logs ansehen

9. Bereinigen

10. Fazit

Test von Client `vm-allow`

Test von Client `vm-deny`

Bestimmten Traffic für `fr-foo-www` zulassen

Regel erstellen, um `vm-allow`-Targeting auf `fr-foo-www` zuzulassen

Test von Client `vm-allow`

Test von Client `vm-deny`

Standard-Traffic für `fr-foo-www` ablehnen

Regel zum Ablehnen von Traffic für `fr-foo-www` erstellen

Test von Client `vm-deny`

Test von Client `vm-deny`

Test von Client `vm-allow`