1. מבוא
איזון העומסים ב-Google Cloud נפרס בקצה הרשת של Google בנקודות נוכחות (POP) של Google ברחבי העולם. תעבורת משתמשים שמנותבת למאזן עומסים של TCP Proxy נכנסת לנקודת ה-PoP שהכי קרובה למשתמש, ואז מתבצע איזון עומסים ברשת הגלובלית של Google עד להגעה לקצה העורפי הקרוב ביותר עם קיבולת מספקת.
Cloud Armor היא מערכת של Google לזיהוי מתקפות מניעת שירות (DDoS) וחומת אש ליישומי אינטרנט (WAF). שירות Cloud Armor משולב באופן הדוק עם מאזן העומסים של שרת ה-proxy של TCP ב-Google Cloud, ומאפשר לבדוק את התעבורה הנכנסת כדי לזהות בקשות לא רצויות. התכונה של הגבלת קצב של יצירת בקשות בשירות הזה מאפשרת לכם לצמצם את תעבורת הנתונים למשאבי ה-Backend על סמך נפח הבקשות, ומונעת מתעבורת נתונים לא רצויה לצרוך משאבים ברשת ה-VPC.
מאזני עומסים מסוג TCP/SSL proxy ב-Google Cloud מאפשרים לכם להשתמש בשרת proxy כדי לנתב תעבורת נתונים מסוג TCP/ SSL בין שירותי ה-Backend שלכם.
ב-Codelab הזה תלמדו איך ליצור מאזן עומסים בשרת proxy של TCP/SSL עם שירות לקצה העורפי, ואיך להשתמש ב-Cloud Armor כדי להגביל את הגישה למאזן העומסים רק לקבוצה ספציפית של לקוחות משתמשים.
מה תלמדו
- איך יוצרים מאזן עומסים מסוג TCP/SSL proxy
- איך יוצרים מדיניות אבטחה של Cloud Armor
- איך יוצרים כלל של רשימת כתובות IP שמהן הגישה נחסמת למאזן עומסים של TCP/SSL Proxy ב-Cloud Armor
- איך יוצרים כלל להגבלת קצב של יצירת בקשות למאזן עומסים של TCP Proxy ב-Cloud Armor
- איך מוסיפים את מדיניות האבטחה לשירות קצה עורפי של איזון עומסים ב-TCP/SSL
הדרישות
- ידע בסיסי ב-Google Compute Engine ( codelab)
- ידע בסיסי ברישות וב-TCP/IP
- ידע בסיסי בשורת הפקודה של Unix/Linux
- מומלץ להשלים סיור מודרך ברשת ב-GCP באמצעות Networking in the Google Cloud
2. דרישות
הגדרת סביבה בקצב עצמי
- נכנסים אל Cloud Console ויוצרים פרויקט חדש או משתמשים בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או Google Workspace, אתם צריכים ליצור חשבון.
הערה: כדי לגשת בקלות ל-Cloud Console, אפשר לזכור את כתובת ה-URL שלו: console.cloud.google.com.
חשוב לזכור את מזהה הפרויקט, שהוא שם ייחודי בכל הפרויקטים ב-Google Cloud (השם שלמעלה כבר תפוס ולא יתאים לכם, מצטערים!). בהמשך ה-codelab הזה, הוא יופיע כ-PROJECT_ID.
הערה: אם אתם משתמשים בחשבון Gmail, אתם יכולים להשאיר את מיקום ברירת המחדל ללא ארגון. אם אתם משתמשים בחשבון Google Workspace, אתם צריכים לבחור מיקום שמתאים לארגון שלכם.
- לאחר מכן, תצטרכו להפעיל את החיוב ב-Cloud Console כדי להשתמש במשאבים של Google Cloud.
העלות של התרגול הזה לא אמורה להיות גבוהה, ואולי אפילו לא תצטרכו לשלם בכלל. חשוב לפעול לפי ההוראות שבקטע 'ניקוי' כדי להשבית את המשאבים, וכך לא תחויבו על שימוש מעבר למה שמוסבר במדריך הזה. משתמשים חדשים ב-Google Cloud זכאים לתוכנית תקופת ניסיון בחינם בשווי 300$.
הפעלת Cloud Shell
אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-codelab הזה תשתמשו ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.
ב-GCP Console, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:
יחלפו כמה רגעים עד שההקצאה והחיבור לסביבת העבודה יושלמו. בסיום התהליך, אמור להופיע משהו כזה:
המכונה הווירטואלית הזו כוללת את כל הכלים שדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את הביצועים והאימות ברשת. אפשר לבצע את כל העבודה ב-Lab הזה רק באמצעות דפדפן.
לפני שמתחילים
ב-Cloud Shell, מוודאים שמזהה הפרויקט מוגדר
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] PROJECT_ID=[YOUR-PROJECT-NAME] echo $PROJECT_ID
הפעלת ממשקי ה-API
הפעלת כל השירותים הנדרשים
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. יצירת שירותים לקצה העורפי
יוצרים 2 מכונות באופן הבא – יוצרים את מכונה1-b1 באזור us-central1-b
gcloud compute instances create vm-1-b1 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b1 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
יוצרים את מכונה 1-b2 באזור us-central1-b
gcloud compute instances create vm-1-b2 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b2 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
יצירת קבוצת מופעים vm-ig1
gcloud compute instance-groups unmanaged create vm-ig1 --zone us-central1-b
יוצרים יציאה עם שם לקבוצת המופעים. בשיעור ה-Lab הזה נשתמש ביציאה 110
gcloud compute instance-groups set-named-ports vm-ig1 \ --named-ports tcp 110:110 --zone us-central1-b
הוספת המופעים לקבוצת המופעים
gcloud compute instance-groups unmanaged add-instances vm-ig1 \ --instances vm-1-b1,vm-1-b2 --zone us-central1-b
4. הגדרת מאזן העומסים
בשלב הבא ניצור בדיקת תקינות.
gcloud compute health-checks create tcp my-tcp-health-check --port 110
יצירת שירות לקצה העורפי
gcloud compute backend-services create my-tcp-lb --global-health-checks --global \ --protocol TCP --health-checks my-tcp-health-check --timeout 5m --port-name tcp110
הוספת קבוצת המכונות לשירות הקצה העורפי
gcloud compute backend-services add-backend my-tcp-lb --global --instance-group \ vm-ig1 --instance-group-zone us-central1-b --balancing-mode UTILIZATION \ --max-utilization 0.8
הגדרת שרת proxy של TCP ביעד
gcloud compute target-tcp-proxies create my-tcp-lb-target-proxy --backend-service \ my-tcp-lb --proxy-header NONE
שמירת כתובות IPv4 סטטיות גלובליות
כתובת ה-IP הזו תשמש אתכם כדי להגיע לשירות עם איזון עומסים.
gcloud compute addresses create tcp-lb-static-ipv4 --ip-version=IPV4 --global
הגדרת כללי העברה גלובליים לכתובת ה-IP של מאזן העומסים.
gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
--global --target-tcp-proxy my-tcp-lb-target-proxy --address LB_STATIC_IPV4 \ --ports 110
5. יצירת כלל לחומת האש עבור מאזן העומסים בשרתי TCP Proxy
gcloud compute firewall-rules create allow-tcplb-and-health \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --target-tags tcp-lb \ --allow tcp:110
אחרי שיוצרים את מאזן העומסים, בודקים אותו באמצעות הפקודה הבאה
Curl LB_IP:110
בשלב הבא, יוצרים מכונות וירטואליות (VM) כדי לאמת את דחיית הגישה ל-LB
צריך ליצור 2 מופעים, לכל אחד מהם כתובת IP ציבורית, ולתת להם את השמות test-server1 ו-test-server2.
6. יצירת מדיניות אבטחה ב-Cloud Armor
בקטע הזה תיצרו כללי מדיניות לאבטחת ה-Backend ו-2 כללים במדיניות ב-Cloud Armor.
הכלל הראשון ימנע מסט מוגבל של כתובות IP לגשת למאזן העומסים של TCP על ידי הגדרת מדיניות אבטחה לדחיית כתובות IP מסוימות, והכלל השני יבצע הגבלת קצב של יצירת בקשות.
- ב-Cloud Shell(הוראות לשימוש ב-Cloud Shell מופיעות בקטע 'הגדרה ודרישות'), יוצרים מדיניות אבטחה של שירות לקצה העורפי בשם rate-limit-and-deny-tcp באופן הבא:
gcloud compute security-policies create rate-limit-and-deny-tcp \
--description "policy for tcp proxy rate limiting and IP deny"
הוספת כללים למדיניות האבטחה
לאחר מכן מוסיפים כלל לרשימת הדחייה למדיניות Cloud Armor rate-limit-and-deny-tcp.
gcloud compute security-policies rules create 1000 --action deny --security-policy \ rate-limit-and-deny-tcp --description "deny test-server1" --src-ip-ranges \ "enter-test-server-1ip-here"
הוספת כלל להגבלת קצב של יצירת בקשות למדיניות האבטחה של Cloud Armor rate-limit-and-deny-tcp
gcloud compute security-policies rules create 3000 \ --security-policy=rate-limit-and-deny-tcp \ --expression="true" --action=rate-based-ban --rate-limit-threshold-count=5 \ --rate-limit-threshold-interval-sec=60 --ban-duration-sec=300 \ --conform-action=allow --exceed-action=deny-404 --enforce-on-key=IP
צירוף מדיניות לשירות קצה עורפי של TCP Proxy:
מריצים את הפקודה הבאה כדי לוודא שמדיניות האבטחה מצורפת לשירות לקצה העורפי של TCP Proxy.
gcloud compute backend-services update my-tcp-lb --security-policy \ rate-limit-and-deny-tcp
הפעלת רישום ביומן ב-TCP Proxy Load Balancer
gcloud beta compute backend-services update my-tcp-lb \ --enable-logging --logging-sample-rate=1
7. אימות של כלל ברשימת הדחייה
כדי לוודא שכלל הרשימה לדחייה תקין, מתחברים לשרת הבדיקה שכתובת ה-IP שלו צוינה בכלל הרשימה לדחייה ומריצים את הפקודה הבאה:
Curl LB_IP:110
בקשות מיידיות עשויות להניב תגובה מ-LB, אבל צריך לחכות עד שהבקשה של curl תידחה או תיפסל, ואז לבדוק את היומנים ב-Cloud Logging כדי לוודא שרשומה ביומן עבור כלל דחיית כתובת ה-IP הופעל.
עוברים אל Cloud Logging ובקטע Resources (משאבים) בוחרים את סוג המשאב tcp_ssl_proxy_rule ומגדירים את יעד ה-backend כ-my-tcp-lb.
אחרי שמגדירים את המשאבים לסינון, אפשר לוודא שכלל דחיית כתובות ה-IP פועל לפי ערך העדיפות 1000 ברשומה ביומן, ושהפעולה המוגדרת DENY פועלת כי שתיהן הוגדרו לפי כלל הדחייה וכתובת ה-IP שנדחית, כמו שמוצג בהמשך
8. אימות של כלל להגבלת קצב של יצירת בקשות
כדי לוודא שכלל הגבלת הקצב פועל, שולחים הרבה בקשות בפרק זמן קצר שחורג מהסף שהוגדר (5 בקשות בדקה).
אחרי שמסיימים, לוחצים על 'הצגת יומנים' בשירות Cloud Armor. הפעולה הזו מעבירה אתכם אל Cloud Logging, שם תוכלו לסנן את היומנים לפי מאזן העומסים כדי לראות את היומנים של Cloud Armor כשהם מגיעים.
רשומה של הגבלת קצב של יצירת בקשות צריכה להיראות כמו בצילום המסך שלמטה. אפשר לוודא שכלל הגבלת קצב של יצירת בקשות פועל לפי הערך PRIORITY של 3,000 ברשומה ביומן, ולפי הפעולה שהוגדרה, הפעולה RATE BASED BAN פועלת לפי ההוראות של כלל הגבלת קצב של יצירת בקשות.
9. ניקוי הסביבה
חשוב למחוק את התשתית שנוצרה כדי להימנע מחיובים על תשתית שלא נמצאת בשימוש.
הדרך הכי מהירה היא למחוק את הפרויקט כולו ב-GCP כדי לוודא שלא נשארו משאבים לא פעילים ללא טיפול.עם זאת, אפשר למחוק את המשאבים בנפרד באמצעות הפקודות הבאות
מאזן העומסים TCP Proxy
gcloud compute target-tcp-proxies delete my-tcp-lb
קבוצת המופעים
gcloud compute instance-groups unmanaged delete vm-ig1
שתי מכונות וירטואליות לבדיקה נוצרו
gcloud compute instances delete Instance_name --zone=instance_zone
השירות לקצה העורפי
gcloud compute backend-services delete BACKEND_SERVICE_NAME
הכללים של Cloud Armor במסגרת המדיניות
gcloud compute security-policies rules delete 1000 \ --security-policy=rate-limit-and-deny-tcp && gcloud compute security-policies rules delete 3000 \ --security-policy=rate-limit-and-deny-tcp
מדיניות האבטחה של Cloud Armor
gcloud compute security-policies delete rate-limit-and-deny-tcp