הגבלת הקצב של יצירת הבקשות באמצעות Cloud Armor

1. מבוא

איזון העומסים של HTTP(S) ב-Google Cloud נפרס בקצה הרשת של Google בנקודות נוכחות (POP) של Google ברחבי העולם. תעבורת משתמשים שמנותבת למאזן עומסים מסוג HTTP(S) נכנסת ל-POP שהכי קרוב למשתמש, ואז מתבצע איזון עומסים ברשת הגלובלית של Google עד להגעה לקצה העורפי הכי קרוב שיש בו מספיק קיבולת פנויה.

‫Cloud Armor היא מערכת של Google לזיהוי מתקפות מניעת שירות (DDoS) וחומת אש ליישומי אינטרנט (WAF). שירות Cloud Armor משולב באופן הדוק עם מאזן העומסים של HTTP ב-Google Cloud, ומאפשר לכם לבדוק את התנועה הנכנסת כדי לזהות בקשות לא רצויות. התכונה של הגבלת קצב בשירות הזה מאפשרת לכם לצמצם את התעבורה למשאבי קצה עורפיים על סמך נפח הבקשות, ומונעת מתעבורה לא רצויה לצרוך משאבים ברשת הענן הווירטואלי הפרטי (VPC).

בשיעור ה-Lab הזה תגדירו מאזן עומסים (LB) מסוג HTTP עם מערכות בק-אנד גלובליות, כמו שמוצג בתרשים שלמטה. לאחר מכן, תבצעו בדיקת עומס על מאזן העומסים ותוסיפו מדיניות להגבלת קצב ב-Cloud Armor כדי להגביל את התנועה שמגיעה למשאבי ה-Backend.

מה תלמדו

• איך מגדירים מאזן עומסים מסוג HTTP עם בדיקות תקינות מתאימות.
• איך יוצרים מדיניות להגבלת קצב יצירת בקשות ב-Cloud Armor.
• איך מוודאים שמדיניות הגבלת הקצב חוסמת תעבורה כשמריצים בדיקת עומס ממכונה וירטואלית.

מה תצטרכו

• ידע בסיסי ברשתות ו-HTTP
• ידע בסיסי בשורת הפקודה של Unix/Linux

2. הגדרה ודרישות

הגדרת סביבה בקצב אישי

1. נכנסים ל-מסוף Google Cloud ויוצרים פרויקט חדש או משתמשים בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או Google Workspace, אתם צריכים ליצור חשבון.

• שם הפרויקט הוא השם המוצג למשתתפים בפרויקט. זו מחרוזת של תווים שלא נמצאת בשימוש ב-Google APIs, ואפשר לעדכן אותה בכל שלב.
• מזהה הפרויקט חייב להיות ייחודי לכל הפרויקטים ב-Google Cloud, והוא קבוע (אי אפשר לשנות אותו אחרי שהוא מוגדר). מסוף Cloud יוצר באופן אוטומטי מחרוזת ייחודית. בדרך כלל לא צריך לדעת מה היא. ברוב סדנאות ה-Codelab, תצטרכו להפנות למזהה הפרויקט (ובדרך כלל הוא מזוהה כ-PROJECT_ID), אז אם אתם לא אוהבים אותו, תוכלו ליצור מזהה אקראי אחר, או לנסות ליצור מזהה משלכם ולראות אם הוא זמין. אחרי שהפרויקט נוצר, הוא 'קפוא'.
• יש ערך שלישי, מספר פרויקט, שמשמש חלק מממשקי ה-API. מידע נוסף על שלושת הערכים האלה מופיע במאמרי העזרה.

חשוב לדעת: מזהה הפרויקט חייב להיות ייחודי גלובלית, ואחרי שבוחרים אותו אף אחד אחר לא יכול להשתמש בו. אתם המשתמשים היחידים במזהה הזה. אם פרויקט נמחק, אי אפשר להשתמש שוב במזהה שלו.

הערה: אם אתם משתמשים בחשבון Gmail, אתם יכולים להשאיר את מיקום ברירת המחדל כללא ארגון. אם אתם משתמשים בחשבון Google Workspace, אתם צריכים לבחור מיקום שמתאים לארגון שלכם.

