סקירה כללית

בדף הזה מוסבר על מדיניות הרשת של הפרויקט ב-Google Distributed Cloud (GDC) עם air gap.

מדיניות הרשת של הפרויקט מגדירה כללים לתעבורת נתונים נכנסת (ingress) או יוצאת (egress). בניגוד למדיניות רשת ב-Kubernetes, אפשר לציין רק סוג מדיניות אחד לכל מדיניות. בכל כלל במדיניות אפשר להגדיר פעולה של "אישור" (ברירת המחדל) או "דחייה".

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

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

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

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

אבטחה וקישוריות

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

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

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

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

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

כשמשתמשים בכתובת IP מוכרת שאתם מקצים לפרויקט, היא מבצעת תרגום כתובת רשת (NAT) של המקור בתנועה היוצאת מהארגון.

מדיניות ברירת המחדל בתוך הפרויקט

כשיוצרים פרויקט, GDC יוצר באופן אוטומטי מדיניות הרשת של הפרויקט בשם base-policy-allow-intra-project-traffic במרחב השמות של הפרויקט. מדיניות ברירת המחדל הזו מבצעת את הפעולות הבאות:

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

‫GDC יוצר את מדיניות ברירת המחדל רק פעם אחת, כשהוא יוצר את הפרויקט. אם תשנו או תמחקו את המדיניות, GDC לא ישחזר אותה. ‫GDC מפיץ את המדיניות לכל אשכול בפרויקט כמדיניות רשת ב-Kubernetes בשם g-base-policy-allow-intra-project-traffic. השם הזה מופיע בשדה status.zones[].replicaStatus.propagatedName של המדיניות.

כדי להציג את מדיניות ברירת המחדל, מריצים את הפקודה הבאה:

kubectl --kubeconfig GLOBAL_API_SERVER get projectnetworkpolicy \
    base-policy-allow-intra-project-traffic -n PROJECT -o yaml

מחליפים את מה שכתוב בשדות הבאים:

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

מדיניות ברירת המחדל משתלבת עם כללי המדיניות שאתם יוצרים באופן הבא:

  • תעבורת נתונים נכנסת (Ingress): כברירת מחדל, עומסי העבודה מבודדים מפרויקטים אחרים ומחוץ לארגון, גם אם מדיניות ברירת המחדל קיימת וגם אם לא. כללי מדיניות תעבורת הנתונים הנכנסת שאתם יוצרים מוסיפים מקורות מותרים, כמו פרויקטים אחרים או בלוקים חיצוניים של CIDR. כל עוד מדיניות ברירת המחדל קיימת, אתם לא צריכים לחזור על הכלל של הפרויקט במדיניות הכניסה שלכם.
  • תעבורת נתונים נכנסת ברמת עומס העבודה בתוך הפרויקט: כל עוד מדיניות ברירת המחדל קיימת, כל עומסי העבודה בפרויקט יכולים להגיע זה לזה בכל היציאות. מדיניות תעבורת נתונים נכנסת ברמת עומס העבודה בתוך הפרויקט שמשתמשת בפעולה Allow לא מגבילה את התנועה הזו עד שמוחקים או משנים את מדיניות ברירת המחדל. כדי למנוע הפרעות, לפני שמוחקים את מדיניות ברירת המחדל, צריך להחיל את כללי המדיניות ברמת עומס העבודה ולוודא שהם מוכנים. כדי לחסום תנועה ספציפית בתוך הפרויקט תוך שמירה על מדיניות ברירת המחדל, אתם יכולים להשתמש בכלל דחייה מפורש, שהוא תכונה בגרסת טרום-השקה (Preview). למידע נוסף, קראו את המאמר יצירת מדיניות כניסה ברמת עומס העבודה בתוך הפרויקט.
  • תעבורת נתונים יוצאת: כברירת מחדל, לפרויקט אין מדיניות תעבורת נתונים יוצאת. תנועה יוצאת לא מוגבלת בתוך הארגון, אבל הגנה מפני זליגת נתונים (מופעלת כברירת מחדל) חוסמת תנועה שיוצאת מהארגון. כללי מדיניות תעבורת הנתונים היוצאת נכנסים לתוקף רק אחרי שמשביתים את ההגנה מפני זליגת נתונים בפרויקט. כשההגנה מפני זליגת נתונים מופעלת, שרתי API אזוריים דוחים את כללי היציאה, וכללי היציאה הגלובליים לא מוכנים.

מדיניות הרשת של הפרויקט גלובליות

אתם יכולים ליצור מדיניות גלובלית לרשת של הפרויקט. ההיקף של מדיניות הרשת הגלובלית של הפרויקט חל על כל סביבת GDC. כל סביבת GDC יכולה להכיל כמה אזורי GDC שמחולקים לאזורים שמקושרים ביניהם ומשתפים מישור בקרה. לדוגמה, אם יש לכם שני אזורים עם שלושה אזורים בכל אחד, זה יכול להיראות כך: us-virginia1-a,‏ us-virginia1-b,‏ us-virginia1-c ו-eu-ams1-a,‏ eu-ams1-b,‏ eu-ams1-c.

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

