ข้อควรทราบเกี่ยวกับ Cloud NGFW สำหรับตัวจัดสรรภาระงาน

1. บทนำ

Codelab นี้จะสำรวจ Cloud Next Generation Firewall (NGFW) Essentials สำหรับตัวจัดสรรภาระงานแอปพลิเคชัน (ALB) ภายในและตัวจัดสรรภาระงานเครือข่าย (NLB) พร็อกซีโดยใช้นโยบายไฟร์วอลล์เครือข่ายระดับภูมิภาค

Cloud NGFW เป็นบริการไฟร์วอลล์แบบกระจายอย่างเต็มรูปแบบที่มีการป้องกันภัยคุกคามขั้นสูงและความสามารถในการแบ่งกลุ่มย่อยเพื่อปกป้องเวิร์กโหลดของ Google Cloud การเปิดใช้ Cloud NGFW ที่ระดับตัวจัดสรรภาระงานจะใช้กฎนโยบายไฟร์วอลล์ที่สอดคล้องกันกับการรับส่งข้อมูล TCP ใดก็ตามที่เข้าสู่ตัวจัดสรรภาระงานภายในที่ใช้พร็อกซี ซึ่งช่วยลดความซับซ้อนในการจัดสรรท่าทางด้านความปลอดภัยขององค์กรด้วยการบังคับใช้นโยบายในวงกว้างสำหรับบริการทั้งหมด

ผลิตภัณฑ์และฟีเจอร์ Cloud NGFW และ Cloud Load Balancer ต่อไปนี้จะครอบคลุมใน Codelab นี้

Essentials ของ Cloud NGFW
นโยบายไฟร์วอลล์เครือข่ายระดับภูมิภาค
ตัวจัดสรรภาระงานแอปพลิเคชันภายในระดับภูมิภาค
กลุ่มอินสแตนซ์ที่มีการจัดการ (MIG) แบ็กเอนด์และกลุ่มปลายทางเครือข่าย (NEG) Private Service Connect (PSC)

หมายเหตุ: โปรดดูเอกสารประกอบของ Cloud NFGW เพื่อดูฟีเจอร์ล่าสุดที่รองรับและข้อจำกัดของกฎนโยบายไฟร์วอลล์สำหรับเป้าหมายของตัวจัดสรรภาระงาน

สิ่งที่คุณจะได้เรียนรู้

การเปิดใช้กฎนโยบายไฟร์วอลล์ Cloud NGFW พื้นฐานที่กำหนดเป้าหมายไปยังตัวจัดสรรภาระงาน
การปกป้องบริการตัวจัดสรรภาระงานภายในของผู้ใช้ด้วยอินสแตนซ์ VM และแบ็กเอนด์ PSC
การทดสอบการเข้าถึงของไคลเอ็นต์และการยืนยันบันทึกไฟร์วอลล์

สิ่งที่ต้องมี

โปรเจ็กต์ Google Cloud
มีความคุ้นเคยกับแนวคิดด้านเครือข่ายของ Google Cloud และการใช้ Google Cloud CLI
สิทธิ์ IAM: roles/compute.instanceAdmin.v1, roles/compute.networkAdmin, roles/compute.securityAdmin และ roles/storage.admin

2. แนวคิด

ระดับฟีเจอร์ไฟร์วอลล์

Cloud NGFW มีระดับฟีเจอร์ 3 ระดับ ได้แก่ Essentials, Standard และ Enterprise แต่ละระดับที่เพิ่มขึ้นจะมีความสามารถในการกรองและตรวจสอบการจราจรของข้อมูลในเครือข่ายเพิ่มเติม

สรุปความสามารถในการกรองของ Cloud NGFW Essentials

ระดับ	ความสามารถ	เลเยอร์เครือข่าย	ตัวอย่างพารามิเตอร์ของกฎ
Essentials	การกรองที่อยู่และช่วง IP	IP	`--src-ip-ranges=1.1.1.0/24,2.2.2.2/32`
Essentials	กลุ่มแอดเดรส	IP	`--src-address-groups=special-ranges`
Essentials	การกรองโปรโตคอลและพอร์ต	TCP	`--layer4-configs=tcp`
Essentials	แท็กที่ปลอดภัย	ข้อมูลเมตา	`--src-secure-tags=tagValues/987654321098`
Essentials	การกรองประเภทเครือข่าย	IP / ข้อมูลเมตา	`--src-network-type=INTRA_VPC`

