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

1. מבוא

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

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

בשיעור ה-Lab הזה תגדירו מאזן עומסים 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 > Instance templates (תבניות של הגדרות מכונה), ואז לוחצים על Create instance template (יצירת תבנית של הגדרות מכונה).
2. בשדה Name (שם), מקלידים us-east1-template.
3. בקטע Series (סדרה), בוחרים באפשרות N1.
4. לוחצים על Networking, Disks, Security, Management , Sole-Tenancy.

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

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

Key	ערך
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, לוחצים על קבוצות של מכונות וירטואליות בתפריט הימני.

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

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

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

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
מצב איזון	דירוג
RPS מקסימלי	‫50 (לכל מופע)
קיבולת	100

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

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

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

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

7. לוחצים על סיום.
8. בקטע בדיקת תקינות, בוחרים באפשרות יצירת בדיקת תקינות.

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. בדיקת מאזן העומסים ב-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. ב-Console, מנווטים אל תפריט הניווט ( ) > 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. לוחצים על הכרטיסייה Monitoring (מעקב). עוקבים אחרי התנועה בין צפון אמריקה לבין שני השרתים העורפיים במשך 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 ‏ > חומת אש. בוחרים את ברירת המחדל של בדיקת תקינות ההרשאה ולוחצים על סמל המחיקה.

9. מעולה!

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

מה נכלל

• איך מגדירים תבניות של מכונות ויוצרים קבוצות של מופעי מכונה מנוהלים.
• איך מגדירים מאזן עומסים מסוג 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