סוכן להסתרת IP

בדף הזה מוסבר איך פועל מיסוך כתובות IP ב-Google Kubernetes Engine ‏ (GKE), ומוצגות אפשרויות הגדרה לתרחישים שונים.

ההנחה בדף הזה היא שאתם מכירים את המושג הסתרת IP ב-Kubernetes.

הסתרת IP ב-GKE

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

בצמתים של Linux, ‏GKE מגדיר כללי iptables. ‫GKE משתמש ב-ip-masq-agent DaemonSet כדי להגדיר את מישור הנתונים המתאים.

‫ip-masq-agent לא נתמך במאגרי צמתים של Windows Server. עם זאת, צמתים של Windows מבצעים הסוואת כתובת IP (תרגום כתובת רשת של המקור או SNAT) למנות שנשלחות ליעדים חיצוניים לאשכול, על ידי כתיבה מחדש של כתובת ה-IP של ה-Pod המקורית לכתובת ה-IP של הצומת. המערכת מדלגת על SNAT בחבילות שנשלחות לכתובות IP של Pod או של צומת באותו אשכול. אי אפשר לשנות את ההתנהגות הזו בצומתי Windows.

הסתרת IP באשכולות רגילים

בקטריים רגילים, ההתנהגות של הסתרת כתובות ה-IP של האשכול נקבעת על ידי שלושה גורמים:

בטבלה הבאה מפורטות הגדרות הסתרת ה-IP באשכולות GKE רגילים:

הגדרת האשכול התנהגות SNAT כתוצאה מכך

‫ip-masq-agent DaemonSet קיים באשכול, וגם רשימה מותאמת אישית של nonMasqueradeCIDRs קיימת ב-ip-masq-agent ConfigMap.

‫GKE שומר את כתובות ה-IP של Pod המקור לחבילות שנשלחות ליעדים שצוינו ברשימה nonMasqueradeCIDRs.

‫GKE משנה את כתובות ה-IP של Pod המקור לכתובות ה-IP של צומת המקור, עבור חבילות שנשלחות ליעדים שלא צוינו ברשימה nonMasqueradeCIDRs.

ה-DaemonSet‏ ip-masq-agent קיים באשכול, אבל רשימת לקוחות nonMasqueradeCIDRs לא קיימת ב-ConfigMap‏ ip-masq-agent או ש-ConfigMap‏ ip-masq-agent לא קיים בכלל.

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

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

ה-DaemonSet של ip-masq-agent לא נמצא באשכול, ויצרתם את האשכול בלי הדגל --disable-default-snat.

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

‫GKE משנה את כתובות ה-IP של Pod המקור לכתובות ה-IP של צומת המקור, עבור חבילות שנשלחות ליעדים מחוץ ליעדי ברירת המחדל ללא הסוואה.

ה-DaemonSet של ip-masq-agent לא נמצא באשכול, ויצרתם את האשכול עם הדגל --disable-default-snat.

‫GKE שומר על כתובות ה-IP של פוד המקור עבור חבילות שנשלחות לכל היעדים.

במאמר שמירה על מקורות של כתובות IPv4 של Pod ליעדים באינטרנט מפורטים שיקולי ניתוב חשובים כששומרים על כתובות מקור של IPv4 של Pod וצריך לנתב חבילות לאינטרנט.

הסתרת IP באשכולות במצב Autopilot

באשכולות Autopilot, ‏GKE תמיד פורס DaemonSet של ip-masq-agent. חוץ מחבילות שנשלחות על ידי Pods לטווחים של הצומת, ה-Pod או השירותים של האשכול, אתם יכולים לשלוט בהתנהגות של הסתרת ה-IP באמצעות EgressNATPolicy. כדי להשתמש ב-EgressNATPolicy, קלאסטר Autopilot צריך לעמוד בשתי הדרישות הבאות:

  • האשכול צריך להיות מגרסה 1.23.4-gke.1600 ואילך, או מגרסה 1.22.7-gke.1500 ואילך.
  • האשכול חייב להיווצר כש-GKE Dataplane V2 מופעל.

בטבלה הבאה מפורטות הגדרות הסתרת ה-IP לאשכולות GKE במצב Autopilot:

הגדרת אשכול Autopilot התנהגות SNAT שנוצרת

האשכול כולל EgressNATPolicy מותאם אישית שערך spec.action שלו הוא NoSNAT, שמכיל יעדים שלא מוסתרים ומפורטים ב-spec.destinations[].

