שכבת הרשת הווירטואלית ב-Google Distributed Cloud (GDC) air-gapped שולטת בקישוריות, בחומות אש, באיתור שירותים, באיזון עומסים ובאפשרות הצפייה בין מכונות וירטואליות ובין פודים שפועלים בארגון GDC.
מודל הרשת של GDC
GDC כולל שני סוגים של מושגים שקשורים לריבוי דיירים: ארגונים ופרויקטים. פרויקטים קיימים בתוך ארגונים, ואתם פורסים את כל עומסי העבודה הווירטואליים והמבוססים על קונטיינרים בפרויקט מסוים בארגון.
רשתות בארגון
לכל ארגון ב-GDC יש רשת וירטואלית מבודדת משלו. הרשת הווירטואלית בארגון היא מרחב IP שטוח, כלומר לכל עומסי העבודה בארגון יש קישוריות ישירה של כתובות IP אחד לשני. באמצעות מדיניות רשת של פרויקט, אתם יכולים לשלוט בגישה בין עומסי עבודה בפרויקטים שונים בארגון.
GDC מבודד כל ארגון ברמת הרשת מכל הארגונים האחרים. לעומסי עבודה בארגון אחד אין קישוריות ישירה של כתובות IP לעומסי עבודה בארגון אחר.
לארגון יש שני טווחי כתובות IP שונים: טווח פנימי וטווח חיצוני. אפשר להגיע לטווח כתובות ה-IP החיצוניות מחוץ לארגון, ואפשר לגשת לטווח כתובות ה-IP הפנימיות רק מתוך הארגון. לעומסי עבודה תמיד מוקצית כתובת IP מהטווח הפנימי של הארגון, כלומר כברירת מחדל אי אפשר לגשת אליהם מחוץ לארגון. צריך להפעיל באופן מפורש תעבורת נתונים נכנסת ויוצאת עבור עומסי עבודה באמצעות האילוצים של תעבורת נתונים נכנסת ותעבורת נתונים יוצאת שמתוארים בקטע רשת הפרויקט.
נטוורקינג בפרויקטים
אתם פורסים את כל המכונות הווירטואליות (VM) ועומסי העבודה בקונטיינרים בפרויקט. פרויקטים מספקים גבול לפילוח הרשת בתוך הארגון.
עומסי עבודה בפרויקט יכולים לתקשר ישירות ביניהם. עם זאת, מדיניות הרשת שמוגדרת כברירת מחדל מונעת תקשורת בין עומסי עבודה בפרויקטים שונים. מדיניות רשת של פרויקט (ProjectNetworkPolicy) מאפשרת להגדיר אילו פרויקטים בארגון יכולים לתקשר זה עם זה. אם מדיניות הרשת של הפרויקט מאפשרת זאת, עומסי העבודה בארגון יכולים להגיע זה לזה בשכבת הרשת L3 באמצעות כתובות ה-IP שלהם. צריך להפעיל באופן מפורש את ההגבלות על תעבורה נכנסת ותעבורה יוצאת אל הארגון וממנו לכל עומס עבודה שדורש תעבורה נכנסת או יוצאת.
הגדרת מאזני עומסים
מאזני עומסים מפזרים את התעבורה בין עומסי העבודה של הקצה העורפי של האפליקציה, כדי להבטיח יציבות וזמינות. יצירת מאזני עומסים חיצוניים ופנימיים לעומסי עבודה של פודים ומכונות וירטואליות. ב-GDC יש שלוש שיטות להגדרת מאזני עומסים. מידע נוסף זמין במאמר בנושא ניהול מאזני עומסים.
מגבלות על Ingress
המנגנון שמשמש לחשיפת עומסי עבודה מחוץ לארגון משתנה בהתאם לשאלה אם עומס העבודה מבוסס על מכונות וירטואליות או על קונטיינרים.
אתם חושפים עומסי עבודה מבוססי-VM מחוץ לארגון באמצעות היכולת של ה-VM לגשת לחיבורים חיצוניים. מפעילים את היכולת הזו לכל מכונה וירטואלית. כל מכונה וירטואלית מקבלת כתובת IP משלה מטווח הכתובות החיצוני של הארגון.
לעומת זאת, אתם חושפים עומסי עבודה מבוססי-קונטיינרים מחוץ לארגון באמצעות התכונה של מאזן עומסים חיצוני. אתם יכולים ליצור מאזן עומסים חיצוני, ו-GDC יקצה כתובת IP חיצונית. לאחר מכן, אפשר לאזן את עומס התנועה בין קבוצה של עומסי עבודה של פודים בקצה העורפי.
מגבלות על תעבורת נתונים יוצאת (egress)
כדי לאפשר תקשורת מחוץ לארגון, צריך להפעיל במפורש תעבורה יוצאת לכל פרויקט ועומס עבודה. הפעלת תעבורה יוצאת משנה את כתובת ה-IP של עומסי העבודה לכתובת IP חיצונית באמצעות תרגום כתובות רשת (NAT) כשמתחברים מחוץ לארגון. מידע נוסף על מתן הרשאה לתעבורת נתונים יוצאת זמין במאמר סקירה כללית של NAT.
מודל לאכיפת מדיניות הרשת
מצב האבטחה של עומסי עבודה בארגון הוא שילוב של מדיניות רשת של פרויקט שמוגדרת כברירת מחדל ושל מדיניות שנוצרה על ידי משתמשים.
אכיפת המדיניות מבוססת על זרימות תנועה בשכבה 3 ובשכבה 4. זרימה מתארת חיבור של 5 טופלים באופן הבא:
- כתובת ה-IP של המקור
- כתובת ה-IP של היעד
- יציאת המקור
- יציאת היעד
- פרוטוקול, כמו
TCPאוUDP
מדיניות הרשת אוכפת תעבורת נתונים יוצאת על תעבורת נתונים בצומת שמארח את עומס העבודה של המקור, ואוכפת תעבורת נתונים נכנסת כשתעבורת הנתונים מגיעה לצומת שמארח את עומס העבודה של היעד. לכן, כדי ליצור חיבור, צריך לאפשר למדיניות לצאת מהמקור אל היעד ולהגיע ליעד מהמקור.
תנועה של תשובות, כמו פלח SYN-ACK (סנכרון-אישור) שמשיב לפלח SYN, לא כפופה לאכיפה. לכן, תנועת גולשים של תשובות תמיד מותרת אם תנועת הגולשים הראשונית מותרת. לכן, אתם יכולים לראות רק פסק זמן קצוב לתפוגה של חיבורים בגלל אכיפת מדיניות מצד הלקוח שיזם את החיבור. התנועה שנדחית מושלכת במהלך העברת הנתונים היוצאת מצומת המקור או במהלך העברת הנתונים הנכנסת בצומת היעד. עומס העבודה המקבל אף פעם לא מתבונן בחיבור.
האכיפה מבוססת על כללי מדיניות של הרשאות, שהם מצטברים. האכיפה שמתקבלת עבור עומס עבודה היא "התאמה כלשהי" לזרימת התנועה ביחס לצירוף של כל כללי המדיניות שחלים על עומס העבודה הזה. אם יש כמה כללי מדיניות, הכללים שחלים על כל עומס עבודה משולבים באופן מצטבר, כך שהתנועה מורשית אם היא תואמת לפחות לאחד מהכללים. אין לך כללי דחייה, רק כללי אישור.
כשמדיניות רשת דוחה זרימה, לא מתקבלת חבילת תגובה ומתרחש פסק זמן לחיבור. לכן, חיבורים ברמת הפרוטוקול שנדחו או שאופסו, או שגיאות HTTP, לא נובעים ישירות מאכיפת הרשת.
מידע נוסף על מדיניות רשת ב-Kubernetes זמין בכתובת https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation.