כללים לחומת אש שנוצרו באופן אוטומטי

בדף הזה מוסבר על כללי חומת האש של VPC שמאפשרים תעבורת נתונים נכנסת (ingress), ש-Google Kubernetes Engine ‏(GKE) יוצר באופן אוטומטי כברירת מחדל ב- Google Cloud.

חומות אש רלוונטיות וחומות אש לתעבורת נתונים יוצאת

ב-GKE נעשה שימוש בכללי חומת אש של ענן וירטואלי פרטי (VPC) כדי לשלוט בתעבורה הנכנסת והיוצאת אל הפודים והצמתים. כברירת מחדל, GKE יוצר ומנהל באופן אוטומטי כללים מסוימים של חומת אש כדי לאפשר תעבורה חיונית, כמו תקשורת בין צמתים ו-Pods, ותעבורה למישור הבקרה של Kubernetes. ‫GKE יוצר באופן אוטומטי כללי חומת אש של VPC לגישה (ingress) לשירותי LoadBalancer כברירת מחדל, אבל אתם יכולים להשבית את ההתנהגות הזו כדי לנהל כללי חומת אש או מדיניות באופן ידני, או כדי להשתמש בתכונות מתקדמות של חומת האש.

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

שיטה מומלצת:

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

‫GKE יוצר רק כללים של חומת אש של VPC לתעבורת נתונים נכנסת (ingress), כי הוא מסתמך על כלל חומת האש המשתמעת לתעבורת נתונים יוצאת (egress) עם העדיפות הכי נמוכה.

אם הגדרתם כללי חומת אש שחוסמים תעבורת נתונים יוצאת ברשת ה-VPC של האשכול, יכול להיות שתצטרכו ליצור כללים שמאפשרים תעבורת נתונים יוצאת כדי לאפשר תקשורת בין הצמתים, ה-Pods ומישור הבקרה של האשכול. לדוגמה, אם יצרתם כלל חומת אש שחוסם תעבורת נתונים יוצאת (egress) לכל הפרוטוקולים והיציאות ולכל כתובות ה-IP של היעד, אתם צריכים ליצור כללי חומת אש שמאפשרים תעבורת נתונים יוצאת (egress), בנוסף לכללי תעבורת הנתונים הנכנסת (ingress) ש-GKE יוצר באופן אוטומטי. הקישוריות לנקודות הקצה של מישור הבקרה תמיד משתמשת ביציאת היעד TCP 443, אבל הקישוריות בין הצמתים וה-Pods של האשכול יכולה להשתמש בכל פרוטוקול ויציאת יעד.

הכלים הבאים יכולים לעזור לכם לקבוע אילו כללים של חומת האש מאפשרים או חוסמים תעבורה:

כללי חומת אש

כברירת מחדל, GKE יוצר כללים לחומת האש באופן אוטומטי כשיוצרים את המשאבים הבאים:

  • אשכולות GKE
  • שירותי GKE
  • שערי GKE ו-HTTPRoutes
  • GKE Ingresses

אלא אם צוין אחרת, העדיפות של כל כללי חומת האש שנוצרו באופן אוטומטי היא 1,000, שהוא ערך ברירת המחדל של כללי חומת האש. אם אתם רוצים יותר שליטה בהתנהגות של חומת האש, אתם יכולים ליצור כללים לחומת האש עם עדיפות גבוהה יותר. כללי חומת אש עם עדיפות גבוהה יותר מוחלים לפני כללי חומת אש שנוצרו אוטומטית.

כללי חומת אש באשכול GKE

כשיוצרים אשכול, GKE יוצר את הכללים הבאים של חומת האש לתעבורת נתונים נכנסת (ingress):

שם מטרה מקור יעד (מגדיר את היעד) פרוטוקול ויציאות עדיפות
gke-[cluster-name]-[cluster-hash]-master עבור אשכולות Autopilot ואשכולות רגילים שמסתמכים על קישוריות לרשת VPC שכנה לקישוריות של נקודת קצה פרטית של מישור הבקרה. מאפשר למישור הבקרה לגשת ל-kubelet ול-metrics-server בצמתי האשכול. טווח כתובות IP של מישור הבקרה (/28) תג צומת ‫TCP: ‏ 443 (metrics-server) ו-TCP: ‏ 10250 (kubelet) 1000
gke-[cluster-name]-[cluster-hash]-vms