‫GKE שומר על כתובות ה-IP של המקור של ה-Pod עבור חבילות שנשלחות ליעדים שצוינו ב-spec.destinations[] של EgressNATPolicy. כדי לעשות את זה, GKE מתרגם את spec.destinations[] לרשימה של nonMasqueradeCIDRs ב-configMap של ip-masq-agent.

‫GKE משנה את כתובות ה-IP של Pod המקור לכתובות ה-IP של צומת המקור, בשביל חבילות שנשלחות ליעדים שלא צוינו ב-spec.destinations[] של EgressNATPolicy.

האשכול לא כולל EgressNATPolicy מותאם אישית.

מדיניות ברירת המחדל של EgressNATPolicy והמדיניות שמנוהלת על ידי GKE חלות, והתוצאה היא ההתנהגות הבאה:

  • ‫GKE שומר על כתובות ה-IP של פוד המקור עבור חבילות שנשלחות לקבוצה של יעדים שמוגדרים כברירת מחדל ללא הסוואה.
  • ‫GKE משנה את כתובות ה-IP של Pod המקור לכתובות ה-IP של צומת המקור, עבור חבילות שנשלחות ליעדים מחוץ ליעדי ברירת המחדל ללא הסוואה.

תצורות לדוגמה

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

הסבר על ההגדרות המתקדמות

כשה-ip-masq-agent נפרס באופן אוטומטי

באשכולות במצב אוטומטי, ‏GKE תמיד פורס DaemonSet של ip-masq-agent.

באשכולות רגילים, GKE פורס DaemonSet של ip-masq-agent כשלא מגדירים את הדגל --disable-default-snat (כלומר, כשמגדירים אותו לערך לא) והאשכול משתמש באחת משילובי ההגדרות הבאים:

  • האשכול לא משתמש ב-GKE Dataplane V2, ואכיפת מדיניות הרשת מופעלת.

  • האשכול משתמש בטווח כתובות IP של Pod שלא מתאים ל-10.0.0.0/8.

כדי ש-ip-masq-agent DaemonSet יהיה יעיל, צריך גם לציין את רשימת nonMasqueradeCIDRs ב-ip-masq-agent ConfigMap. מידע נוסף מופיע במאמר בנושא איך מגדירים סוכן להסתרת כתובת IP.

כש-ip-masq-agent DaemonSet קיים באשכול, GKE מעדכן ומבצע התאמה של Pod להצגת מודעות בכל צומת באשכול.

יעדי ברירת מחדל ללא התחזות

יעדי ברירת המחדל שלא מוסתרים הם:

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4

יעדי ברירת המחדל שלא מוסתרים רלוונטיים לאשכולות עם ההגדרות הבאות:

יעדי ברירת המחדל שאינם מסוג masquerade לא רלוונטיים לאשכולות עם ההגדרות הבאות:

ההשפעה של הדגל --disable-default-snat

הדגל --disable-default-snat משנה את התנהגות ברירת המחדל של SNAT ב-GKE, כך שכתובות ה-IP של הפודים המקור יישמרו עבור מנות שנשלחות לכל היעדים. ‫GKE מטמיע את התנהגות ברירת המחדל של SNAT על ידי אי-פריסה של ip-masq-agent DaemonSet באשכול.

לדגל --disable-default-snat אין השפעה כשאשכול כולל DaemonSet של ip-masq-agent:

כדי להגדיר את הדגל --disable-default-snat, צריך לעדכן את האשכול אחרי שהוא נוצר. בתנאי שלא נפרס ip-masq-agent DaemonSet באשכול, השבתת SNAT כברירת מחדל נכנסת לתוקף אחרי שהאשכול מחליף את כל הצמתים שלו – לפעמים כמה שעות לאחר מכן. הסיבה לכך היא ש-GKE מכבד את חלונות הזמן לתחזוקה שהגדרתם כשהוא מחליף צמתים באשכול. אם לא הגדרתם חלון תחזוקה, תצטרכו להחליף את הצמתים באשכול באופן ידני לפני שהדגל --disable-default-snat ישפיע.

הסוואה של כתובת לקישור מקומי

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

באשכולות Autopilot, כתובות ה-IP של Pod המקור תמיד נשמרות בחבילות שנשלחות ליעדים של 169.254.0.0/16.

כברירת מחדל, באשכולות Standard נשמרות גם כתובות ה-IP של Pod המקור של חבילות שנשלחות ליעדים ב-169.254.0.0/16.

כדי להפעיל הסוואה של כתובות IP מקומיות בקישור באשכול רגיל, צריך לבצע את שני השלבים הבאים:

