Princípios básicos do NGFW do Cloud para balanceadores de carga

1. Introdução

Este codelab aborda os Essentials do Cloud Next Generation Firewall (NGFW) para balanceadores de carga de aplicativo (ALB) internos e balanceadores de carga de rede (NLB) de proxy usando políticas de firewall de rede regionais.

O Cloud NGFW é um serviço de firewall totalmente distribuído com recursos avançados de proteção contra ameaças e microssegmentação para proteger cargas de trabalho do Google Cloud. Ao ativar o Cloud NGFW no nível do balanceador de carga, você aplica regras de política de firewall consistentes a qualquer tráfego TCP que entra nos balanceadores de carga internos baseados em proxy. Ele simplifica o provisionamento de uma postura de segurança organizacional ao oferecer uma aplicação mais ampla de políticas para todos os serviços.

Este codelab aborda os seguintes produtos e recursos do Cloud NGFW e do balanceador de carga do Cloud:

Princípios básicos do Cloud NGFW
Políticas regionais de firewall da rede
Balanceador de carga de aplicativo interno regional
Grupo gerenciado de instâncias (MIG) de back-end e grupo de endpoints de rede (NEG) do Private Service Connect (PSC)

OBSERVAÇÃO:consulte a documentação do NFGW do Cloud para conferir os recursos e as limitações mais recentes das regras de política de firewall para destinos do balanceador de carga.

Conteúdo do laboratório

Como ativar regras básicas de política de firewall do Cloud NGFW direcionadas a balanceadores de carga
Proteger um serviço de balanceador de carga de consumidor interno com instâncias de VM e back-ends do PSC
Testar o acesso do cliente e verificar os registros do firewall

O que é necessário

um projeto do Google Cloud;
Familiaridade com os conceitos de rede do Google Cloud e o uso da CLI do Google Cloud
Permissões do IAM: roles/compute.instanceAdmin.v1, roles/compute.networkAdmin, roles/compute.securityAdmin e roles/storage.admin

2. Conceitos

Níveis de recursos do firewall

O Cloud NGFW tem três níveis de recursos: Essentials, Standard e Enterprise. Cada nível progressivo oferece mais recursos de filtragem e inspeção de tráfego de rede.

Um resumo dos recursos de filtragem do Cloud NGFW Essentials:

Nível	Capacidade	Camadas de rede	Exemplo de parâmetros de regra
Essentials	Filtragem de intervalo e endereço IP	IP	`--src-ip-ranges=1.1.1.0/24,2.2.2.2/32`
Essentials	Grupos de endereços	IP	`--src-address-groups=special-ranges`
Essentials	Filtragem de protocolo e porta	TCP	`--layer4-configs=tcp`
Essentials	Tags seguras	Metadados	`--src-secure-tags=tagValues/987654321098`
Essentials	Filtragem por tipo de rede	IP / metadados	`--src-network-type=INTRA_VPC`

As regras de encaminhamento do balanceador de carga definem explicitamente a porta TCP de destino. O parâmetro --layer4-configs= da regra de firewall só pode especificar tcp. O valor da porta é implícito na própria regra de encaminhamento.

Os grupos de endereços e os tipos de rede podem ser úteis para tornar as regras de política de firewall mais eficientes. Os tipos de rede VPC_NETWORKS e INTRA_VPC são compatíveis com regras de política de firewall para balanceadores de carga.

OBSERVAÇÃO:as regras de política de firewall para balanceadores de carga são compatíveis apenas com --direction=INGRESS. Essas regras foram criadas para controlar o acesso a serviços expostos pelo balanceador de carga.

Filtragem do plano de dados

Os recursos do Cloud NGFW Essentials abrangem regras básicas de firewall com estado da camada 3 (endereço IP) e da camada 4 (porta TCP). Todos esses recursos de regra de política de firewall são executados de maneira eficiente no plano de dados do balanceador de carga sem a necessidade de inspeção completa de pacotes.