กฎการส่งต่อของตัวจัดสรรภาระงานจะกำหนดพอร์ต TCP ปลายทางอย่างชัดเจน พารามิเตอร์กฎไฟร์วอลล์ --layer4-configs= ระบุได้เฉพาะ tcp เท่านั้น ค่าพอร์ตจะแสดงโดยกฎการส่งต่อเอง

กลุ่มที่อยู่และประเภทเครือข่ายอาจมีประโยชน์ในการทำให้กฎนโยบายไฟร์วอลล์มีประสิทธิภาพมากขึ้น ระบบรองรับประเภทเครือข่าย VPC_NETWORKS และ INTRA_VPC ที่มีกฎนโยบายไฟร์วอลล์สำหรับตัวจัดสรรภาระงาน

หมายเหตุ: กฎนโยบายไฟร์วอลล์สำหรับตัวจัดสรรภาระงานรองรับเฉพาะ --direction=INGRESS กฎเหล่านี้ออกแบบมาเพื่อควบคุมการเข้าถึงบริการที่ตัวจัดสรรภาระงานแสดง

การกรอง Data Plane

ฟีเจอร์ Essentials ของ Cloud NFGW ครอบคลุมกฎไฟร์วอลล์แบบเก็บสถานะพื้นฐานของเลเยอร์ 3 (ที่อยู่ IP) และเลเยอร์ 4 (พอร์ต TCP) ฟีเจอร์กฎนโยบายไฟร์วอลล์เหล่านี้ทำงานได้อย่างมีประสิทธิภาพใน Data Plane ของตัวจัดสรรภาระงานโดยไม่ต้องตรวจสอบแพ็กเก็ตทั้งหมด

กฎนโยบาย Essentials ของ Cloud NGFW ที่กำหนดเป้าหมายเป็นอินสแตนซ์ VM จะมีผลบังคับใช้ในโครงสร้างเครือข่าย VPC แบบกระจายเป็นส่วนหนึ่งของเครือข่ายที่ซอฟต์แวร์กำหนด (Andromeda) หลักของ Google Cloud กฎการกรองแพ็กเก็ตและนโยบายไฟร์วอลล์จะบังคับใช้ที่ระดับไฮเปอร์ไวเซอร์ของอินสแตนซ์ VM แต่ละรายการ ก่อนที่แพ็กเก็ตจะไปถึงอินเทอร์เฟซเครือข่ายของอินสแตนซ์ VM

กฎนโยบาย Essentials ของ Cloud NGFW ที่กำหนดเป้าหมายเป็นตัวจัดสรรภาระงานจะบังคับใช้โดยใช้เทคโนโลยีพื้นฐานของตัวจัดสรรภาระงานของ Google Cloud ซึ่งก็คือโครงสร้างพื้นฐานของพร็อกซีบริการ Envoy การกรองแพ็กเกตแบบเก็บสถานะจะบังคับใช้โดยตรงใน Data Plane ของตัวจัดสรรภาระงานที่ใช้พร็อกซี โดยใช้โมเดลทรัพยากรและโครงสร้างกฎเดียวกันของ Cloud NFGW

เป้าหมายของตัวจัดสรรภาระงาน

นโยบาย Cloud NGFW ที่กำหนดเป้าหมายเป็นตัวจัดสรรภาระงานและนโยบายที่กำหนดเป้าหมายเป็นอินสแตนซ์ VMมีความแตกต่างที่สำคัญบางประการ

คุณใช้กฎนโยบายไฟร์วอลล์กับตัวจัดสรรภาระงานรายการเดียวได้โดยการระบุ --target-type=INTERNAL_MANAGED_LB พร้อมกับการอ้างอิงที่เฉพาะเจาะจงไปยังกฎการส่งต่อของตัวจัดสรรภาระงาน --target-forwarding-rules=FR_NAME หากต้องการกำหนดเป้าหมายกฎการส่งต่อตัวจัดสรรภาระงานทั้งหมดในภูมิภาคเครือข่าย VPC (ซึ่งนโยบายกำหนดขอบเขตภูมิภาค) คุณไม่จำเป็นต้องระบุการอ้างอิงที่เฉพาะเจาะจง และใช้เพียงแค่ตัวบ่งชี้ --target-type=INTERNAL_MANAGED_LB

หากไม่ได้ตั้งค่าพารามิเตอร์ --target-type ในการกำหนดค่ากฎ กฎจะใช้ค่าเริ่มต้นเป็นใช้กับอินสแตนซ์ VM ทั้งหมดโดยอัตโนมัติ และไม่ใช้กับตัวจัดสรรภาระงาน