משמש לתקשורת בתוך האשכול שנדרשת על ידי מודל הרישות של Kubernetes. מאפשר לתוכנה שפועלת בצמתים לשלוח מנות, עם מקורות שתואמים לכתובות ה-IP של הצמתים, לכתובות ה-IP של היעד של ה-Pod ושל הצומת באשכול. לדוגמה, תנועה שמותרת על ידי הכלל הזה כוללת:

  • חבילות שנשלחות מ-daemons של המערכת, כמו kubelet, ליעדים של כתובות IP של צמתים ו-Pods באשכול.
  • חבילות שנשלחות מתוכנה שפועלת ב-Pods עם hostNetwork:true ליעדים של כתובות IP של צמתים ו-Pods באשכול.
טווח כתובות ה-IP של הצומת או קבוצת-על של טווח כתובות ה-IP של הצומת: ‫GKE לא מעדכן את טווח כתובות ה-IPv4 של המקור של כלל חומת האש הזה אם מרחיבים את טווח כתובות ה-IPv4 הראשי של רשת המשנה של האשכול. אם מרחיבים את טווח ה-IPv4 הראשי של רשת המשנה של האשכול, צריך ליצור ידנית את כלל חומת האש הנדרש לכניסת תנועה. תג צומת ‫TCP: 1-65535, ‏ UDP: 1-65535, ‏ ICMP 1000
gke-[cluster-name]-[cluster-hash]-all מאפשר תעבורת נתונים בין כל קבוצות ה-Pod באשכול, כנדרש על ידי מודל הרשת של Kubernetes.

Pod CIDR

באשכולות שמופעל בהם CIDR של כמה Pods לא רציפים, כל בלוקי ה-CIDR של ה-Pods שבהם נעשה שימוש באשכול.

תג צומת TCP, ‏ UDP, ‏ SCTP, ‏ ICMP, ‏ ESP, ‏ AH 1000
gke-[cluster-hash]-ipv6-all רק לאשכולות של רשתות עם פרוטוקול כפול. מאפשרת תעבורת נתונים בין צמתים ו-Pods באשכול.

אותו טווח כתובות IP שהוקצה ב-subnetIpv6CidrBlock.

תג צומת ‫TCP, ‏ UDP, ‏ SCTP, ‏ ICMP ל-IPv6, ‏ ESP, ‏ AH 1000
gke-[cluster-name]-[cluster-hash]-inkubelet מתן גישה ליציאה 10255 (יציאה לקריאה בלבד של Kubelet) מ-CIDR של Pod פנימיים ומ-CIDR של צמתים באשכולות GKE חדשים שמריצים גרסה 1.23.6 ואילך. באשכולות שפועלות בהם גרסאות מתקדמות יותר מ-1.26.4-gke.500, נעשה שימוש ביציאה מאומתת של Kubelet ‏ (10250) במקום זאת. אל תוסיפו כללים לחומת האש שחוסמים את 10250 באשכול.

חסימות CIDR של Pod פנימיות וחסימות CIDR של צמתים.

תג צומת ‫TCP: 10255 999
gke-[cluster-name]-[cluster-hash]-exkubelet דחיית גישה ציבורית ליציאה 10255 באשכולות GKE חדשים שמריצים גרסה 1.23.6 ואילך.

0.0.0.0/0

תג צומת ‫TCP: 10255 1000

כללי חומת אש של שירות GKE

מערכת GKE יוצרת את כללי חומת האש הבאים של Ingress כשיוצרים שירות. כדי למנוע יצירה של חלק מהכללים האלה של חומת האש, אתם יכולים לנהל את היצירה של כללים של חומת האש ב-VPC.

שם מטרה מקור יעד (מגדיר את היעד) פרוטוקול ויציאות
k8s-fw-[loadbalancer-hash] מאפשרת לתעבורת נתונים נכנסת (ingress) להגיע לשירות. מקור התוצאה: spec.loadBalancerSourceRanges. אם לא מציינים ערך לפרמטר spec.loadBalancerSourceRanges, ערך ברירת המחדל הוא 0.0.0.0/0.