2. בשלב הבא, תצטרכו להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבי Cloud או בממשקי API. העלות של התרגול הזה לא אמורה להיות גבוהה, ואולי לא תהיה עלות בכלל. כדי לכבות את המשאבים ולא לחייב אתכם מעבר למה שמוסבר במדריך הזה, צריך לפעול לפי ההוראות לניקוי שמופיעות בסוף ה-Codelab. משתמשים חדשים ב-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. הגדרת כלל של חומת אש שמאפשר תעבורת נתונים מסוג HTTP אל השרתים העורפיים

מגדירים כללי חומת אש שמאפשרים תעבורת HTTP אל השרתים העורפיים מבדיקות התקינות של Google Cloud וממאזן העומסים.

נשתמש ברשת ה-VPC default שנוצרה בפרויקט. יוצרים כלל חומת אש שמאפשר תעבורת HTTP אל השרתים העורפיים. בדיקות התקינות קובעות אילו מופעים של איזון עומסים יכולים לקבל חיבורים חדשים. באיזון עומסים של HTTP, בדיקות תקינות של מופעים מאוזני עומסים מגיעות מכתובות בטווחים ‎130.211.0.0/22 ו-‎35.191.0.0/16. כללי חומת האש ב-VPC צריכים לאפשר את החיבורים האלה. בנוסף, מאזני העומסים מתקשרים עם הבק-אנד באותו טווח כתובות IP.

1. ב-Cloud Console, עוברים אל תפריט הניווט ( ) > רשת VPC > Firewall.

2. שימו לב לכללים הקיימים של חומת האש: ICMP,‏ internal,‏ RDP ו-SSH.כל פרויקט בענן ב-Google Cloud מתחיל עם רשת ברירת המחדל ועם הכללים האלה של חומת האש.
3. לוחצים על יצירת כלל לחומת האש.
4. מגדירים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
שם	default-allow-health-check
רשת	ברירת מחדל
יעדים	תגי יעד שצוינו
תגי טירגוט	http-server
מסנן מקור	טווחי כתובות IP
טווח כתובות ה-IP של המקור	‫130.211.0.0/22, 35.191.0.0/16
פרוטוקולים ויציאות	מציינים פרוטוקולים ויציאות, ואז מסמנים את tcp

חשוב להזין את שני טווח כתובות ה-IP של המקור בנפרד וללחוץ על מקש הרווח ביניהם.

5. לוחצים על יצירה.

לחלופין, אם אתם משתמשים בשורת הפקודה gcloud. זו הפקודה –

gcloud compute firewall-rules create default-allow-health-check --direction=INGRESS --priority=1000 --network=default --action=ALLOW --rules=tcp --source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=http-server

4. הגדרה של תבניות של מופעי מכונה ויצירה של קבוצות של מופעי מכונה מנוהלים

קבוצת מופעי מכונה מנוהלים משתמשת בתבנית של הגדרות מכונה כדי ליצור קבוצה של מופעים זהים. משתמשים בהם כדי ליצור את הקצוות העורפיים של מאזן העומסים מסוג HTTP.

הגדרת תבניות של מכונות

תבנית של הגדרות מכונה היא משאב API שמשמש ליצירת מכונות וירטואליות וקבוצות של מופעי מכונה מנוהלים. תבניות של מכונות מגדירות את סוג המכונה, את תמונת דיסק האתחול, את רשת המשנה, את התוויות ומאפיינים אחרים של המכונה. יוצרים תבנית של הגדרות מכונה אחת ל-us-east1 ותבנית של הגדרות מכונה אחת ל-europe-west1.

1. ב-Cloud Console, מנווטים אל תפריט הניווט ( ) > Compute Engine > תבניות של הגדרות מכונה, ואז לוחצים על יצירת תבנית של הגדרות מכונה.
2. בשדה Name (שם), מקלידים us-east1-template.
3. בשדה Series, בוחרים באפשרות N1.
4. לוחצים על Networking, Disks, Security, Management , Sole-Tenancy.

5. עוברים לקטע ניהול.

6. בקטע מטא-נתונים, לוחצים על הוספת פריט ומציינים את הפרטים הבאים:

מקש	ערך
startup-script-url	gs://cloud-training/gcpnet/httplb/startup.sh

המאפיין startup-script-url מציין סקריפט שמופעל כשמפעילים את המופעים. הסקריפט הזה מתקין את Apache ומשנה את דף הפתיחה כך שיכלול את כתובת ה-IP של הלקוח ואת השם, האזור והתחום של המכונה הווירטואלית. אפשר לעיין בסקריפט הזה כאן.

7. לוחצים על Networking.
8. מגדירים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
רשת (בקטע Network Interfaces)	ברירת מחדל
רשת משנה (בקטע Network Interfaces)	ברירת מחדל (us-east1)
תגים של רשתות	http-server

תג הרשת http-server מבטיח שכללי חומת האש של HTTP ובדיקת תקינות יחולו על המופעים האלה.

9. לוחצים על יצירה.
10. ממתינים ליצירת תבנית המופע.

עכשיו יוצרים עוד תבנית של הגדרות מכונה בשביל subnet-b על ידי העתקה של us-east1-template:

1. לוחצים על us-east1-template ואז על האפשרות Copy (העתקה) בחלק העליון.
2. בשדה Name (שם), מקלידים europe-west1-template.
3. לוחצים על Networking, Disks, Security, Management , Sole-Tenancy.
4. לוחצים על Networking.
5. בקטע Network Interfaces,עורכים את ממשק ברירת המחדל. בקטע Subnet, בוחרים באפשרות default (europe-west1).
6. לוחצים על יצירה.

יצירת קבוצות של מופעי מכונה מנוהלים

יוצרים קבוצה של מופעי מכונה מנוהלים באזור us-east1 וקבוצה נוספת באזור europe-west1.

1. עדיין ב-Compute Engine, לוחצים על Instance groups בתפריט הימני.

2. לוחצים על יצירת קבוצת מופעים. בוחרים באפשרות קבוצת מופעי מכונה מנוהלים חדשה (בלי שמירת מצב).
3. מגדירים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
שם	us-east1-mig
מיקום	כמה תחומים
אזור	us-east1
תבנית של הגדרות מכונה	us-east1-template
שינוי קנה מידה אוטומטי > מדיניות שינוי קנה מידה אוטומטי > לוחצים על סמל העיפרון > סוג המדד	ניצול יחידת העיבוד המרכזית (CPU)
ניצול יעד של יחידת העיבוד המרכזית (CPU)	‫80, לוחצים על סיום.
תקופת צינון	45
מספר המופעים המינימלי	1
מספר המופעים המקסימלי	5

קבוצות של מופעי מכונה מנוהלים (MIG) מציעות יכולות של שינוי גודל אוטומטי שמאפשרות לכם להוסיף או להסיר מופעים מקבוצת MIG באופן אוטומטי בהתבסס על עליות או ירידות בעומס. התכונה 'שינוי קנה מידה אוטומטי' עוזרת לאפליקציות לטפל בצורה חלקה בעלייה בתנועה, ומפחיתה את העלויות כשאין צורך במשאבים רבים. אתם רק מגדירים את מדיניות ההתאמה האוטומטית לעומס, והמידרוג האוטומטי מבצע התאמה אוטומטית לעומס על סמך העומס שנמדד.

4. לוחצים על יצירה.

עכשיו חוזרים על אותה הפרוצדורה כדי ליצור קבוצת מופעים שנייה בשם europe-west1-mig באזור europe-west1:

1. לוחצים על יצירת קבוצת מופעים.
2. מגדירים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
שם	europe-west1-mig
מיקום	כמה תחומים
אזור	europe-west1
תבנית של הגדרות מכונה	europe-west1-template
שינוי קנה מידה אוטומטי > מדיניות שינוי קנה מידה אוטומטי > לוחצים על סמל העיפרון > סוג המדד	ניצול יחידת העיבוד המרכזית (CPU)
ניצול יעד של יחידת העיבוד המרכזית (CPU)	‫80, לוחצים על סיום.
תקופת צינון	45
מספר המופעים המינימלי	1
מספר המופעים המקסימלי	5

3. לוחצים על יצירה.

5. הגדרת מאזן עומסים מסוג HTTP

מגדירים את מאזן העומסים מסוג HTTP לאיזון תעבורת נתונים בין שני השרתים העורפיים (us-east1-mig ב-us-east1 ו-europe-west1-mig ב-europe-west1), כפי שמוצג בדיאגרמה של הרשת:

התחלת ההגדרה

1. ב-Cloud Console, לוחצים על תפריט הניווט ( ) > Network Services > Load balancing, ואז לוחצים על Create load balancer.
2. בקטע HTTP(S) Load Balancing, לוחצים על Start configuration.

3. בוחרים באפשרות From Internet to my VMs, ‏ Classic HTTP(S) Load Balancer ולוחצים על Continue.
4. מגדירים את Name לערך http-lb.

הגדרת הקצה העורפי

שירותי קצה עורפי מפנים תנועה נכנסת לקצה עורפי אחד או יותר שמצורפים אליהם. כל קצה עורפי מורכב מקבוצת מכונות וממטא-נתונים נוספים של קיבולת ההגשה.

1. לוחצים על Backend configuration.
2. בקטע שירותי קצה עורפי וקטגוריות קצה עורפי לוחצים על יצירת שירות קצה עורפי.
3. מגדירים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (בוחרים אפשרות כמפורט)
שם	http-backend
קבוצת מופעים	us-east1-mig
לנייד מספרים	80
מצב איזון	דירוג
בקשות מקסימליות לשנייה	‫50 (לכל מופע)
קיבולת	100

ההגדרה הזו אומרת שמאזן העומסים מנסה לשמור על כל מופע של us-east1-mig ברמה של 50 בקשות לשנייה (RPS) או פחות.

4. לוחצים על סיום.
5. לוחצים על הוספת קצה עורפי.
6. מגדירים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (בוחרים אפשרות כמפורט)
קבוצת מופעים	europe-west1-mig
לנייד מספרים	80
מצב איזון	ניצול
ניצול מקסימלי של ה-Backend	80
קיבולת	100

ההגדרה הזו אומרת שמאזן העומסים ינסה לשמור על ניצול של 80% או פחות של יחידת העיבוד המרכזית (CPU) בכל מופע של europe-west1-mig.

7. לוחצים על סיום.
8. בקטע Health Check, בוחרים באפשרות Create a health check.

9. מגדירים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (בוחרים אפשרות כמפורט)
שם	http-health-check
פרוטוקול	TCP
יציאה	80

בדיקות התקינות קובעות אילו מופעים יקבלו חיבורים חדשים. בבדיקת תקינות HTTP הזו, המערכת שולחת בקשות למופעים כל 5 שניות, מחכה עד 5 שניות לתשובה, ומתייחסת ל-2 ניסיונות מוצלחים או ל-2 ניסיונות שנכשלו כאל מופעים תקינים או לא תקינים, בהתאמה.

10. לוחצים על שמירה.
11. מסמנים את התיבה הפעלת רישום ביומן.
12. מגדירים את Sample Rate (שיעור הדגימה) ל-1:

13. לוחצים על Create כדי ליצור את שירות לקצה העורפי.

הגדרת הקצה הקדמי

כללי המארח והנתיב קובעים איך התנועה תנותב. לדוגמה, אפשר להפנות תנועה של סרטונים לעורף אחד ותנועה סטטית לעורף אחר. עם זאת, בשיעור ה-Lab הזה לא מגדירים את הכללים של המארח והנתיב.

1. לוחצים על Frontend configuration.
2. מציינים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
פרוטוקול	HTTP
גרסת ה-IP	IPv4
כתובת IP	זמנית
יציאה	80

3. לוחצים על סיום.
4. לוחצים על Add Frontend IP and port.
5. מציינים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
פרוטוקול	HTTP
גרסת ה-IP	IPv6
כתובת IP	זמנית
יציאה	80

6. לוחצים על סיום.

איזון עומסים של HTTP(S) תומך בכתובות IPv4 וגם בכתובות IPv6 לתנועת לקוחות. בקשות IPv6 של לקוחות מסתיימות בשכבת איזון העומסים הגלובלית, ואז מועברות דרך IPv4 אל השרתים העורפיים.

בדיקה ויצירה של מאזן עומסים מסוג HTTP

1. לוחצים על בדיקה וסיום.

2. בודקים את שירותי הקצה העורפי והקצה הקדמי.

3. לוחצים על Create.
4. ממתינים ליצירת מאזן העומסים.
5. לוחצים על השם של מאזן העומסים (http-lb).
6. שימו לב לכתובות IPv4 ו-IPv6 של איזון העומסים לקראת המשימה הבאה. נתייחס אליהן בתור [LB_IP_v4] ו-[LB_IP_v6], בהתאמה.