หมายเหตุ: ลักษณะการทำงานของกฎนโยบายไฟร์วอลล์เริ่มต้นสำหรับตัวโหลดบาลานซ์คือ action=allow นี่เป็นลักษณะการทำงานปกติในแต่ละวันสำหรับตัวปรับโหลดภายในที่ไม่มีนโยบายไฟร์วอลล์แนบอยู่ อย่างไรก็ตาม การดำเนินการนี้จะมีผลกับตัวจัดสรรภาระงานที่มีนโยบายไฟร์วอลล์แนบอยู่ด้วยเมื่อแพ็กเก็ตไม่ตรงกับกฎที่กำหนดไว้ หากต้องการเปลี่ยนลักษณะการทำงานเริ่มต้นนี้ ให้กำหนดค่านโยบาย "ปฏิเสธทั้งหมด" ที่ชัดเจนโดยมีลำดับความสำคัญต่ำกว่า (หมายเลขลำดับความสำคัญสูงกว่า) เป็นการจับทั้งหมด

เครือข่าย Codelab

Codelab นี้ใช้โปรเจ็กต์เดียวที่มีเครือข่าย VPC 1 เครือข่ายและทรัพยากรต่อไปนี้

ซับเน็ตระดับภูมิภาค 2 รายการ
นโยบายไฟร์วอลล์เครือข่ายระดับภูมิภาค 1 รายการ
ตัวจัดสรรภาระงานของแอปพลิเคชันภายในระดับภูมิภาค 3 รายการ
- www บริการ HTTP ที่มีแบ็กเอนด์กลุ่มอินสแตนซ์ VM
- api บริการ HTTP ที่มีแบ็กเอนด์กลุ่มอินสแตนซ์ VM
- gcs บริการ HTTPS ที่มีแบ็กเอนด์ NEG ของ PSC ไปยัง Google API
อินสแตนซ์ VM 2 รายการเพื่อทดสอบนโยบายอนุญาตและปฏิเสธต่างๆ

รูปที่ 1 เครือข่าย Codelab

กฎนโยบายไฟร์วอลล์ที่กำหนดเป้าหมายตัวจัดสรรภาระงานจะลิงก์กับทรัพยากรกฎการส่งต่อของตัวจัดสรรภาระงาน ตัวจัดสรรภาระงานประกอบด้วยทรัพยากรที่กำหนดแยกกันซึ่งกำหนดค่าร่วมกันเพื่อให้บริการจัดสรรภาระงานที่สมบูรณ์ คำจำกัดความของกฎการส่งต่อจะอ้างอิงทรัพยากรพร็อกซีเป้าหมายที่เฉพาะเจาะจงซึ่งกำหนดไว้สำหรับกฎนั้นโดยตรง

รูปที่ 1 Cloud NFGW สำหรับทรัพยากรตัวจัดสรรภาระงาน

ตัวกรอง Essentials ของ Cloud NGFW ได้รับการตั้งโปรแกรมลงใน Data Plane ของตัวจัดสรรภาระงาน และนำไปใช้ที่เลเยอร์บริการพร็อกซีเป้าหมายที่กำหนด ซึ่งคล้ายกับอินเทอร์เฟซอินสแตนซ์ VM โดยใช้กลไกไฟร์วอลล์แบบกระจายและสอดคล้องกันเดียวกันเพื่อบังคับใช้นโยบาย

3. การตั้งค่าโปรเจ็กต์

เข้าถึงโปรเจ็กต์

Codelab นี้ใช้โปรเจ็กต์ที่อยู่ในระบบคลาวด์ของ Google เดียว ขั้นตอนการกำหนดค่าใช้คำสั่ง CLI ของ gcloud cli และคำสั่ง Shell ของ Linux

เริ่มต้นด้วยการเข้าถึงบรรทัดคำสั่งของโปรเจ็กต์ที่อยู่ในระบบคลาวด์ของ Google โดยทำดังนี้

Cloud Shell ที่ shell.cloud.google.com หรือ
เทอร์มินัลในเครื่องที่gcloud CLI ติดตั้งแล้ว

ตั้งค่ารหัสโปรเจ็กต์

gcloud config set project YOUR_PROJECT_ID_HERE

เปิดใช้บริการ API

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

ตั้งค่าตัวแปรสภาพแวดล้อมของ 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. พื้นฐานเครือข่าย

ในส่วนนี้ คุณจะทำให้ใช้งานได้พื้นฐานระบบเครือข่ายด้วยสิ่งต่อไปนี้