פרטים נוספים זמינים במאמר בנושא כללים של חומת אש ורשימת היתרים של כתובות IP של מקורות.

 כתובת IP וירטואלית של איזון עומסים ‫TCP ו-UDP ביציאות שצוינו במניפסט השירות.
k8s-[cluster-id]-node-http-hc מאפשר בדיקות תקינות של שירות מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי, כשערך המאפיין externalTrafficPolicy מוגדר ל-Cluster.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
 כתובת IP וירטואלית של איזון עומסים TCP: 10256
k8s-[loadbalancer-hash]-http-hc מאפשר בדיקות תקינות של שירות מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי, כשערך המאפיין externalTrafficPolicy מוגדר ל-Local.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
 תג צומת יציאת TCP שמוגדרת על ידי spec.healthCheckNodePort. אם לא מציינים יציאה, מישור הבקרה של Kubernetes מקצה יציאה לבדיקת תקינות מטווח היציאות של הצומת.

פרטים נוספים זמינים במאמר בנושא יציאה לבדיקת תקינות.
k8s-[cluster-id]-node-hc מאפשרת בדיקות תקינות של שירות מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, כש-externalTrafficPolicy מוגדר כ-Cluster.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
 תג צומת TCP: 10256
[loadbalancer-hash]-hc מאפשר בדיקות תקינות של שירות מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, כש-externalTrafficPolicy מוגדר ל-Local.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
 תג צומת יציאת TCP שמוגדרת על ידי spec.healthCheckNodePort. אם לא מציינים יציאה, מישור הבקרה של Kubernetes מקצה יציאה לבדיקת תקינות מטווח היציאות של הצומת.

