Principes de base de Cloud NGFW pour les équilibreurs de charge

1. Introduction

Cet atelier de programmation explore les principes de base de Cloud Next Generation Firewall (NGFW) pour les équilibreurs de charge d'application (ALB) et les équilibreurs de charge réseau (NLB) proxy internes à l'aide des stratégies de pare-feu réseau régionales.

Cloud NGFW est un service de pare-feu entièrement distribué offrant des fonctionnalités de protection avancées contre les menaces et de microsegmentation pour protéger les charges de travail Google Cloud. L'activation de Cloud NGFW au niveau de l'équilibreur de charge applique des règles de stratégie de pare-feu cohérentes à tout trafic TCP entrant dans les équilibreurs de charge internes basés sur un proxy. Il simplifie le provisionnement d'une posture de sécurité organisationnelle en offrant une application plus large des règles pour tous les services.

Cet atelier de programmation couvre les produits et fonctionnalités Cloud NGFW et d'équilibreur de charge Cloud suivants :

Principes de base de Cloud NGFW
Règles de pare-feu réseau régionales
Équilibreur de charge d'application interne régional
Groupe d'instances géré (MIG) de backend et groupe de points de terminaison du réseau (NEG) Private Service Connect (PSC)

REMARQUE : Consultez la documentation Cloud NGFW pour connaître les dernières fonctionnalités et limites des règles de stratégie de pare-feu pour les cibles d'équilibreur de charge.

Objectifs

Activer les règles de stratégie de pare-feu Cloud NGFW de base ciblant les équilibreurs de charge
Protéger un service d'équilibreur de charge client interne avec des backends d'instances de VM et de PSC
Tester l'accès client et vérifier les journaux de pare-feu

Ce dont vous avez besoin

Un projet Google Cloud
Bonne connaissance des concepts de mise en réseau Google Cloud et de l'utilisation de Google Cloud CLI
Autorisations IAM : roles/compute.instanceAdmin.v1, roles/compute.networkAdmin, roles/compute.securityAdmin et roles/storage.admin

2. Concepts

Niveaux de fonctionnalités du pare-feu

Cloud NGFW propose trois niveaux de fonctionnalités : Essentials, Standard et Enterprise. Chaque niveau progressif offre des niveaux supplémentaires de filtrage et d'inspection du trafic réseau.

Voici un récapitulatif des capacités de filtrage de Principes de base de Cloud NGFW :

Niveau	Capacité	Couches réseau	Exemples de paramètres de règles
Essentials	Filtrage des adresses IP et des plages d'adresses IP	IP	`--src-ip-ranges=1.1.1.0/24,2.2.2.2/32`
Essentials	Groupes d'adresses	IP	`--src-address-groups=special-ranges`
Essentials	Filtrage des protocoles et des ports	TCP	`--layer4-configs=tcp`
Essentials	Tags sécurisés	Métadonnées	`--src-secure-tags=tagValues/987654321098`
Essentials	Filtrage par type de réseau	IP / métadonnées	`--src-network-type=INTRA_VPC`

Les règles de transfert de l'équilibreur de charge définissent explicitement le port TCP de destination. Le paramètre --layer4-configs= de la règle de pare-feu ne peut spécifier que tcp. La valeur du port est implicite dans la règle de transfert elle-même.

Les groupes d'adresses et les types de réseau peuvent être utiles pour rendre les règles de stratégie de pare-feu plus efficaces. Les types de réseau VPC_NETWORKS et INTRA_VPC sont compatibles avec les règles de stratégie de pare-feu pour les équilibreurs de charge.

REMARQUE : Les règles de stratégie de pare-feu pour les équilibreurs de charge ne sont compatibles qu'avec --direction=INGRESS. Ces règles sont conçues pour contrôler l'accès aux services exposés par l'équilibreur de charge.

Filtrage du plan de données

Les fonctionnalités Essentials de Cloud NGFW couvrent les règles de pare-feu avec état de base de couche 3 (adresse IP) et de couche 4 (port TCP). Ces fonctionnalités de règles de stratégie de pare-feu sont toutes exécutées efficacement dans le plan de données de l'équilibreur de charge sans avoir besoin d'une inspection complète des paquets.

Les règles de stratégie Essentials de Cloud NGFW ciblant les instances de VM sont appliquées dans le tissu de réseau VPC distribué dans le cadre du réseau défini par logiciel (Andromeda) de base de Google Cloud. Les règles de filtrage des paquets et de stratégie de pare-feu sont appliquées au niveau de l'hyperviseur de chaque instance de VM individuelle, avant que le paquet n'atteigne l'interface réseau de l'instance de VM.