למידע נוסף על משאבים גלובליים בסביבת GDC, קראו את הסקירה הכללית על ריבוי אזורים.

אתם יכולים ליצור מדיניות רשת גלובלית של פרויקטים באמצעות Networking Kubernetes Resource Model (KRM) API. כדי ליצור משאבים גלובליים, משתמשים בגרסת ה-API ‏networking.global.gdc.goog.

אתם יכולים ליצור מדיניות רשת של פרויקט באזור מסוים באמצעות KRM API או מסוף GDC. כדי ליצור משאבים של תחום מוגדר, צריך להשתמש בגרסת ה-API‏ networking.gdc.goog.

מדיניות רשת ב-Kubernetes שמאפשרת הכול

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

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

  • מדיניות רשת שמאפשרת הכול: מאפשרת תנועה מכל מקור ואליו, כולל פרויקטים אחרים וכתובות IP חיצוניות.
  • מדיניות רשת ב-Kubernetes שמאפשרת את כל התעבורה החיצונית: מאפשרת תעבורה אל כתובות IP מחוץ לארגון ומכתובות כאלה.
  • מדיניות הרשת "אישור לכל הפרויקטים": מאפשרת תנועה מכל הפרויקטים בארגון ואליהם.

מידע נוסף זמין במאמר יצירת מדיניות רשת ב-Kubernetes שמאפשרת את כל התנועה.

מדיניות רשת ב-Kubernetes עם דחייה מפורשת

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

התכונות והמגבלות העיקריות של כללי דחייה:

  • עדיפות: כללי דחייה מקבלים עדיפות מוחלטת על פני כללי הרשאה (כולל כללי מדיניות בסיסיים של הפלטפורמה).
  • כללי בטיחות לתעבורת נתונים יוצאת: כדי למנוע חסימה בטעות של תעבורת נתונים בתשתית קריטית, כללי דחייה של תעבורת נתונים יוצאת מחריגים באופן אוטומטי מרחבי שמות של המערכת ומרחבי שמות שלא שייכים לפרויקט.
  • הגבלת עמיתים: כדי להבטיח הגדרה בטוחה, כללי דחייה של תעבורת נתונים נכנסת חייבים לציין במפורש עמית מקור בשדה from, וכללי דחייה של תעבורת נתונים יוצאת חייבים לציין במפורש עמית יעד בשדה to. אי אפשר לבחור את כל המקורות או היעדים על ידי השארת שדה הישות המקבילה ריק. אסור להשאיר את השדה של המקבילים ריק, והמדיניות תידחה.
  • אין דחיית תעבורת נתונים יוצאת עם DEP: אי אפשר להגדיר כללי דחייה של תעבורת נתונים יוצאת כשההגנה מפני זליגת נתונים (DEP) מופעלת בפרויקט.

מידע נוסף זמין במאמר יצירת מדיניות רשת ב-Kubernetes עם דחייה מפורשת.

מדיניות רשת ברמת עומס העבודה

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

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

מידע נוסף זמין במאמרים יצירת מדיניות ברמת עומס העבודה בתוך הפרויקט ויצירת מדיניות ברמת עומס העבודה בפרויקטים שונים.

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

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

apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-frontend-to-backend
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            app: backend
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PEER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: frontend
    ports:
    - protocol: TCP
      port: 8080

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT: שם הפרויקט.
  • ‫PEER_PROJECT: שם הפרויקט שמכיל את עומסי העבודה של הלקוח.

המדיניות הזו מאפשרת לעומסי עבודה עם התווית app: frontend ב-PEER_PROJECT להתחבר לעומסי עבודה עם התווית app: backend בפרויקט שלכם ביציאת TCP‏ 8080.

כשאתם כותבים מדיניות, חשוב לפעול לפי הכללים הבאים:

  • תמיד צריך להגדיר את spec.policyType באופן מפורש ל-Ingress או ל-Egress. מדיניות Ingress יכולה להכיל רק כללי ingress עם עמיתים מסוג from, ומדיניות Egress יכולה להכיל רק כללי egress עם עמיתים מסוג to. אם משמיטים את policyType, המדיניות מוגדרת כברירת מחדל ל-Ingress, ושרת ה-API דוחה מדיניות שמכילה רק כללי egress.
  • כדי לבחור עומסי עבודה של נושאים לפי תווית, משתמשים ב-spec.subject.userWorkloadSelector.labelSelector.workloads. אם לא מציינים את userWorkloadSelector, המדיניות חלה על כל עומסי העבודה של המשתמשים בפרויקט.
  • אל תמקמו בוררי תוויות ישירות מתחת ל-spec.subject. כברירת מחדל, kubectl דוחה שדות כמו spec.subject.matchLabels עם הודעת strict decoding error: unknown field.
  • כדי לבחור עומסי עבודה מקבילים לפי תווית, משתמשים ב-projectSelector.workloadSelector.labelSelector.workloads ברשומה של from או to.
  • אם עומסי העבודה של הנושא או של השותף הם מכונות וירטואליות, צריך להוסיף את הקידומת user-label.gpc.gke.io/ למפתחות התוויות שלהם. לדוגמה, אפשר להשתמש ב-user-label.gpc.gke.io/app: backend.
  • מדיניות ברירת המחדל שנוצרה באופן אוטומטי בתוך הפרויקט וחלק מהכללי המדיניות הקיימים משתמשים בשדה spec.subject.workloadSelector שהוצא משימוש, שמקבל בורר תוויות באופן ישיר. משתמשים ב-userWorkloadSelector במדיניות חדשה.