As regras da política do Cloud NGFW Essentials destinadas a instâncias de VM são aplicadas na estrutura de rede VPC distribuída como parte da rede definida por software (Andromeda) principal do Google Cloud. A filtragem de pacotes e as regras de política de firewall são aplicadas no nível do hipervisor de cada instância de VM individual, antes que o pacote chegue à interface de rede da instância de VM.

As regras de política do Cloud NGFW Essentials que têm como destino balanceadores de carga são aplicadas usando as tecnologias subjacentes dos balanceadores de carga do Google Cloud, especificamente a infraestrutura de proxy de serviço do Envoy. Usando o mesmo modelo de recurso e estrutura de regra do Cloud NFGW, a filtragem de pacotes com estado é aplicada diretamente no plano de dados do balanceador de carga baseado em proxy.

Destinos do balanceador de carga

Há algumas diferenças importantes entre as políticas do Cloud NGFW que segmentam balanceadores de carga e as que segmentam instâncias de VM.

As regras de política de firewall podem ser aplicadas a um único balanceador de carga especificando --target-type=INTERNAL_MANAGED_LB junto com a referência específica à regra de encaminhamento do balanceador de carga --target-forwarding-rules=FR_NAME. Para segmentar todas as regras de encaminhamento do balanceador de carga na região da rede VPC (em que a região é definida pela política), omita a referência específica e use apenas a flag --target-type=INTERNAL_MANAGED_LB.

Se o parâmetro --target-type não estiver definido na configuração da regra, ela será aplicada automaticamente a todas as instâncias de VM e não aos balanceadores de carga.

Rede de codelab

Este codelab usa um único projeto com uma rede VPC e os seguintes recursos:

Duas sub-redes regionais
Uma política regional de firewall de rede
Três balanceadores de carga de aplicativo internos regionais
- Serviço HTTP www com back-end de grupo de instâncias de VM
- Serviço HTTP api com back-end de grupo de instâncias de VM
- Serviço HTTPS gcs com back-end NEG do PSC para APIs do Google
Duas instâncias de VM para testar várias políticas de permissão e negação

Fig. 1. Rede do codelab

As regras de política de firewall destinadas a balanceadores de carga são vinculadas aos recursos de regra de encaminhamento do balanceador de carga. Os balanceadores de carga são compostos por recursos definidos individualmente e configurados juntos para fornecer um serviço completo de balanceamento de carga. A definição da regra de encaminhamento faz referência direta a um recurso de proxy de destino específico definido para ela.

Fig. 1. Cloud NGFW para recursos de balanceador de carga

Os filtros do Cloud NGFW Essentials são programados no plano de dados do balanceador de carga e implementados na camada de serviço de proxy de destino definida, análoga a uma interface de instância de VM, usando os mesmos mecanismos de firewall distribuídos e consistentes para aplicar políticas.

3. Configurar o projeto

Acessar seu projeto

Este codelab usa um único projeto na nuvem do Google Cloud. As etapas de configuração usam a CLI gcloud cli e comandos do shell do Linux.

Comece acessando a linha de comando do projeto na nuvem do Google Cloud:

Cloud Shell em shell.cloud.google.com ou
Um terminal local com a CLI gcloud instalada

Definir o ID do projeto

gcloud config set project YOUR_PROJECT_ID_HERE

Ativar serviços de API

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

Definir variáveis de ambiente 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. Fundamentos de rede

Nesta seção, você vai implantar uma base de rede com:

Rede VPC global e sub-redes regionais
Política regional de firewall de rede para proteger a rede VPC
Cloud Router e Cloud NAT para servidores buscarem pacotes de software
Reservas de endereços IP e registros DNS para entrada do balanceador de carga

Criar recursos de rede

# 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

Criar componentes de firewall

A política de firewall de rede regional básica criada aqui será usada mais tarde ao adicionar destinos específicos do balanceador de carga. A política precisa estar na mesma região que o balanceador de carga.

Criar grupo de endereços

Comece criando um grupo de endereços para identificar os intervalos de IP de sondagem da verificação de integridade de origem que oferecem suporte à funcionalidade do balanceador de carga. Esses intervalos precisam ser permitidos para que os back-ends do balanceador de carga sejam considerados íntegros. Ela também será usada mais tarde com regras de política de firewall segmentando balanceadores de carga.

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