Les règles de stratégie Essentials de Cloud NGFW ciblant les équilibreurs de charge sont appliquées à l'aide des technologies sous-jacentes des équilibreurs de charge Google Cloud, en particulier l'infrastructure de proxy de service Envoy. En utilisant le même modèle de ressources et la même structure de règles que Cloud NFGW, le filtrage de paquets avec état est appliqué directement dans le plan de données de l'équilibreur de charge basé sur un proxy.

Cibles de l'équilibreur de charge

Il existe quelques différences clés entre les stratégies Cloud NGFW ciblant les équilibreurs de charge et celles ciblant les instances de VM.

Les règles de stratégie de pare-feu peuvent être appliquées à un seul équilibreur de charge en spécifiant --target-type=INTERNAL_MANAGED_LB avec la référence spécifique à la règle de transfert de l'équilibreur de charge --target-forwarding-rules=FR_NAME. Pour cibler toutes les règles de transfert d'équilibreur de charge dans la région du réseau VPC (où la région est définie par la stratégie), la référence spécifique doit être omise et seul l'indicateur --target-type=INTERNAL_MANAGED_LB est nécessaire.

Si le paramètre --target-type n'est pas défini dans la configuration de la règle, la règle s'applique par défaut à toutes les instances de VM et non aux équilibreurs de charge.

Réseau d'ateliers de programmation

Cet atelier de programmation utilise un seul projet avec un réseau VPC et les ressources suivantes :

Deux sous-réseaux régionaux
Une stratégie de pare-feu réseau régionale
Trois équilibreurs de charge d'application internes régionaux
- Service HTTP www avec backend de groupe d'instances de VM
- Service HTTP api avec backend de groupe d'instances de VM
- gcs Service HTTPS avec backend NEG PSC pour les API Google
Deux instances de VM pour tester différentes stratégies d'autorisation et de refus

Fig. 1. Réseau de l'atelier de programmation

Les règles de stratégie de pare-feu ciblant les équilibreurs de charge sont associées aux ressources de règles de transfert des équilibreurs de charge. Les équilibreurs de charge eux-mêmes sont constitués de ressources définies individuellement et configurées ensemble pour fournir un service d'équilibrage de charge complet. La définition de la règle de transfert fait directement référence à une ressource de proxy cible spécifique définie pour elle.

Fig. 1. Cloud NGFW pour les ressources d'équilibreur de charge

Les filtres Essentials de Cloud NGFW sont programmés dans le plan de données de l'équilibreur de charge et implémentés au niveau du service de proxy cible défini (analogue à une interface d'instance de VM) à l'aide des mêmes mécanismes de pare-feu distribués et cohérents pour appliquer les règles.

3. Configuration du projet

Accéder à votre projet

Cet atelier de programmation utilise un seul projet Google Cloud. Les étapes de configuration utilisent la CLI gcloud cli et les commandes du shell Linux.

Commencez par accéder à la ligne de commande de votre projet Google Cloud :

Cloud Shell à l'adresse shell.cloud.google.com
Un terminal local avec gcloud CLI installé

Définir votre ID de projet

gcloud config set project YOUR_PROJECT_ID_HERE

Activer les services d'API

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

Définir des variables d'environnement de 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. Principes de base du réseau

Dans cette section, vous allez déployer une base de réseau avec les éléments suivants :

Réseau VPC mondial et sous-réseaux régionaux
Stratégie de pare-feu de réseau régional pour sécuriser le réseau VPC
Routeur Cloud Router et Cloud NAT pour que les serveurs récupèrent les packages logiciels
Réservations d'adresses IP et enregistrements DNS pour l'entrée de l'équilibreur de charge

Créer des ressources réseau

# 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

Créer des composants de pare-feu

La stratégie de pare-feu réseau régionale de base créée ici sera utilisée ultérieurement lors de l'ajout de cibles spécifiques à l'équilibreur de charge. La règle doit se trouver dans la même région que l'équilibreur de charge.

Créer un groupe d'adresses

Commencez par créer un groupe d'adresses pour identifier les plages d'adresses IP de vérification d'état sources qui prennent en charge la fonctionnalité d'équilibreur de charge. Ces plages doivent être autorisées pour que les backends de l'équilibreur de charge soient considérés comme opérationnels. Il sera également utilisé ultérieurement avec les règles de stratégie de pare-feu ciblant les équilibreurs de charge.

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