כדי לאמת מדיניות מול שרת ה-API הגלובלי בלי להחיל אותה, מריצים הרצה יבשה בצד השרת:

kubectl --kubeconfig GLOBAL_API_SERVER apply --dry-run=server \
    --validate=strict -f POLICY_FILE

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

כדי להציג את השדות ששרת ה-API הגלובלי מקבל, מריצים את הפקודה הבאה:

kubectl --kubeconfig GLOBAL_API_SERVER explain projectnetworkpolicy.spec \
    --api-version=networking.global.gdc.goog/v1 --recursive

מחליפים את מה שכתוב בשדות הבאים:

  • ‫GLOBAL_API_SERVER: הנתיב של kubeconfig בשרת ה-API הגלובלי.
  • ‫POLICY_FILE: הנתיב למניפסט של ProjectNetworkPolicy.

הכנת תפקידים מוגדרים מראש וגישה

כדי להגדיר את מדיניות הרשת של הפרויקט, צריך שיהיו לכם את התפקידים הנדרשים לזהות ולגישה:

  • אדמין של מדיניות הרשת של הפרויקט: יש לו הרשאות כתיבה בכל המשאבים של מדיניות הרשת של הפרויקט בכמה אזורים במרחב השמות הגלובלי של הפרויקט. צריך לבקש ממנהל חשבון ארגוני ב-IAM להקצות לכם את התפקיד global-project-networkpolicy-admin. למידע נוסף, קראו את תיאורי התפקידים המוגדרים מראש.

טירגוט צמתים באשכול באמצעות בלוקים של כתובות IP

אפשר להשתמש בשדה ipBlocks במשאב ProjectNetworkPolicy כדי לציין כתובות IP ספציפיות של צמתים או טווחי CIDR של צמתים, ולשלוט בתעבורת נתונים בין פודים לצמתים ספציפיים באשכול (לדוגמה, לאפשר תעבורת נתונים נכנסת מצמתים של מישור הבקרה לפוד של תגובה לפעולה מאתר אחר (webhook) בהתאמה אישית, או להגביל תעבורת נתונים יוצאת של פוד לצמתים של מישור הבקרה). להוראות, ראו יצירת מדיניות בתוך הפרויקט לאשכולות רגילים.

שיקולים שקשורים להיקף

כשמגדירים את מדיניות הרשת של הפרויקט לטירגוט צמתים ספציפיים או כשמשתמשים בטווחי CIDR רחבים, הבחירות שלכם בהגדרת המדיניות יכולות להשפיע על יכולת ההתאמה לעומס (scalability) ועל הביצועים:

  • ההתנהגות של 0.0.0.0/0: שימוש בטווח CIDR רחב כמו 0.0.0.0/0 בכלל ipBlocks תואם לכל הצמתים באשכול, בנוסף לכתובות IP חיצוניות.
  • קנה מידה: לכל צומת באשכול מוקצית זהות CIDR ייחודית. לכל נקודת קצה (endpoint) של עומס עבודה (VM או pod) יש טבלת מדיניות פנימית שבה מאוחסנים כללי הרשת שלה. באשכולות גדולים, כללים רחבים של ipBlocks כמו 0.0.0.0/0 מגדילים את השימוש בטבלת המדיניות באופן יחסי למספר הצמתים, כי המערכת צריכה ליצור רשומות לכל זהות CIDR ייחודית של צומת.
  • אזהרה: אם יש לכם מספר גדול של צמתים או הרבה כללי מדיניות מורכבים, אל תשתמשו בטווחי CIDR רחבים מדי בכללי ipBlocks, כי אתם עלולים לחרוג מהמגבלה של טבלת המדיניות לנקודת קצה. אם נקודת קצה מגיעה למגבלה הזו, כללי מדיניות רשת ב-Kubernetes חדשים לא יחולו, מה שעלול לשבש את הקישוריות לרשת או למנוע את אכיפת המדיניות על עומס העבודה הזה.

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