เครือข่าย VPC ทั่วโลกและซับเน็ตระดับภูมิภาค
นโยบายไฟร์วอลล์เครือข่ายระดับภูมิภาคเพื่อรักษาความปลอดภัยเครือข่าย VPC
Cloud Router และ Cloud NAT สำหรับเซิร์ฟเวอร์เพื่อดึงข้อมูลแพ็กเกจซอฟต์แวร์
การจองที่อยู่ IP และระเบียน DNS สำหรับขาเข้าของตัวจัดสรรภาระงาน

สร้างทรัพยากรเครือข่าย

# 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

สร้างคอมโพเนนต์ไฟร์วอลล์

ระบบจะใช้นโยบายไฟร์วอลล์เครือข่ายระดับภูมิภาคพื้นฐานที่สร้างขึ้นที่นี่ในภายหลังเมื่อเพิ่มเป้าหมายเฉพาะของตัวจัดสรรภาระงาน นโยบายต้องอยู่ในภูมิภาคเดียวกับตัวจัดสรรภาระงาน

สร้างกลุ่มที่อยู่

เริ่มต้นด้วยการสร้างกลุ่มที่อยู่เพื่อระบุช่วง IP ของการตรวจสอบประสิทธิภาพการทำงานต้นทางที่รองรับฟังก์ชันการทำงานของตัวจัดสรรภาระงาน คุณต้องอนุญาตช่วงเหล่านี้เพื่อให้แบ็กเอนด์ของตัวจัดสรรภาระงานถือว่ามีสถานะเป็นปกติ นอกจากนี้ยังจะใช้ในภายหลังกับกฎนโยบายไฟร์วอลล์ที่กำหนดเป้าหมายไปยังตัวจัดสรรภาระงานด้วย

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

สร้างนโยบายไฟร์วอลล์

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

กำหนดค่าบริการเครือข่าย

สร้าง Cloud Router และเกตเวย์ 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

จองที่อยู่ 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

สร้างระเบียน 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"

ตอนนี้เราได้ตั้งค่าเครือข่ายเรียบร้อยแล้ว ต่อไปเราจะกำหนดค่าตัวจัดสรรภาระงาน

5. บริการตัวจัดสรรภาระงาน

ในส่วนนี้ คุณจะติดตั้งใช้งานคอมโพเนนต์ของตัวจัดสรรภาระงาน (บริการแบ็กเอนด์, แมป URL, พร็อกซีเป้าหมาย และกฎการส่งต่อ) สำหรับ 3 บริการ ได้แก่

www บริการ (ilb-foo-www) ในพอร์ต 80
api บริการ (ilb-foo-api) ในพอร์ต 8080
บริการ gcs (ilb-foo-gcs) ในพอร์ต 443 ที่มีใบรับรอง TLS

พร้อมกับทรัพยากรแบ็กเอนด์ที่รองรับ

อินสแตนซ์ VM ที่เรียกใช้เซิร์ฟเวอร์ HTTP ในกลุ่มอินสแตนซ์ที่มีการจัดการ
กลุ่มปลายทางเครือข่าย (NEG) Private Service Connect (PSC) ไปยัง Google API
ที่เก็บข้อมูล Google Cloud Storage (GCS)

ตั้งค่าทรัพยากรแบ็กเอนด์

สร้างเซิร์ฟเวอร์กลุ่มอินสแตนซ์ VM

www ตัวจัดสรรภาระงานจะใช้เซิร์ฟเวอร์แบ็กเอนด์ของกลุ่มอินสแตนซ์ VM ที่เรียกใช้เว็บเซิร์ฟเวอร์ Apache ซึ่งรับฟังบนพอร์ต 80

api ตัวจัดสรรภาระงานจะใช้กลุ่มอินสแตนซ์ VM เดียวกันที่รับฟังในพอร์ต 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}

สร้างที่เก็บข้อมูล

gcs ตัวจัดสรรภาระงานจะใช้แบ็กเอนด์ NEG ของ PSC เพื่อเชื่อมต่อผ่านส่วนหน้าของ Google APIs ไปยังที่เก็บข้อมูล Cloud Storage

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

หมายเหตุ: ตัวแปรสภาพแวดล้อมจะหายไปเมื่อปิดเซสชันเชลล์ จดชื่อ Bucket ไว้หากจำเป็นต้องดำเนินการให้เสร็จสมบูรณ์ในเซสชันในอนาคต

# 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

สร้างใบรับรอง

gcs ตัวจัดสรรภาระงานจะสิ้นสุดคำขอ HTTPS ของไคลเอ็นต์ด้วยใบรับรองแบบ Self-signed ที่ติดตั้งใช้งานในพร็อกซี HTTPS เป้าหมาย

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

สร้างคอมโพเนนต์ของตัวจัดสรรภาระงาน