6. בדיקת מאזן העומסים (LB) מסוג HTTP

אחרי שיוצרים את מאזן העומסים ב-HTTP עבור הקצה העורפי, צריך לוודא שהתנועה מועברת לשירות הקצה העורפי.

גישה למאזן עומסים מסוג HTTP

כדי לבדוק את הגישה ל-IPv4 של מאזן העומסים HTTP, פותחים כרטיסייה חדשה בדפדפן ועוברים אל http://[LB_IP_v4]. חשוב להקפיד להחליף את [LB_IP_v4] בכתובת ה-IPv4 של מאזן העומסים.

יכול להיות שיחלפו עד 5 דקות עד שתהיה לכם גישה למאזן העומסים של HTTP. בינתיים, יכול להיות שתקבלו שגיאה 404 או 502. ממשיכים לנסות עד שמוצג הדף של אחד מהעורפים.

בהתאם למיקום שלכם ביחס ל-us-east1 ול-europe-west1, התנועה מועברת למופע us-east1-mig או למופע europe-west1-mig.

אם יש לכם כתובת IPv6 מקומית, נסו את כתובת ה-IPv6 של מאזן העומסים של HTTP על ידי מעבר לכתובת http://[LB_IP_v6]. חשוב להקפיד להחליף את [LB_IP_v6] בכתובת ה-IPv6 של מאזן העומסים.

שם המארח ומיקום השרת מזהים את ה-backend שמקבל את הבקשה ממאזן העומסים של HTTP.

בדיקת מאמץ של מאזן העומסים מסוג HTTP

יוצרים מכונה וירטואלית חדשה כדי לדמות עומס על מאזן העומסים של HTTP באמצעות siege. לאחר מכן, בודקים אם התנועה מאוזנת בשני השרתים העורפיים כשהעומס גבוה.

1. במסוף, מנווטים אל תפריט הניווט ( ) > Compute Engine > VM instances.
2. לוחצים על Create instance.
3. מגדירים את הערכים הבאים ומשאירים את הערכים האחרים בברירת המחדל:

נכס	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
שם	siege-vm
אזור	us-west1
תחום (zone)	us-west1-c
סדרה	N1

בהתחשב בכך שהאזור us-west1 קרוב יותר לאזור us-east1 מאשר לאזור europe-west1, התנועה צריכה להיות מועברת רק לאזור us-east1-mig (אלא אם העומס גבוה מדי).

4. לוחצים על יצירה.
5. ממתינים ליצירת המופע siege-vm.
6. בשורה siege-vm, לוחצים על SSH כדי להפעיל טרמינל ולהתחבר.
7. כדי להתקין את siege, מריצים את הפקודה הבאה:

sudo apt-get -y install siege

8. כדי לאחסן את כתובת ה-IPv4 של מאזן העומסים של HTTP במשתנה סביבה, מריצים את הפקודה הבאה ומחליפים את [LB_IP_v4] בכתובת ה-IPv4:

export LB_IP=[LB_IP_v4]

9. כדי לדמות עומס, מריצים את הפקודה הבאה:

siege -c 250 http://$LB_IP

הפלט אמור להיראות כך (אל תעתיקו, זהו פלט לדוגמה):

New configuration template added to /home/student/.siege
Run siege -C to view the current settings in that file
** SIEGE 4.0.4
** Preparing 250 concurrent users for battle.
The server is now under siege...

10. ב-Cloud Console, לוחצים על תפריט הניווט (), לוחצים על Network Services (שירותי רשת) > Load balancing (איזון עומסים).
11. לוחצים על http-lb.
12. לוחצים על הכרטיסייה מעקב. עוקבים אחרי התנועה בין צפון אמריקה לבין שני השרתים העורפיים במשך 2 עד 3 דקות.

בהתחלה, התנועה תופנה רק אל us-east1-mig, אבל ככל שערך ה-RPS יעלה, התנועה תופנה גם אל europe-west1-mig.​​

אפשר לראות שכברירת מחדל, התנועה מועברת לחלק האחורי הקרוב ביותר, אבל אם העומס גבוה מאוד, התנועה יכולה להתחלק בין החלקים האחוריים.