Criar política de 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}

configurar serviços de rede;

Criar um Cloud Router e um 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

Reservar endereços 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

Criar registros 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"

Concluímos a parte de configuração de rede. Agora vamos configurar os balanceadores de carga.

5. Serviços de balanceador de carga

Nesta seção, você vai implantar componentes do balanceador de carga (serviços de back-end, mapas de URL, proxies de destino e regras de encaminhamento) para três serviços:

Serviço www (ilb-foo-www) na porta 80
Serviço api (ilb-foo-api) na porta 8080
Serviço gcs (ilb-foo-gcs) na porta 443 com certificado TLS

Junto com os recursos de back-end de suporte:

Instâncias de VM que executam servidores HTTP em um grupo gerenciado de instâncias
Grupo de endpoints de rede (NEG) do Private Service Connect (PSC) para APIs do Google
Bucket do Google Cloud Storage (GCS)

Configurar recursos de back-end

Criar servidores de grupo de instâncias de VM

O balanceador de carga www usará os servidores de back-end do grupo de instâncias de VM que executam o servidor da Web Apache na porta 80.

O balanceador de carga api vai usar o mesmo grupo de instâncias de VM que está escutando na 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}

Criar bucket de armazenamento

O balanceador de carga gcs vai usar o back-end NEG do PSC para se conectar pelo front-end das APIs do Google ao bucket do Cloud Storage.

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

OBSERVAÇÃO:as variáveis de ambiente são perdidas quando a sessão do shell é fechada. Anote o nome do bucket, se necessário, para concluir em uma sessão 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

Criar certificado

O balanceador de carga gcs vai encerrar as solicitações HTTPS do cliente com um certificado autoassinado implantado no proxy HTTPS de destino.

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

Criar componentes do balanceador de carga

Use o script a seguir para automatizar a implantação dos componentes do balanceador de carga. Isso ajuda na velocidade e na precisão de todos os elementos de configuração envolvidos.

Implantar o script de criação do balanceador de carga

# 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

OBSERVAÇÃO:a execução desse script leva alguns minutos.

Verificar a criação do balanceador de carga

Verifique se as regras de encaminhamento e os serviços de back-end foram implantados.

# check forwarding rules
gcloud compute forwarding-rules list

# check backend services
gcloud compute backend-services list

Concluímos a parte da configuração do balanceador de carga. Agora vamos configurar as instâncias de VM do cliente.

6. Acesso de cliente

Criar recursos de cliente de VM

Nesta seção, você vai implantar clientes e verificar a conectividade de ponta a ponta.

Crie instâncias 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

Serviço de referência de teste

Teste do cliente `vm-allow`

OBSERVAÇÃO:as instâncias de VM vão ficar on-line e acessíveis por ssh usando o IAP logo após a emissão dos comandos instances create. Talvez seja necessário aguardar um momento se a solicitação falhar na primeira tentativa.

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

Teste o upload de um arquivo para o Google Cloud Storage pelo balanceador de carga.

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

A resposta da API Storage confirma que o caminho de rede está funcionando corretamente.

Teste do cliente `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"

OBSERVAÇÃO:esses testes também devem ser bem-sucedidos porque nenhuma regra de firewall ainda segmentou o balanceador de carga.

Concluímos todas as principais partes da configuração. Agora vamos criar regras de firewall do balanceador de carga.

7. Firewall do balanceador de carga

Nesta seção, você vai implantar regras de política de firewall direcionadas a balanceadores de carga. A sequência de configurações vai criar uma postura de segurança que permite o acesso ao vm-allow e bloqueia o tráfego do vm-deny para todos os serviços.

Permitir tráfego selecionado para `fr-foo-www`

Adicione uma nova regra de política de firewall à política de firewall atual fw-policy-foo-${REGION_1}

Permitir um intervalo de IP de origem que inclua vm-allow e exclua endereços IP vm-deny
Adicione outro filtro de origem INTRA_VPC para usar o tipo de rede em uma regra de política de firewall direcionada ao balanceador de carga.

O tipo de rede de origem de INTRA_VPC e VPC_NETWORKS é compatível com regras de políticas de firewall segmentando balanceadores de carga quando usado em combinação com outro parâmetro de origem. A lógica de avaliação é uma AND entre os dois parâmetros de origem. Nesse caso, o tráfego precisa atender aos critérios de INTRA_VPC e --src-ip-ranges=${VM_ALLOW_IP}/32 para ser permitido.

Criar regra para permitir a segmentação de `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