ใช้สคริปต์ต่อไปนี้เพื่อทำให้การติดตั้งใช้งานคอมโพเนนต์ของตัวจัดสรรภาระงานเป็นไปโดยอัตโนมัติ ซึ่งจะช่วยเพิ่มความเร็วและความแม่นยำในองค์ประกอบการกำหนดค่าทั้งหมดที่เกี่ยวข้อง

ทำให้สคริปต์การสร้างตัวจัดสรรภาระงานใช้งานได้

# 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

หมายเหตุ: สคริปต์นี้จะใช้เวลาหลายนาทีจึงจะเสร็จสมบูรณ์

ยืนยันการสร้างตัวจัดสรรภาระงาน

ตรวจสอบว่าได้ติดตั้งใช้งานกฎการส่งต่อและบริการแบ็กเอนด์แล้ว

# check forwarding rules
gcloud compute forwarding-rules list

# check backend services
gcloud compute backend-services list

ส่วนการตั้งค่าตัวจัดสรรภาระงานสิ้นสุดลงแล้ว... ต่อไปคือการกำหนดค่าอินสแตนซ์ VM ของไคลเอ็นต์

6. การเข้าถึงของลูกค้า

สร้างทรัพยากรไคลเอ็นต์ VM

ในส่วนนี้ คุณจะติดตั้งใช้งานไคลเอ็นต์และยืนยันการเชื่อมต่อแบบครบวงจร

สร้างอินสแตนซ์ 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

ทดสอบบริการพื้นฐาน

ทดสอบจากไคลเอ็นต์ `vm-allow`

หมายเหตุ: อินสแตนซ์ VM จะออนไลน์และเข้าถึงได้ผ่าน ssh โดยใช้ IAP หลังจากออกคำสั่ง instances create ไม่นาน คุณอาจต้องรอสักครู่หากคำขอไม่สำเร็จในครั้งแรก

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

ทดสอบการอัปโหลดไฟล์ไปยัง Google Cloud Storage ผ่านตัวจัดสรรภาระงาน

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

การตอบกลับของ Cloud Storage API จะยืนยันว่าเส้นทางเครือข่ายทำงานได้อย่างถูกต้อง

ทดสอบจากไคลเอ็นต์ `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"

หมายเหตุ: การทดสอบเหล่านี้ควรสำเร็จด้วย เนื่องจากยังไม่มีกฎไฟร์วอลล์ที่กำหนดเป้าหมายไปยังตัวจัดสรรภาระงาน

ตอนนี้เราได้ตั้งค่าหลักๆ ทั้งหมดแล้ว ต่อไปเราจะสร้างกฎไฟร์วอลล์ของตัวจัดสรรภาระงาน

7. ไฟร์วอลล์ของตัวจัดสรรภาระงาน

ในส่วนนี้ คุณจะทำให้กฎนโยบายไฟร์วอลล์ที่กำหนดเป้าหมายไปยังตัวจัดสรรภาระงานใช้งานได้ ลำดับการกำหนดค่าจะสร้างท่าทางด้านความปลอดภัยที่อนุญาตการเข้าถึง vm-allow และบล็อกการรับส่งข้อมูล vm-deny ไปยังบริการทั้งหมด

อนุญาตให้การรับส่งข้อมูลบางส่วนไปยัง `fr-foo-www`

เพิ่มกฎนโยบายไฟร์วอลล์ใหม่ไปยังนโยบายไฟร์วอลล์ที่มีอยู่ fw-policy-foo-${REGION_1}

อนุญาตช่วง IP ต้นทางที่มีที่อยู่ IP vm-allow และยกเว้นที่อยู่ IP vm-deny
เพิ่มตัวกรองแหล่งที่มาเพิ่มเติม INTRA_VPC เพื่อใช้ประเภทเครือข่ายในกฎนโยบายไฟร์วอลล์ที่กำหนดเป้าหมายไปยังตัวจัดสรรภาระงาน

ประเภทเครือข่ายต้นทางของ INTRA_VPC และ VPC_NETWORKS ได้รับการรองรับในกฎนโยบายไฟร์วอลล์ที่กำหนดเป้าหมายไปยังตัวจัดสรรภาระงานเมื่อใช้ร่วมกันกับพารามิเตอร์แหล่งที่มาอื่น ตรรกะการประเมินคือ AND ระหว่างพารามิเตอร์แหล่งที่มา 2 รายการ ในกรณีนี้ การรับส่งข้อมูลต้องเป็นไปตามเกณฑ์สำหรับ INTRA_VPC และ --src-ip-ranges=${VM_ALLOW_IP}/32 จึงจะได้รับอนุญาต

สร้างกฎเพื่ออนุญาต`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