קונטיינרים ו-Pods לאבחון עם hostNetwork: true

אלא אם מציינים כתובת IP מותאמת אישית של המקור לחבילות, פודים שפועלים עם hostNetwork: true ומכלי אבחון שולחים חבילות עם מקורות שתואמים לכתובת ה-IP של הצומת. ב-Pods שפועלים עם hostNetwork: true, ‏GKE מקצה ל-Pod את כתובת ה-IP של הצומת. ‫GKE לא מנהל כתובות IP עבור קונטיינרים לאבחון, כולל קונטיינרים לניפוי באגים בבעיות בצמתים באמצעות toolbox.

באשכולות Autopilot אי אפשר להריץ Pods עם spec.hostNetwork: true. אי אפשר לגשת לצמתים של אשכול Autopilot באמצעות SSH, ולכן אי אפשר להריץ בהם קונטיינרים לאבחון.

שמירה על מקורות כתובות ה-IPv4 של ה-Pod ליעדים באינטרנט

אם הגדרתם באשכול אחת מהאפשרויות הבאות להסתרת כתובת ה-IP,‏ GKE שומר את המקורות של כתובות ה-IP של הפודים בחבילות שנשלחות לכל היעדים, כולל יעדים באינטרנט:

  • באשכולות רגילים עם DaemonSet של ip-masq-agent, אם הגדרתם את nonMasqueradeCIDRs ל-0.0.0.0 ב-ConfigMap של ip-masq-agent.
  • באשכולות רגילים בלי DaemonSet של ip-masq-agent, אם הגדרתם את הדגל --disable-default-snat.
  • באשכולות של Autopilot, אם עורכים את ברירת המחדל של EgressNATPolicy כך ש-spec.action הוא NoSNAT, ו-spec.destinations מכיל Cidr: 0.0.0.0/0.

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

  • מוודאים שברשת ה-VPC יש נתיב שמוגדר כברירת מחדל עם הצעד הבא של שער ברירת המחדל לאינטרנט, ומגדירים שער Cloud NAT כדי לספק שירותי NAT ציבוריים לפחות לטווחי כתובות ה-IPv4 המשניים של רשת המשנה שבהם משתמשים Pods באשכול. פרטים נוספים זמינים במאמר אינטראקציה עם GKE בסקירה הכללית של Cloud NAT.
  • מגדירים את רשת ה-VPC כך שתשתמש בנתיב ברירת מחדל בהתאמה אישית, שהקפיצה הבאה שלו היא מכונה וירטואלית או מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי, שבהם המכונה הווירטואלית או רכיבי ה-backend של מאזן העומסים הוגדרו לניתוב חבילות לאינטרנט בשם ה-Pods.

שחזור להתנהגות ברירת המחדל של SNAT

כדי לשחזר את התנהגות ברירת המחדל של SNAT כשיש ip-masq-agent DaemonSet באשכול, צריך למחוק את ה-ConfigMap המשויך של ip-masq-agent. ‫DaemonSet של ip-masq-agent משחזר את התנהגות ברירת המחדל של הסתרת ה-IP בצמתים שהוא מנהל.

כדי לשחזר את התנהגות ברירת המחדל של SNAT כש-DaemonSet של ip-masq-agent לא נמצא באשכול, צריך לשדרג את מאגר הצמתים (לוודא ש---disable-default-snat לא מוגדר באשכול).

השפעת מדיניות ה-NAT של יציאה באשכולות של Autopilot

מדיניות Egress NAT ב-GKE מאפשרת להגדיר הסוואת כתובות IP באשכולות Autopilot. אתם יכולים להשתמש בהגדרת משאב מותאם אישית (CRD) של מדיניות GKE Egress NAT כדי לשנות את כתובות ה-IP של המקור של מנות שנשלחות מה-Pods.

מסיבות אבטחה או בגלל מיצוי של כתובות IP, אתם יכולים להסוות כתובות IP מ-Pod לטווח כתובות IP של צומת, לתנועה יוצאת לרשתות מקומיות. לדוגמה, אתם יכולים להשתמש בטווח שאינו RFC-1918 לאשכולות Autopilot, ובטווח RFC-1918 לצמתים. עם זאת, אם הפודים צריכים לתקשר עם רשתות מקומיות שגם משתמשות בטווח שאינו RFC-1918, יכול להיות שיהיה חפיפה בין כתובות ה-IP. כדי למנוע אובדן תנועה, אפשר להגדיר מדיניות NAT ליציאה כדי לא לפרסם את טווחי ה-IP שאינם RFC-1918 של ה-Pods ברשתות מקומיות. מדיניות NAT ליציאה מסווה את טווח ה-RFC-1918 של ה-Pods כדי להשתמש בטווח ה-RFC-1918 של הצומת במקום. חשוב לוודא שטווח הצמתים לא חופף לטווח מקומי כלשהו, אחרת עלול להיווצר לולאת תנועה.