Teste do cliente `vm-allow`

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

Teste do cliente `vm-deny`

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

OBSERVAÇÃO:isso funciona porque o comportamento implícito padrão da regra da política de firewall para balanceadores de carga é --action=allow. Uma regra de negação padrão (catchall) é necessária para mudar isso.

Negar o tráfego padrão para `fr-foo-www`

Adicione uma nova regra de política de firewall de prioridade mais baixa (número de prioridade mais alta).

Negar todo o tráfego de qualquer endereço IP de origem
O tráfego de vm-allow para fr-foo-www será permitido antes de atingir a regra de negação.

Criar regra para negar a segmentação de tráfego `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

Considerações sobre verificações de integridade

Assim como nas regras de política de firewall destinadas a instâncias de VM, a regra de negação de entrada padrão (implícita) de captura de tudo bloqueia o tráfego originado dos intervalos de sondagem de verificação de integridade destinados aos back-ends do balanceador de carga. Portanto, uma regra de permissão explícita foi configurada para permitir intervalos de sondagem de verificação de integridade de entrada (consulte a regra 1002).

IMPORTANTE: da mesma forma, ao criar uma regra de negação de entrada catchall (explícita) para destinos do balanceador de carga, outra regra de prioridade mais alta (número de prioridade mais baixa) precisa ser criada para permitir a entrada do intervalo de sondagem da verificação de integridade. Essa regra precisa segmentar os balanceadores de carga.

# 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

Teste do cliente `vm-deny`

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

Isso vai falhar porque a regra de firewall 2999 nega todo o tráfego originado da rede VPC. A regra de prioridade mais alta (número de prioridade mais baixa) 2001 permitia apenas um intervalo de origem que incluísse vm-allow.

Para interromper o processo curl, pressione Ctrl+C.

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

O vm-deny ainda pode acessar o serviço de API. Isso deu certo porque a regra de firewall foi aplicada especificamente à regra de encaminhamento fr-foo-www e não segmentou fr-foo-api.

Atualizar regras para segmentar todos os balanceadores de carga

OBSERVAÇÃO:as regras da política de firewall podem ser aplicadas a todos os balanceadores de carga em uma rede VPC omitindo --target-forwarding-rules=FR_NAME.

Mude as regras da política de firewall para que elas sejam aplicadas a todos os destinos de regras de encaminhamento do balanceador de carga na rede VPC.

Crie uma regra de entrada allow 2003 que tenha como destino todas as regras de encaminhamento para permitir o tráfego de VM (intervalo de IP vm-allow).
Crie uma regra de permissão de entrada 2004 que tenha como destino todas as regras de encaminhamento para permitir o tráfego de verificações de integridade (grupo de endereços uhc-probes).
Crie uma nova regra de negação de entrada 2998 que tenha como destino todas as regras de encaminhamento como uma negação abrangente para todo o outro tráfego.

Modificar regras de firewall para segmentar todos os balanceadores de carga

# 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

As regras anteriores da política de firewall que segmentam regras de encaminhamento de balanceador de carga explícitas podem ser removidas, já que agora são redundantes com as regras que segmentam todas as regras de encaminhamento na rede 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}

Teste do cliente `vm-deny`

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

Isso vai falhar porque fr-foo-api também é segmentado por todas as regras de política de firewall com --target-type=INTERNAL_MANAGED_LB.

Para interromper o processo curl, pressione Ctrl+C.

Teste o download de um arquivo do Google Cloud Storage pelo balanceador de carga.

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

Para interromper o processo curl, pressione Ctrl+C.

Teste do cliente `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"

Verificar o conteúdo do download

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

Todos os serviços de balanceadores de carga estão disponíveis para vm-allow e bloqueados para vm-deny.