ทดสอบจากไคลเอ็นต์ `vm-allow`

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

ทดสอบจากไคลเอ็นต์ `vm-deny`

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

หมายเหตุ: การดำเนินการนี้สำเร็จเนื่องจากลักษณะการทำงานของกฎนโยบายไฟร์วอลล์เริ่มต้นโดยนัยสำหรับตัวโหลดบาลานซ์คือ --action=allow คุณต้องมีกฎปฏิเสธเริ่มต้น (catchall) เพื่อเปลี่ยนการตั้งค่านี้

ปฏิเสธการรับส่งข้อมูลเริ่มต้นไปยัง `fr-foo-www`

เพิ่มกฎนโยบายไฟร์วอลล์ใหม่ที่มีลำดับความสำคัญต่ำกว่า (หมายเลขลำดับความสำคัญสูงกว่า)

ปฏิเสธการเข้าชมทั้งหมดจากที่อยู่ IP ต้นทางใดก็ได้
ระบบจะอนุญาตการรับส่งข้อมูลจาก vm-allow ไปยัง fr-foo-www ก่อนที่จะใช้กฎปฏิเสธ

สร้างกฎเพื่อปฏิเสธการรับส่งข้อมูลที่กำหนดเป้าหมายเป็น `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

ข้อควรพิจารณาสำหรับการตรวจสอบประสิทธิภาพการทำงาน

เช่นเดียวกับกฎนโยบายไฟร์วอลล์ที่กำหนดเป้าหมายเป็นอินสแตนซ์ VM กฎการปฏิเสธขาเข้าแบบครอบคลุม (โดยนัย) โดยค่าเริ่มต้นจะบล็อกการรับส่งข้อมูลที่มาจากช่วงการตรวจสอบประสิทธิภาพการทำงานซึ่งมีปลายทางเป็นแบ็กเอนด์ของตัวจัดสรรภาระงาน ดังนั้นจึงมีการกำหนดค่ากฎการอนุญาตที่ชัดเจนเพื่ออนุญาตช่วงการตรวจสอบประสิทธิภาพการทำงานขาเข้า (ดูที่กฎ 1002)

สำคัญ: ในทำนองเดียวกัน เมื่อสร้างกฎการปฏิเสธขาเข้าทั้งหมด (ชัดเจน) สำหรับเป้าหมายของตัวจัดสรรภาระงาน คุณต้องสร้างกฎอื่นที่มีลำดับความสำคัญสูงกว่า (หมายเลขลำดับความสำคัญต่ำกว่า) เพื่ออนุญาตขาเข้าจากช่วงการตรวจสอบประสิทธิภาพการทำงานของ Health Check กฎนี้ต้องกำหนดเป้าหมายไปยังตัวจัดสรรภาระงาน

# 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

ทดสอบจากไคลเอ็นต์ `vm-deny`

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

ตอนนี้คำสั่งนี้ควรจะล้มเหลวเนื่องจากกฎไฟร์วอลล์ 2999 ปฏิเสธการรับส่งข้อมูลทั้งหมดที่มาจากเครือข่าย VPC กฎที่มีลำดับความสำคัญสูงกว่า (หมายเลขลำดับความสำคัญต่ำกว่า) 2001 อนุญาตเฉพาะช่วงแหล่งที่มาซึ่งรวม vm-allow

หยุดกระบวนการ curl โดยกด 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 ยังคงเข้าถึงบริการ API ได้ การดำเนินการนี้สำเร็จเนื่องจากกฎไฟร์วอลล์มีผลเฉพาะกับกฎการส่งต่อ fr-foo-www และไม่ได้กำหนดเป้าหมายเป็น fr-foo-api

อัปเดตกฎเพื่อกำหนดเป้าหมายตัวจัดสรรภาระงานทั้งหมด

หมายเหตุ: คุณสามารถใช้กฎนโยบายไฟร์วอลล์กับ Load Balancer ทั้งหมดในเครือข่าย VPC ได้โดยละเว้น --target-forwarding-rules=FR_NAME

เปลี่ยนกฎนโยบายไฟร์วอลล์ให้มีผลกับเป้าหมายกฎการส่งต่อของตัวจัดสรรภาระงานทั้งหมดในเครือข่าย VPC

สร้างกฎอนุญาตขาเข้าใหม่ 2003 ที่กำหนดเป้าหมายเป็นกฎการส่งต่อทั้งหมดเพื่ออนุญาตการรับส่งข้อมูล VM (vm-allow ช่วง IP)
สร้างกฎอนุญาตขาเข้าใหม่ 2004 ที่กำหนดเป้าหมายกฎการส่งต่อทั้งหมดเพื่ออนุญาตการรับส่งข้อมูลการตรวจสอบสถานะ (กลุ่มที่อยู่ uhc-probes)
สร้างกฎปฏิเสธขาเข้าใหม่ 2998 ที่กำหนดเป้าหมายเป็นกฎการส่งต่อทั้งหมดเพื่อปฏิเสธการรับส่งข้อมูลอื่นๆ ทั้งหมด

แก้ไขกฎไฟร์วอลล์เพื่อกำหนดเป้าหมายไปยังตัวจัดสรรภาระงานทั้งหมด

# 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

คุณสามารถนำกฎนโยบายไฟร์วอลล์ก่อนหน้านี้ที่กำหนดเป้าหมายเป็นกฎการส่งต่อของตัวจัดสรรภาระงานที่ชัดเจนออกได้ เนื่องจากขณะนี้กฎดังกล่าวซ้ำซ้อนกับกฎที่กำหนดเป้าหมายเป็นกฎการส่งต่อทั้งหมดในเครือข่าย 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}

ทดสอบจากไคลเอ็นต์ `vm-deny`

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

ตอนนี้คำสั่งนี้ควรจะล้มเหลวเนื่องจากกฎนโยบายไฟร์วอลล์ทั้งหมดที่มี --target-type=INTERNAL_MANAGED_LB จะกำหนดเป้าหมายเป็น fr-foo-api ด้วย

หยุดกระบวนการ curl โดยกด Ctrl+C

ทดสอบการดาวน์โหลดไฟล์จาก Google Cloud Storage ผ่านตัวจัดสรรภาระงาน

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

หยุดกระบวนการ curl โดยกด Ctrl+C

ทดสอบจากไคลเอ็นต์ `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"