‫GKE אוכף את ההתנהגות של הסתרת כתובות IP באשכולות Autopilot באמצעות התהליך הבא:

  1. מערכת GKE פורסת את בקר ה-NAT של יציאה ואת ip-masq-agent.
  2. יוצרים את מדיניות ה-NAT ליציאה.
  3. הבקר של GKE מתרגם את המדיניות ל-ConfigMap‏ ip-masq-agent.
  4. ‫DaemonSet של ip-masq-agent קורא את ConfigMap, ואז GKE אוכף את ההתנהגות של הסתרת ה-IP.

מדיניות שנוצרת באופן אוטומטי

‫GKE תומך בשתי מדיניות NAT ליציאה שנוצרות באופן אוטומטי:

  • ברירת המחדל: אפשר לערוך את כללי המדיניות האלה.
  • מנוהל על ידי GKE: המדיניות הזו קבועה ואי אפשר לערוך אותה.

מדיניות ברירת המחדל

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

המניפסט הבא מתאר מדיניות ברירת מחדל של Egress NAT:

    Name:         default
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  networking.gke.io/v1
    Kind:         EgressNATPolicy
    Metadata:
      Creation Timestamp:  2022-03-16T21:05:45Z
      Generation:          2
      Managed Fields:
        API Version:  networking.gke.io/v1
        Fields Type:  FieldsV1
        fieldsV1:
          f:spec:
            .:
            f:action:
          f:status:
        Manager:      egress-nat-controller
        Operation:    Update
        Time:         2022-03-16T21:05:45Z
        API Version:  networking.gke.io/v1
        Fields Type:  FieldsV1
        fieldsV1:
          f:spec:
            f:destinations:
        Manager:         kubectl
        Operation:       Update
        Time:            2022-03-17T01:58:13Z
      Resource Version:  189346
      UID:               06acbb5a-23ba-4c2a-bb34-9b6ed8c4a87f
    Spec:
      Action:  NoSNAT
      Destinations:
        Cidr:  10.0.0.0/8
        Cidr:  172.16.0.0/12
        Cidr:  192.168.0.0/16
        Cidr:  240.0.0.0/4
        Cidr:  192.0.2.0/24
        Cidr:  198.51.100.0/24
        Cidr:  203.0.113.0/24
        Cidr:  100.64.0.0/10
        Cidr:  198.18.0.0/15
        Cidr:  192.0.0.0/24
        Cidr:  192.88.99.0/24
    Status:
    Events:  <none>

טווחי ה-CIDR זהים לטווחי היעד שמוגדרים כברירת מחדל ללא הסוואה.

מנוהל על ידי מדיניות GKE

מדיניות GKE Egress NAT שומרת טווח סטטי של כתובות IP שנדרש כדי לשמור על פעולת האשכול. הטווח הסטטי הזה מכיל את טווחי כתובות ה-IP של Pod,‏ Service ו-Node של האשכול, ויכול להיות שהוא חופף למדיניות ברירת המחדל.

אפשר לזהות את המדיניות הזו באמצעות גיבוב דינמי של 8 בייט (gke-{CLUSTER_SHORT_HASH}) שמוקצה על ידי GKE. אי אפשר לערוך את המדיניות הזו.

המניפסט הבא מתאר מדיניות בניהול GKE בשם gke-bbfa6c0e-1:

    Name:         gke-bbfa6c0e-1
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  networking.gke.io/v1
    Kind:         EgressNATPolicy
    Metadata:
      Creation Timestamp:  2022-03-16T21:05:46Z
      Generation:          1
      Managed Fields:
        API Version:  networking.gke.io/v1
        Fields Type:  FieldsV1
        fieldsV1:
          f:spec:
            .:
            f:action:
            f:destinations:
          f:status:
        Manager:         egress-nat-controller
        Operation:       Update
        Time:            2022-03-16T21:05:46Z
      Resource Version:  11699
      UID:               0201b5de-a6f6-4926-822b-31ed7cdee2c6
    Spec:
      Action:  NoSNAT
      Destinations:
        Cidr:  10.119.128.0/17
        Cidr:  10.120.0.0/22
        Cidr:  10.128.0.0/20
    Status:
    Events:  <none>

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