Isso conclui a parte de testes. Em seguida, vamos dar uma olhada rápida na geração de registros.

8. Geração de registros de regras de Firewall

O formato de registro de firewall tem campos e registros para regras que segmentam balanceadores de carga (--target-type=INTERNAL_MANAGED_LB).

Os registros vão conter um campo adicional chamado load_balancer_details com mais informações sobre o balanceador de carga em que a regra da política de firewall foi direcionada. Isso é análogo ao formato do campo InstanceDetails quando as instâncias de VM são segmentadas em regras de política de firewall.

load_balancer_details.forwarding_rule_name mostra a regra de encaminhamento de destino da regra de política de firewall.
load_balancer_details.type indica qual tipo de balanceador de carga baseado em proxy é o destino.
load_balancer_details.url_map_name registra o recurso de mapa de URL usado quando o tipo é um balanceador de carga de aplicativo.

Ver registros

Consulte os registros de firewall para ver os resultados das regras de política de 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
  )"

A saída do registro mostra as regras efetivas aplicadas pela política:

Todo o tráfego vm-allow para todos os balanceadores de carga é permitido pela regra 2011.
Todo o tráfego destinado aos balanceadores de carga é negado pela regra 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

Os registros também podem ser visualizados no console do Google Cloud usando a Análise de registros. Navegue até console.cloud.google.com/logs/query e use o registro padrão do firewall da VPC compute.googleapis.com/firewall.

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

Isso conclui a parte de geração de registros... vamos liberar espaço!

9. Limpeza

# 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. Conclusão

Parabéns! Você configurou com sucesso o Cloud NGFW Essentials para balanceadores de carga.

Envie comentários, dúvidas ou correções usando este formulário de feedback.

Agradecemos pela atenção!

Princípios básicos do NGFW do Cloud para balanceadores de carga

1. Introdução

Conteúdo do laboratório

O que é necessário

2. Conceitos

Níveis de recursos do firewall

Filtragem do plano de dados

Destinos do balanceador de carga

Rede de codelab

3. Configurar o projeto

Acessar seu projeto

Definir o ID do projeto

Ativar serviços de API

Definir variáveis de ambiente shell

4. Fundamentos de rede

Criar recursos de rede

Criar componentes de firewall

Criar grupo de endereços

Criar política de firewall

configurar serviços de rede;

Criar um Cloud Router e um gateway NAT

Reservar endereços IP

Criar registros DNS

5. Serviços de balanceador de carga

Configurar recursos de back-end

Criar servidores de grupo de instâncias de VM

Criar bucket de armazenamento

Criar certificado

Criar componentes do balanceador de carga

Implantar o script de criação do balanceador de carga

Verificar a criação do balanceador de carga

6. Acesso de cliente

Criar recursos de cliente de VM

Crie instâncias de VM

Serviço de referência de teste

Teste do cliente vm-allow

Teste do cliente vm-deny

7. Firewall do balanceador de carga

Permitir tráfego selecionado para fr-foo-www

Criar regra para permitir a segmentação de vm-allow fr-foo-www

Teste do cliente vm-allow

Teste do cliente vm-deny

Negar o tráfego padrão para fr-foo-www

Criar regra para negar a segmentação de tráfego fr-foo-www

Considerações sobre verificações de integridade

Teste do cliente vm-deny

Atualizar regras para segmentar todos os balanceadores de carga

Modificar regras de firewall para segmentar todos os balanceadores de carga

Teste do cliente vm-deny

Teste do cliente vm-allow

8. Geração de registros de regras de Firewall

Ver registros

9. Limpeza

10. Conclusão

Teste do cliente `vm-allow`

Teste do cliente `vm-deny`

Permitir tráfego selecionado para `fr-foo-www`

Criar regra para permitir a segmentação de `vm-allow` `fr-foo-www`

Teste do cliente `vm-allow`

Teste do cliente `vm-deny`

Negar o tráfego padrão para `fr-foo-www`

Criar regra para negar a segmentação de tráfego `fr-foo-www`

Teste do cliente `vm-deny`

Teste do cliente `vm-deny`

Teste do cliente `vm-allow`