ยืนยันเนื้อหาที่ดาวน์โหลด

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

บริการตัวจัดสรรภาระงานทั้งหมดพร้อมให้บริการแก่ vm-allow และบล็อก vm-deny เรียบร้อยแล้ว

ส่วนการทดสอบก็จบลงเพียงเท่านี้... ต่อไปเราจะมาดูการบันทึกข้อมูลกันคร่าวๆ

8. การบันทึกกฎไฟร์วอลล์

รูปแบบบันทึกไฟร์วอลล์มีฟิลด์และบันทึกสำหรับกฎที่กำหนดเป้าหมายไปยังตัวจัดสรรภาระงาน (--target-type=INTERNAL_MANAGED_LB)

โดยบันทึกจะมีฟิลด์เพิ่มเติมที่มีป้ายกำกับ load_balancer_details พร้อมข้อมูลเพิ่มเติมเกี่ยวกับตัวจัดสรรภาระงานที่กำหนดเป้าหมายกฎนโยบายไฟร์วอลล์ ซึ่งคล้ายกับรูปแบบฟิลด์ InstanceDetails เมื่อกำหนดเป้าหมายอินสแตนซ์ VM ในกฎนโยบายไฟร์วอลล์

load_balancer_details.forwarding_rule_name แสดงกฎการส่งต่อเป้าหมายของกฎนโยบายไฟร์วอลล์
load_balancer_details.type ระบุว่ากําหนดเป้าหมายไปยังตัวจัดสรรภาระงานที่อิงตามพร็อกซีประเภทใด
load_balancer_details.url_map_name บันทึกทรัพยากรแมป URL ที่ใช้เมื่อประเภทเป็นตัวจัดสรรภาระงานแอปพลิเคชัน

ดูบันทึก

ค้นหาบันทึกไฟร์วอลล์เพื่อดูผลลัพธ์ของกฎนโยบายไฟร์วอลล์

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

เอาต์พุตของบันทึกจะแสดงกฎที่มีผลบังคับใช้ตามนโยบาย ดังนี้

กฎ 2011 อนุญาตการรับส่งข้อมูล vm-allow ทั้งหมดไปยังตัวจัดสรรภาระงานทั้งหมด
กฎ 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

นอกจากนี้ คุณยังดูบันทึกในคอนโซล Google Cloud ได้โดยใช้ Logs Explorer ไปที่ console.cloud.google.com/logs/query แล้วใช้บันทึกไฟร์วอลล์ VPC มาตรฐาน compute.googleapis.com/firewall

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

ส่วนการบันทึกก็มีเพียงเท่านี้... มาเริ่มล้างข้อมูลกันเลย

9. ล้างข้อมูล

# 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. บทสรุป