פרטים נוספים זמינים במאמר בנושא יציאה לבדיקת תקינות.
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] מאפשרת לתעבורת נתונים נכנסת (ingress) להגיע לשירות כשאחת מהאפשרויות הבאות מופעלת:
  • GKE subsetting.
  • מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי.
  • אפשר להשבית את היצירה האוטומטית של כללי חומת האש האלה ב-VPC. מידע נוסף זמין במאמר ניהול יצירה אוטומטית של כללים של חומת אש.
    		•  מקור התוצאה: spec.loadBalancerSourceRanges. אם לא מציינים ערך לפרמטר spec.loadBalancerSourceRanges, ערך ברירת המחדל הוא 0.0.0.0/0.

    פרטים נוספים זמינים במאמר בנושא כללים של חומת אש ורשימת היתרים של כתובות IP של מקורות.

    		 כתובת IP וירטואלית של איזון עומסים ‫TCP ו-UDP ביציאות שצוינו במניפסט השירות.
    k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw מאפשר בדיקות תקינות של השירות כשהערך של externalTrafficPolicy הוא Local ואחת מההגדרות הבאות מופעלת:
  • GKE subsetting.
  • מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי.
    		•
    • 35.191.0.0/16
    • 130.211.0.0/22
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 כתובת IP וירטואלית של איזון עומסים יציאת TCP שמוגדרת על ידי spec.healthCheckNodePort. אם לא מציינים יציאה, מישור הבקרה של Kubernetes מקצה יציאה לבדיקת תקינות מטווח היציאות של הצומת.

    פרטים נוספים זמינים במאמר בנושא יציאה לבדיקת תקינות.
    k8s2-[cluster-id]-l4-shared-hc-fw מאפשר בדיקות תקינות של השירות כשהערך של externalTrafficPolicy הוא Cluster ואחת מההגדרות הבאות מופעלת:
  • GKE subsetting.
  • מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שמבוסס על שירות לקצה העורפי.
    		•
    • 35.191.0.0/16
    • 130.211.0.0/22
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 תג צומת TCP: 10256
    gke-[cluster-name]-[cluster-hash]-mcsd מאפשר למישור הבקרה לגשת ל-kubelet ול-metrics-server בצמתי האשכול עבור שירותים מרובי-אשכולות. העדיפות של הכלל הזה היא 900. כתובות IP של בדיקות תקינות תג צומת TCP, ‏ UDP, ‏ SCTP, ‏ ICMP, ‏ ESP, ‏ AH

    כללי חומת אש של GKE Gateway

    מערכת GKE יוצרת את הכללים הבאים של חומת האש של שערים כשיוצרים משאבי Gateway ו-HTTPRoute:

    שם מטרה מקור יעד (מגדיר את היעד) פרוטוקול ויציאות
    • gkegw1-l7-[network]-[region/global]
    • gkemcg1-l7-[network]-[region/global]

    מאפשרת בדיקות תקינות של קבוצת נקודות קצה ברשת (NEG).

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

    		תג צומת ‫TCP: כל יציאות היעד של מאגרי התגים (ל-NEG)

    כללי חומת אש של GKE Ingress

    מערכת GKE יוצרת את הכללים הבאים של חומת האש של Ingress כשיוצרים משאב Ingress:

    שם מטרה מקור יעד (מגדיר את היעד) פרוטוקול ויציאות
    k8s-fw-l7-[random-hash]

    מאפשרת בדיקות תקינות של שירות NodePort או של קבוצה של נקודות קצה ברשת (NEG).

    ה-controller של Ingress יוצר את הכלל הזה כשיוצרים את משאב ה-Ingress הראשון. בקר Ingress יכול לעדכן את הכלל הזה אם נוצרים עוד משאבי Ingress.

    		ב-GKE גרסה v1.17.13-gke.2600 ואילך:
    • 35.191.0.0/16
    • 130.211.0.0/22
    • טווחים של רשתות משנה לשרת proxy בלבד שהוגדרו על ידי המשתמש (למאזני עומסים פנימיים של אפליקציות)
    		 תג צומת ‫TCP: 30000-32767, ‏ TCP:80 (למאזני עומסים פנימיים של אפליקציות), ‫ TCP: כל יציאות היעד של מאגרי התגים (ל-NEGs)

    ניהול יצירה של כללים לחומת אש ב-VPC

    כברירת מחדל, GKE יוצר באופן אוטומטי כללי חומת אש של VPC המאפשרים Ingress לכל שירותי LoadBalancer. אם אתם רוצים לנהל בעצמכם את כללי חומת האש של שירותי LoadBalancer, אתם צריכים להשבית את היצירה האוטומטית של כללי חומת אש של VPC.

    השבתת היצירה האוטומטית של כללי חומת אש של VPC עבור LoadBalancerServices חלה רק על המקרים הבאים:

    מידע על השבתת כללים של חומת אש זמין במאמר כללים של חומת אש בניהול המשתמש בשירותי LoadBalancer של GKE.

    VPC משותף

    אם אתם משתמשים בשירותי Ingress או LoadBalancer, ויש לכם אשכול שנמצא ב-VPC משותף באמצעות רשת VPC משותפת, חשבון השירות של GKE בפרויקט השירות לא יכול ליצור ולעדכן כללי חומת אש של Ingress בפרויקט המארח. אתם יכולים להעניק לחשבון השירות של GKE בפרויקט שירות הרשאות ליצור ולנהל את משאבי חומת האש. מידע נוסף זמין במאמר בנושא VPC משותף.

    כלל חומת אש שנדרש לתת-רשת מורחבת

    אם מרחיבים את טווח ה-IPv4 הראשי של רשת המשנה של האשכול,‏ GKE לא מעדכן אוטומטית את טווח המקור של כלל חומת האש gke-[cluster-name]-[cluster-hash]-vms. מכיוון שהצמתים באשכול יכולים לקבל כתובות IPv4 מהחלק המורחב של טווח ה-IPv4 הראשי של רשת המשנה, צריך ליצור ידנית כלל חומת אש כדי לאפשר תקשורת בין הצמתים באשכול.

    כלל חומת האש לתעבורת נתונים נכנסת שצריך ליצור חייב לאפשר חבילות TCP ו-ICMP מטווח כתובות ה-IPv4 המורחב של רשת המשנה הראשית, והוא חייב לחול לפחות על כל הצמתים באשכול.

    כדי ליצור כלל לחומת אש של תעבורת נתונים נכנסת (ingress) שחל רק על הצמתים של האשכול, צריך להגדיר את היעד של כלל חומת האש לאותו תג יעד שבו נעשה שימוש בgke-[cluster-name]-[cluster-hash]-vmsכלל חומת האש שנוצר אוטומטית של האשכול.

    המאמרים הבאים