Créer une stratégie de pare-feu

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

Configurer des services réseau

Créer un routeur Cloud Router et une passerelle 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

Réserver des adresses 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

Créer des enregistrements 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"

La configuration du réseau est terminée. Passons maintenant à la configuration des équilibreurs de charge.

5. Services d'équilibrage de charge

Dans cette section, vous allez déployer des composants d'équilibreur de charge (services de backend, mappages d'URL, proxys cibles et règles de transfert) pour trois services :

Service www (ilb-foo-www) sur le port 80
Service api (ilb-foo-api) sur le port 8080
Service gcs (ilb-foo-gcs) sur le port 443 avec certificat TLS

ainsi que les ressources de backend associées :

Instances de VM exécutant des serveurs HTTP dans un groupe d'instances géré
Groupe de points de terminaison du réseau (NEG) Private Service Connect (PSC) vers les API Google
Bucket Google Cloud Storage (GCS)

Configurer les ressources de backend

Créer des serveurs de groupe d'instances de VM

L'équilibreur de charge www utilisera les serveurs de backend du groupe d'instances de VM exécutant le serveur Web Apache écoutant le port 80.

L'équilibreur de charge api utilisera le même groupe d'instances de VM écoutant le port 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}

Créer un bucket de stockage

L'équilibreur de charge gcs utilisera le backend PSC NEG pour se connecter au bucket Cloud Storage via le frontend des API Google.

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

REMARQUE : Les variables d'environnement sont perdues une fois la session shell fermée. Notez le nom du bucket si vous en avez besoin pour le compléter lors d'une prochaine session.

# 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

Créer un certificat

L'équilibreur de charge gcs mettra fin aux requêtes HTTPS des clients avec un certificat auto-signé déployé sur le proxy HTTPS cible.

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

Créer des composants pour l'équilibreur de charge

Utilisez le script suivant pour automatiser le déploiement des composants de l'équilibreur de charge. Cela vous aidera à gagner en rapidité et en précision pour tous les éléments de configuration concernés.

Déployer le script de création de l'équilibreur de charge

# 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

REMARQUE : L'exécution de ce script prend plusieurs minutes.

Vérifier la création de l'équilibreur de charge

Vérifiez que les règles de transfert et les services de backend ont été déployés.

# check forwarding rules
gcloud compute forwarding-rules list

# check backend services
gcloud compute backend-services list

La configuration de l'équilibreur de charge est terminée. Passons maintenant à la configuration des instances de VM clientes.

6. Accès des clients

Créer des ressources de VM cliente

Dans cette section, vous allez déployer des clients et vérifier la connectivité de bout en bout.

Créer des instances de 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

Tester le service de référence

Tester à partir du client `vm-allow`

REMARQUE : Les instances de VM seront mises en ligne et accessibles via ssh à l'aide d'IAP peu de temps après l'exécution des commandes instances create. Si la demande échoue la première fois, vous devrez peut-être patienter quelques instants.

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

Testez l'importation d'un fichier dans Google Cloud Storage via l'équilibreur de charge.

# 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 réponse de l'API Cloud Storage confirme que le chemin réseau fonctionne correctement.

Tester à partir du 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"

REMARQUE : Ces tests devraient également réussir, car aucune règle de pare-feu n'a encore ciblé l'équilibreur de charge.

Nous avons terminé la configuration principale. Passons maintenant à la création de règles de pare-feu pour l'équilibreur de charge.

7. Pare-feu de l'équilibreur de charge

Dans cette section, vous allez déployer des règles de stratégie de pare-feu ciblant les équilibreurs de charge. La séquence de configurations permettra d'établir une stratégie de sécurité qui autorise l'accès vm-allow et bloque le trafic vm-deny vers tous les services.

Autoriser le trafic sélectionné vers `fr-foo-www`

Ajoutez une règle de stratégie de pare-feu à la stratégie de pare-feu existante fw-policy-foo-${REGION_1}

Autoriser une plage d'adresses IP sources incluant les adresses IP vm-allow et excluant les adresses IP vm-deny
Ajoutez un filtre de source supplémentaire INTRA_VPC pour utiliser type de réseau dans une règle de stratégie de pare-feu ciblant l'équilibreur de charge.