ยินดีด้วย คุณกำหนดค่า Cloud NGFW Essentials สำหรับตัวจัดสรรภาระงานเรียบร้อยแล้ว

โปรดแสดงความคิดเห็น ถามคำถาม หรือแก้ไขโดยใช้แบบฟอร์มความคิดเห็นนี้

ขอขอบคุณ

ข้อควรทราบเกี่ยวกับ Cloud NGFW สำหรับตัวจัดสรรภาระงาน

1. บทนำ

สิ่งที่คุณจะได้เรียนรู้

สิ่งที่ต้องมี

2. แนวคิด

ระดับฟีเจอร์ไฟร์วอลล์

การกรอง Data Plane

เป้าหมายของตัวจัดสรรภาระงาน

เครือข่าย Codelab

3. การตั้งค่าโปรเจ็กต์

เข้าถึงโปรเจ็กต์

ตั้งค่ารหัสโปรเจ็กต์

เปิดใช้บริการ API

ตั้งค่าตัวแปรสภาพแวดล้อมของ Shell

4. พื้นฐานเครือข่าย

สร้างทรัพยากรเครือข่าย

สร้างคอมโพเนนต์ไฟร์วอลล์

สร้างกลุ่มที่อยู่

สร้างนโยบายไฟร์วอลล์

กำหนดค่าบริการเครือข่าย

สร้าง Cloud Router และเกตเวย์ NAT

จองที่อยู่ IP

สร้างระเบียน DNS

5. บริการตัวจัดสรรภาระงาน

ตั้งค่าทรัพยากรแบ็กเอนด์

สร้างเซิร์ฟเวอร์กลุ่มอินสแตนซ์ VM

สร้างที่เก็บข้อมูล

สร้างใบรับรอง

สร้างคอมโพเนนต์ของตัวจัดสรรภาระงาน

ทำให้สคริปต์การสร้างตัวจัดสรรภาระงานใช้งานได้

ยืนยันการสร้างตัวจัดสรรภาระงาน

6. การเข้าถึงของลูกค้า

สร้างทรัพยากรไคลเอ็นต์ VM

สร้างอินสแตนซ์ VM

ทดสอบบริการพื้นฐาน

ทดสอบจากไคลเอ็นต์ vm-allow

ทดสอบจากไคลเอ็นต์ vm-deny

7. ไฟร์วอลล์ของตัวจัดสรรภาระงาน

อนุญาตให้การรับส่งข้อมูลบางส่วนไปยัง fr-foo-www

สร้างกฎเพื่ออนุญาตvm-allowการกำหนดเป้าหมายfr-foo-www

ทดสอบจากไคลเอ็นต์ vm-allow

ทดสอบจากไคลเอ็นต์ vm-deny

ปฏิเสธการรับส่งข้อมูลเริ่มต้นไปยัง fr-foo-www

สร้างกฎเพื่อปฏิเสธการรับส่งข้อมูลที่กำหนดเป้าหมายเป็น fr-foo-www

ข้อควรพิจารณาสำหรับการตรวจสอบประสิทธิภาพการทำงาน

ทดสอบจากไคลเอ็นต์ vm-deny

อัปเดตกฎเพื่อกำหนดเป้าหมายตัวจัดสรรภาระงานทั้งหมด

แก้ไขกฎไฟร์วอลล์เพื่อกำหนดเป้าหมายไปยังตัวจัดสรรภาระงานทั้งหมด

ทดสอบจากไคลเอ็นต์ vm-deny

ทดสอบจากไคลเอ็นต์ vm-allow

8. การบันทึกกฎไฟร์วอลล์

ดูบันทึก

9. ล้างข้อมูล

10. บทสรุป

ทดสอบจากไคลเอ็นต์ `vm-allow`

ทดสอบจากไคลเอ็นต์ `vm-deny`

อนุญาตให้การรับส่งข้อมูลบางส่วนไปยัง `fr-foo-www`

สร้างกฎเพื่ออนุญาต`vm-allow`การกำหนดเป้าหมาย`fr-foo-www`

ทดสอบจากไคลเอ็นต์ `vm-allow`

ทดสอบจากไคลเอ็นต์ `vm-deny`

ปฏิเสธการรับส่งข้อมูลเริ่มต้นไปยัง `fr-foo-www`

สร้างกฎเพื่อปฏิเสธการรับส่งข้อมูลที่กำหนดเป้าหมายเป็น `fr-foo-www`

ทดสอบจากไคลเอ็นต์ `vm-deny`

ทดสอบจากไคลเอ็นต์ `vm-deny`

ทดสอบจากไคลเอ็นต์ `vm-allow`