13. חוזרים לטרמינל SSH של siege-vm.
14. מקישים על CTRL+C כדי להפסיק את siege.

7. יצירת מדיניות להגבלת קצב של יצירת בקשות ב-Cloud Armor

בקטע הזה נשתמש ב-Cloud Armor כדי למנוע מ-siege-vm לגשת למאזן העומסים של HTTP על ידי הגדרת מדיניות להגבלת קצב.

1. ב-Cloud Shell(הוראות לשימוש ב-Cloud Shell מופיעות בקטע הגדרה ודרישות במאמר הפעלת Cloud Shell), יוצרים מדיניות אבטחה באמצעות gcloud:

gcloud compute security-policies create rate-limit-siege \
    --description "policy for rate limiting"

2. לאחר מכן, מוסיפים כלל להגבלת קצב הבקשות:

gcloud beta compute security-policies rules create 100 \
    --security-policy=rate-limit-siege     \
    --expression="true" \
    --action=rate-based-ban                   \
    --rate-limit-threshold-count=50           \
    --rate-limit-threshold-interval-sec=120   \
    --ban-duration-sec=300           \
    --conform-action=allow           \
    --exceed-action=deny-404         \
    --enforce-on-key=IP

3. מצרפים את מדיניות האבטחה לשירות הקצה העורפי http-backend:

gcloud compute backend-services update http-backend \
    --security-policy rate-limit-siege –-global

4. במסוף, מנווטים אל תפריט הניווט > Network Security > Cloud Armor.
5. לוחצים על rate-limit-siege. המדיניות שלכם צריכה להיראות כך:

אימות מדיניות האבטחה

1. חוזרים לטרמינל ה-SSH של siege-vm.
2. מריצים curl מול כתובת ה-IP של איזון העומסים כדי לוודא שעדיין אפשר להתחבר אליו. אמורה להתקבל תגובה 200.

curl http://$LB_IP

3. בטרמינל SSH של siege-vm, כדי לדמות עומס, מריצים את הפקודה הבאה:

siege -c 250 http://$LB_IP

הפלט אמור להיראות כך (אל תעתיקו, זהו פלט לדוגמה):

** SIEGE 4.0.4
** Preparing 250 concurrent users for battle.
The server is now under siege...

4. כדאי לעיין ביומני הרישום של מדיניות האבטחה כדי לראות אם התנועה הזו נחסמת גם כן.
5. במסוף, מנווטים אל תפריט הניווט > אבטחת רשת > Cloud Armor.
6. לוחצים על rate-limit-siege.
7. לוחצים על יומנים.

8. לוחצים על הצגת יומני מדיניות.
9. בדף 'רישום ביומן', מוודאים שמנקים את כל הטקסט בתצוגה המקדימה של השאילתה.
10. בוחרים את המשאב Cloud HTTP Load Balancer > http-lb-forwarding-rule > http-lb ואז לוחצים על Add. לחלופין, אפשר להעתיק ולהדביק את שאילתת MQL(שפת שאילתות לניטור) הבאה בעורך השאילתות:

resource.type="http_load_balancer" resource.labels.forwarding_rule_name="http-lb-forwarding-rule" resource.labels.url_map_name="http-lb"

11. לוחצים על Run Query.
12. מרחיבים רשומה ביומן בתוצאות השאילתה.
13. מרחיבים את httpRequest. הבקשה צריכה להגיע מכתובת ה-IP של siege-vm. אם לא, מרחיבים רשומה אחרת ביומן.
14. מרחיבים את jsonPayload.
15. מרחיבים את enforcedSecurityPolicy.

שימו לב שהערך של configuredAction מוגדר ל-RATE_BASED_BAN עם השם rate-limit-siege.

מדיניות האבטחה של Cloud Armor יוצרת יומנים שאפשר לבדוק כדי לדעת מתי תעבורת נתונים נדחית ומתי היא מורשית, וגם מהו המקור של תעבורת הנתונים.

16. כדי לבצע בדיקה נוספת, בתפריט הניווט ( ), לוחצים על Network Services (שירותי רשת) > Load balancing (איזון עומסים). לוחצים על http-lb ואז על הכרטיסייה Monitoring.

אפשר לראות את התנועה של המצור בתרשימים. תשימו לב גם שהתנועה המוגבלת לא מגיעה לקצה העורפי ונחסמת על ידי מדיניות Cloud Armor.