Les types de réseau sources INTRA_VPC et VPC_NETWORKS sont acceptés dans les règles de stratégies de pare-feu ciblant les équilibreurs de charge lorsqu'ils sont utilisés en combinaison avec un autre paramètre source. La logique d'évaluation est un AND entre les deux paramètres sources. Ici, le trafic doit répondre aux critères de INTRA_VPC et --src-ip-ranges=${VM_ALLOW_IP}/32 pour être autorisé.

Créer une règle pour autoriser le ciblage `vm-allow` `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

Tester à partir du client `vm-allow`

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

Tester à partir du client `vm-deny`

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

REMARQUE : Cette opération réussit, car le comportement de la règle de stratégie de pare-feu par défaut implicite pour les équilibreurs de charge est --action=allow. Pour ce faire, vous devez créer une règle de refus par défaut (générique).

Refuser le trafic par défaut vers `fr-foo-www`

Ajoutez une règle de stratégie de pare-feu avec une priorité plus faible (nombre de priorité plus élevé).

Refuser tout trafic provenant de n'importe quelle adresse IP source
Le trafic de vm-allow vers fr-foo-www sera autorisé avant d'être soumis à la règle de refus.

Créer une règle pour refuser le trafic ciblant `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

Points à prendre en compte pour les vérifications d'état

Comme pour les règles de stratégie de pare-feu ciblant les instances de VM, la règle d'entrée interdite par défaut (implicite) bloque le trafic provenant des plages de vérification d'état et destiné aux backends de l'équilibreur de charge. Une règle d'autorisation explicite a donc été configurée pour autoriser les plages de vérification d'état des entrées (voir la règle 1002).

IMPORTANT : De même, lorsque vous créez une règle de refus (explicite) pour le trafic entrant pour les cibles d'équilibreur de charge, vous devez créer une autre règle de priorité plus élevée (nombre de priorité plus faible) pour autoriser le trafic entrant à partir de la plage de vérification d'état. Cette règle doit cibler le ou les équilibreurs de charge.

# 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

Tester à partir du client `vm-deny`

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

Cette opération devrait maintenant échouer, car la règle de pare-feu 2999 refuse tout le trafic provenant du réseau VPC. La règle 2001 de priorité plus élevée (nombre de priorité plus faible) n'autorisait qu'une plage source incluant vm-allow.

Arrêtez le processus curl en appuyant sur 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 peut toujours accéder au service d'API. Cette opération a réussi, car la règle de pare-feu n'a été appliquée spécifiquement qu'à la règle de transfert fr-foo-www et ne ciblait pas fr-foo-api.

Mettre à jour les règles pour cibler tous les équilibreurs de charge

REMARQUE : Les règles de stratégie de pare-feu peuvent être appliquées à tous les équilibreurs de charge d'un réseau VPC en omettant --target-forwarding-rules=FR_NAME.

Modifiez les règles de la stratégie de pare-feu pour qu'elles s'appliquent désormais à toutes les cibles de règles de transfert de l'équilibreur de charge dans le réseau VPC.

Créez une règle d'entrée allow (autoriser) 2003 ciblant toutes les règles de transfert pour autoriser le trafic des VM (plage d'adresses IP vm-allow).
Créez une règle d'autorisation d'entrée 2004 ciblant toutes les règles de transfert pour autoriser le trafic de vérification de l'état (groupe d'adresses uhc-probes).
Créez une règle deny (refuser) entrante 2998 ciblant toutes les règles de transfert comme règle de refus globale pour tout autre trafic.

Modifier les règles de pare-feu pour cibler tous les équilibreurs de charge

# 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

Les règles de stratégie de pare-feu précédentes ciblant les règles de transfert d'équilibreur de charge explicites peuvent être supprimées, car elles sont désormais redondantes avec les règles ciblant toutes les règles de transfert du réseau 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}

Tester à partir du client `vm-deny`

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

Cette opération devrait maintenant échouer, car fr-foo-api est également ciblé par toutes les règles de stratégie de pare-feu avec --target-type=INTERNAL_MANAGED_LB.

Arrêtez le processus curl en appuyant sur Ctrl+C.

Testez le téléchargement d'un fichier depuis Google Cloud Storage via l'équilibreur de charge.

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

Arrêtez le processus curl en appuyant sur Ctrl+C.

Tester à partir du 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"

Vérifier le contenu téléchargé

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

Tous les services d'équilibrage de charge sont disponibles pour vm-allow et bloqués pour vm-deny.

La partie consacrée aux tests est terminée. Passons maintenant à la journalisation.

8. Journalisation des règles de pare-feu

Le format des journaux de pare-feu comporte des champs et des enregistrements pour les règles ciblant les équilibreurs de charge (--target-type=INTERNAL_MANAGED_LB).

Les journaux contiendront un champ supplémentaire intitulé load_balancer_details, qui fournira plus d'informations sur l'équilibreur de charge auquel la règle de stratégie de pare-feu était destinée. Cela est analogue au format du champ InstanceDetails lorsque des instances de VM sont ciblées dans les règles de stratégie de pare-feu.

load_balancer_details.forwarding_rule_name indique la règle de transfert cible de la règle de stratégie de pare-feu.
load_balancer_details.type indique la variante d'équilibreur de charge basé sur un proxy ciblée.
load_balancer_details.url_map_name consigne la ressource de mappage d'URL utilisée lorsque le type est un équilibreur de charge d'application.

Afficher les journaux

Interrogez les journaux du pare-feu pour afficher les résultats des règles de la stratégie de pare-feu.

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

Le résultat du journal affiche les règles effectives appliquées par la règle :

La règle 2011 autorise tout le trafic vm-allow vers tous les équilibreurs de charge.
Tout le trafic destiné aux équilibreurs de charge est refusé par la règle 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

Vous pouvez également afficher les journaux dans la console Google Cloud à l'aide de l'explorateur de journaux. Accédez à console.cloud.google.com/logs/query et utilisez le journal de pare-feu VPC standard compute.googleapis.com/firewall.

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

La partie sur la journalisation est terminée. Passons au nettoyage !

9. Nettoyage

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

Félicitations ! Vous avez configuré avec succès Cloud NGFW Essentials pour les équilibreurs de charge.

N'hésitez pas à nous faire part de vos commentaires, questions ou corrections en utilisant ce formulaire de commentaires.

Merci !

Principes de base de Cloud NGFW pour les équilibreurs de charge

1. Introduction

Objectifs

Ce dont vous avez besoin

2. Concepts

Niveaux de fonctionnalités du pare-feu

Filtrage du plan de données

Cibles de l'équilibreur de charge

Réseau d'ateliers de programmation

3. Configuration du projet

Accéder à votre projet

Définir votre ID de projet

Activer les services d'API

Définir des variables d'environnement de shell

4. Principes de base du réseau

Créer des ressources réseau

Créer des composants de pare-feu

Créer un groupe d'adresses

Créer une stratégie de pare-feu

Configurer des services réseau

Créer un routeur Cloud Router et une passerelle NAT

Réserver des adresses IP

Créer des enregistrements DNS

5. Services d'équilibrage de charge

Configurer les ressources de backend

Créer des serveurs de groupe d'instances de VM

Créer un bucket de stockage

Créer un certificat

Créer des composants pour l'équilibreur de charge

Déployer le script de création de l'équilibreur de charge

Vérifier la création de l'équilibreur de charge

6. Accès des clients

Créer des ressources de VM cliente

Créer des instances de VM

Tester le service de référence

Tester à partir du client vm-allow

Tester à partir du client vm-deny

7. Pare-feu de l'équilibreur de charge

Autoriser le trafic sélectionné vers fr-foo-www

Créer une règle pour autoriser le ciblage vm-allow fr-foo-www

Tester à partir du client vm-allow

Tester à partir du client vm-deny

Refuser le trafic par défaut vers fr-foo-www

Créer une règle pour refuser le trafic ciblant fr-foo-www

Points à prendre en compte pour les vérifications d'état

Tester à partir du client vm-deny

Mettre à jour les règles pour cibler tous les équilibreurs de charge

Modifier les règles de pare-feu pour cibler tous les équilibreurs de charge

Tester à partir du client vm-deny

Tester à partir du client vm-allow

8. Journalisation des règles de pare-feu

Afficher les journaux

9. Nettoyage

10. Conclusion

Tester à partir du client `vm-allow`

Tester à partir du client `vm-deny`

Autoriser le trafic sélectionné vers `fr-foo-www`

Créer une règle pour autoriser le ciblage `vm-allow` `fr-foo-www`

Tester à partir du client `vm-allow`

Tester à partir du client `vm-deny`

Refuser le trafic par défaut vers `fr-foo-www`

Créer une règle pour refuser le trafic ciblant `fr-foo-www`

Tester à partir du client `vm-deny`

Tester à partir du client `vm-deny`

Tester à partir du client `vm-allow`