מזל טוב! סיימתם את שיעור ה-Lab בנושא הגבלת קצב של יצירת בקשות באמצעות Cloud Armor

‫©2020 Google LLC כל הזכויות שמורות. Google והלוגו של Google הם סימנים מסחריים רשומים של Google LLC. כל שמות החברות והמוצרים האחרים עשויים להיות סימנים מסחריים של החברות שאליהן הם קשורים.

8. ניקוי המעבדה

1. עוברים אל Network Security >> Cloud Armor >> %POLICY NAME% ובוחרים באפשרות delete (מחיקה) –

2. עוברים אל Networking >> Network services >> Load Balancing (רשת >> שירותי רשת >> איזון עומסים). בוחרים את מאזן העומסים שיצרתם ולוחצים על 'מחיקה'.

בוחרים את שירות לקצה העורפי ואת בדיקת תקינות כמשאבים נוספים למחיקה –

3. מנווטים אל תפריט הניווט ( ) > Compute Engine > Instance Groups. בוחרים את שתי קבוצות המכונות המנוהלות ולוחצים על Delete (מחיקה) –

כדי לאשר את המחיקה, מקלידים delete בתיבת הטקסט.

מחכים שמחיקת קבוצות המכונות המנוהלות תושלם. הפעולה הזו מוחקת גם את המופעים בקבוצה. אפשר למחוק את התבניות רק אחרי שמוחקים את קבוצת המכונות.

4. בחלונית הימנית, עוברים אל Instance templates (תבניות של מכונות וירטואליות)**.** בוחרים את שתי תבניות המופעים ולוחצים על 'מחיקה' –

5. בחלונית הימנית, עוברים אל VM instances (מופעי מכונות וירטואליות). לוחצים על סמל האליפסה לצד מופע siege-vm ולוחצים על סמל המחיקה.

6. עוברים אל תפריט הניווט ( ) > רשת VPC ‏ > חומת אש. בוחרים באפשרות default-allow-health-check ולוחצים על סמל המחיקה.

9. מעולה!

הטמעתם בהצלחה הגבלת קצב של יצירת בקשות באמצעות Cloud Armor. הגדרתם מאזן עומסים מסוג HTTP עם קצה עורפי באזורים us-east1 ו-europe-west1. לאחר מכן, ביצעתם בדיקת עומס על מאזן העומסים באמצעות מכונה וירטואלית והסרתם את כתובת ה-IP מרשימת החסימה באמצעות הגבלת קצב יצירת הבקשות באמצעות Cloud Armor. יכולתם לעיין ביומני מדיניות האבטחה כדי לזהות למה התנועה נחסמה.

מה נכלל

• איך מגדירים תבניות של מכונות ויוצרים קבוצות של מופעי מכונה מנוהלים.
• איך מגדירים מאזן עומסים (LB) מסוג HTTP.
• איך יוצרים מדיניות להגבלת קצב יצירת בקשות ב-Cloud Armor.
• איך מוודאים שהמדיניות בנושא הגבלת קצב הבקשות פועלת כמצופה.

השלבים הבאים

• כדאי לנסות להגדיר מדיניות להגבלת קצב הבקשות על סמך טווח כתובות IP של מקור. דוגמה לפקודה –

gcloud alpha compute security-policies rules create 105 \
    --security-policy sec-policy     \
    --src-ip-ranges "1.2.3.0/24"     \
    --action throttle                \
    --rate-limit-threshold-count 100 \
    --rate-limit-threshold-interval-sec 60 \
    --conform-action allow           \
    --exceed-action deny-429         \
    --enforce-on-key IP

• אפשר לנסות להגדיר מדיניות להגבלת קצב הבקשות על סמך קוד אזור. דוגמה לפקודה –

gcloud alpha compute security-policies rules create 101 \
    --security-policy sec-policy     \
    --expression "origin.region_code == 'US'" \
    --action rate-based-ban                 \
    --rate-limit-threshold-count 10         \
    --rate-limit-threshold-interval-sec 60  \
    --ban-duration-sec 300           \
    --ban-threshold-count 1000       \
    --ban-threshold-interval-sec 600 \
    --conform-action allow           \
    --exceed-action deny-403         \
    --enforce-on-key IP