מידע על בידוד רשת ב-GKE

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

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

שיטה מומלצת:

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

סוגי הגישה לרשת

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

  • גישה למישור הבקרה ממקורות חיצוניים: אפשר להתאים אישית את האנשים שיכולים לגשת למישור הבקרה כדי לבצע משימות כמו הפעלת פקודות kubectl באשכול.
  • גישה ל-webhooks חיצוניים משרת ה-API: אפשר להתאים אישית את האפשרות ששרת ה-API של Kubernetes יוכל לשלוח תנועה ישירות לשרתי webhook חיצוניים דרך מישור הבקרה.
  • גישה לצמתים ממקורות חיצוניים: אתם יכולים להגדיר אם לקוחות חיצוניים באינטרנט הציבורי יוכלו לגשת לצמתים שלכם.

גישה למישור הבקרה ממקורות חיצוניים

בקטע הזה נסביר לכם למי יש גישה למישור הבקרה.

לכל אשכול GKE יש מישור בקרה שמטפל בבקשות של Kubernetes API. מישור הבקרה פועל במכונה וירטואלית (VM) שנמצאת ברשת VPC בפרויקט שמנוהל על ידי Google. באשכול אזורי יש כמה רפליקות של מישור הבקרה, וכל אחת מהן פועלת במכונה וירטואלית משלה. חשבונות ראשיים, כמו אדמינים של אשכולות, משתמשים בנקודת קצה של מישור הבקרה כדי לגשת לאשכול לצורך ביצוע משימות כמו הפעלת פקודות kubectl או פריסת עומסי עבודה. לקוחות חיצוניים משתמשים בנקודת הקצה של רמת הבקרה כדי לגשת לאשכול, והיא לא משמשת לתקשורת ישירה עם המכונות הווירטואליות ב-Compute Engine שמארחות את העותקים המשוכפלים של רמת הבקרה. למישור הבקרה יש את הסוגים הבאים של נקודות קצה (endpoints) לגישה לאשכול:

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

  • נקודת קצה מבוססת-DNS
  • נקודות קצה מבוססות-IP
שיטה מומלצת:

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

נקודת קצה מבוססת DNS

נקודת הקצה שמבוססת על DNS נותנת DNS ייחודי ובלתי ניתן לשינוי, או שם דומיין שמוגדר במלואו (FQDN) לכל מישור בקרה של אשכול. אפשר להשתמש בשם ה-DNS הזה כדי לגשת למישור הבקרה לאורך כל מחזור החיים שלו. שם ה-DNS מומר לנקודת קצה שאפשר לגשת אליה מכל רשת שאפשר להגיע אליה באמצעות ממשקי API של Cloud de Confiance by S3NS , כולל רשתות מקומיות או רשתות ענן אחרות. כשמפעילים את נקודת הקצה שמבוססת על DNS, לא צריך יעד מבוצר או צומתי proxy כדי לגשת למישור הבקרה מרשתות VPC אחרות או ממיקומים חיצוניים.

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

בנוסף למדיניות ולטוקנים של IAM, אפשר גם להגדיר את מאפייני הגישה הבאים:

  • אמצעי בקרה מבוססי כתובת IP או רשת באמצעות VPC Service Controls: כדי לשפר את האבטחה של מישור הבקרה של אשכול GKE,‏ VPC Service Controls מוסיף עוד שכבת אבטחה לגישה. היא משתמשת בבקרת גישה מבוססת-הקשר שמבוססת על מאפיינים כמו מקור הרשת.

    שירות VPC Service Controls לא תומך ישירות באשכולות עם כתובות IP ציבוריות למישור הבקרה שלהם. עם זאת, אשכולות GKE, כולל אשכולות פרטיים וציבוריים, מקבלים הגנה מ-VPC Service Controls כשניגשים אליהם באמצעות נקודת הקצה (endpoint) שמבוססת על DNS.

    כדי להגדיר את VPC Service Controls להגנה על נקודת הקצה מבוססת ה-DNS של אשכול GKE, צריך לכלול את container.googleapis.com ואת kubernetesmetadata.googleapis.com ברשימת השירותים המוגבלים של גבולות גזרה לשירות. הוספת ממשקי ה-API האלה לגבולות גזרה לשירות תאפשר שימוש ב-VPC-SC עבור כל הפעולות של GKE API. ההגדרה הזו עוזרת לוודא שמתחמי האבטחה שהגדרתם שולטים בגישה למישור הבקרה.

    שימוש במדיניות IAM וב-VPC Service Controls כדי לאבטח את הגישה לנקודת הקצה שמבוססת על DNS יוצר מודל אבטחה רב-שכבתי למישור הבקרה של האשכול. ‫VPC Service Controls משתלב עם שירותים נתמכים Cloud de Confiance . הוא מתאים את הגדרות האבטחה של האשכול לנתונים שמתארחים בשירותים אחרים של Cloud de Confiance .

  • ‫Private Service Connect או Cloud NAT: כדי לגשת לנקודת הקצה (endpoint) שמבוססת על DNS מלקוחות שאין להם גישה לאינטרנט הציבורי. כברירת מחדל, אפשר לגשת לנקודת הקצה שמבוססת על DNS דרך Cloud de Confianceממשקי API שזמינים באינטרנט הציבורי. מידע נוסף זמין במאמר בנושא נקודת קצה מבוססת-DNS בדף בנושא התאמה אישית של בידוד הרשת.

  • פרטי כניסה לאימות ב-Kubernetes: כדי לבצע אימות לנקודת הקצה שמבוססת על DNS באמצעות טוקנים למוכ"ז של Kubernetes ServiceAccount או אישורי לקוח מסוג X.509. שיטות האימות האלה מושבתות כברירת מחדל באשכולות GKE. אפשר להפעיל את השיטות האלה כשמגדירים את נקודת הקצה (endpoint) מבוססת ה-DNS של אשכול.

נקודות קצה מבוססות-IP

אפשר גם להגדיר גישה למישור הבקרה באמצעות נקודות קצה (endpoints) שמבוססות על כתובות IP.

מינוח שקשור לאשכולות ולכתובות IP

  • Cloud de Confiance by S3NS כתובות IP חיצוניות:

    • כתובות IP חיצוניות שמוקצות למכונה וירטואלית כלשהי שמשמשת לקוח כלשהו שמתארח ב- Cloud de Confiance.הן בבעלות Cloud de Confiance . מידע נוסף זמין במאמר איפה אפשר למצוא טווחי כתובות IP של Compute Engine?

    • כתובות IP חיצוניות שמשמשות Cloud de Confiance מוצרים כמו Cloud Run או פונקציות Cloud Run. כל לקוח שמארח ב- Cloud de Confiance יכול ליצור מופעים של כתובות ה-IP האלה. Cloud de Confiance הוא הבעלים של כתובות ה-IP האלה.

  • כתובות IP ששמורות ל-Google: כתובות IP חיצוניות למטרות ניהול של אשכולות GKE. כתובות ה-IP האלה כוללות תהליכים מנוהלים של GKE ושירותי Google אחרים בסביבת הייצור. כתובות ה-IP האלה הן בבעלות Google.

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

  • כתובות IP פנימיות: כתובות IP מרשת ה-VPC של האשכול. כתובות ה-IP האלה יכולות לכלול את כתובת ה-IP של האשכול, רשתות מקומיות, טווחים של RFC 1918 או כתובות IP ציבוריות בשימוש פרטי (PUPI) שכוללות טווחים שאינם RFC 1918.

  • נקודת קצה של אשכול שמבוססת על כתובת IP חיצונית: כתובת ה-IP של נקודת הקצה החיצונית, שמוקצית למישור הבקרה על ידי GKE.

  • כתובת IP חיצונית של המכונה הווירטואלית של מישור הבקרה: כתובת ה-IP החיצונית שמוקצית לכל מכונה וירטואלית שמריצה את מישור הבקרה, ומשמשת רק לתעבורת נתונים יוצאת משרת ה-API.

  • נקודת קצה פנימית: כתובת ה-IP הפנימית ש-GKE מקצה למישור הבקרה.

  • רשת VPC: רשת וירטואלית שבה יוצרים תת-רשתות עם טווחי כתובות IP במיוחד לצמתים ול-Pods של האשכול.

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

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

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

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

בשתי האפשרויות הקודמות, אפשר להגביל את כתובות ה-IP שיכולות להגיע לנקודות הקצה באמצעות הגדרה של רשתות מורשות. אם אתם משתמשים בנקודות קצה (endpoints) שמבוססות על כתובות IP, מומלץ מאוד להוסיף לפחות רשת מורשית אחת. רשתות מורשות מעניקות גישה למישור הבקרה לקבוצה ספציפית של כתובות IPv4 מהימנות, ומספקות הגנה והטבות אבטחה נוספות לאשכול GKE.

שיטה מומלצת:

כדי לאבטח את אשכול GKE, מומלץ להפעיל רשתות מורשות כשמשתמשים בנקודות קצה (endpoint) מבוססות-IP.

איך רשתות מורשות פועלות

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

בטבלה הבאה מוצגים:

  • כתובות ה-IP המוגדרות מראש שתמיד יכולות לגשת למישור הבקרה של GKE, גם אם מפעילים רשתות מורשות.
  • כתובות ה-IP שאפשר להגדיר, שיכולות לגשת למישור הבקרה כשמוסיפים אותן לרשימת ההיתרים על ידי הפעלת רשתות מורשות.
נקודות קצה (endpoint) של מישור הבקרה כתובות IP מוגדרות מראש שתמיד יכולות לגשת לנקודות הקצה כתובת IP שאפשר להגדיר לה גישה לנקודות הקצה אחרי הפעלת רשתות מורשות
נקודות קצה חיצוניות ופנימיות מופעלות
  • כתובות IP ששמורות ל-Google
  • טווחים של כתובות IP באשכול GKE
  • כתובות IP חיצוניות ברשימת ההיתרים
  • כתובות IP פנימיות ברשימת ההיתרים
  • Cloud de Confiance כתובות IP חיצוניות
רק נקודת קצה פנימית מופעלת
  • כתובות IP ששמורות ל-Google
  • טווחים של כתובות IP באשכול GKE
  • כתובות IP פנימיות שנוספו לרשימת ההיתרים.

ברשת מורשית, אפשר גם להגדיר את האזור שממנו כתובת IP פנימית יכולה להגיע לנקודת הקצה הפנימית של מישור הבקרה. אתם יכולים לבחור לאפשר גישה רק מרשת ה-VPC של האשכול, או מכל אזור של Cloud de Confiance ברשת VPC או בסביבה מקומית.

מגבלות על השימוש בנקודות קצה (endpoints) שמבוססות על כתובות IP

  • אם מרחיבים רשת משנה שמשמשת אשכול עם רשתות מורשות, צריך לעדכן את הגדרת הרשתות המורשות כך שתכלול את טווח כתובות ה-IP המורחב.
  • אם יש לכם לקוחות שמתחברים מרשתות עם כתובות IP דינמיות, כמו עובדים ברשתות ביתיות, אתם צריכים לעדכן את רשימת הרשתות המורשות לעיתים קרובות כדי לשמור על הגישה לאשכול.
  • השבתת הגישה לנקודת הקצה החיצונית של מישור הבקרה מונעת אינטראקציה עם האשכול מרחוק. אם אתם צריכים לגשת מרחוק לאשכול, אתם צריכים להשתמש ביעד מבוצר (bastion host) שמעביר את תעבורת הנתונים של הלקוחות לאשכול. לעומת זאת, כדי להשתמש בנקודת קצה (endpoint) שמבוססת על DNS, צריך רק להגדיר הרשאות IAM.
  • נקודות קצה שמבוססות על כתובות IP לא משתלבות ישירות עם VPC Service Controls. התכונה VPC Service Controls פועלת ברמת גבולות גזרה לשירות כדי לשלוט בגישה לנתונים ובתנועת הנתונים בתוך Cloud de Confiance. מומלץ להשתמש גם בנקודת קצה מבוססת DNS וגם ב-VPC Service Controls כדי להשיג הגנה חזקה מפני איומי אבטחה.
  • אפשר לציין עד 100 טווחי כתובות IP מורשים (כולל כתובות IP חיצוניות ופנימיות).

אבטחת תעבורה לחיבורים של מישור הבקרה

כששולחים בקשות לשרת Kubernetes API באשכול באמצעות שיטות כמו ספריות לקוח או kubectl CLI, החיבור בין הלקוח לשרת מוגן באמצעות TLS.

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

  • נקודת קצה מבוססת-DNS: שירות Google Front End‏ (GFE) שמארח את נקודת הקצה מבוססת-ה-DNS מציג את האישור. האישור נחתם על ידי רשות אישורים (CA) ציבורית של Google, שמוכרת בדרך כלל. הלקוח יכול להשתמש במידע הציבורי של רשות האישורים כדי לאמת את האישור.
  • נקודות קצה מבוססות-IP: שרת ה-API של Kubernetes מציג את האישור. האישור נחתם על ידי רשות האישורים (CA) ברמה הבסיסית של האשכול. כדי לאמת את אישור שרת ה-API, הלקוח צריך להשתמש באישור הציבורי של CA הבסיסי של האשכול. כשמגדירים לקוח בסביבה שאין לה גישה ל-CLI של gcloud, צריך להוסיף את אישור ה-CA הבסיסי של האשכול לקובץ ~/.kube/config. מידע נוסף זמין במאמר בנושא אימות לשרת Kubernetes API.

גישה למקורות חיצוניים משרת ה-API

מישור הבקרה של אשכול GKE מריץ רכיבים של מישור הבקרה של Kubernetes, כמו שרת ה-API, המתזמן והבקרים. מישור הבקרה פועל במכונה וירטואלית ב-Compute Engine שנמצאת בבעלות GKE בפרויקט מנוהל. באשכולות אזוריים ובאשכולות Autopilot יש כמה רפליקות של מישור הבקרה, וכל אחת מהן פועלת במכונה וירטואלית משלה.

כברירת מחדל, לכל אחת מהמכונות הווירטואליות האלה ב-Compute Engine יש כתובת IP חיצונית שמוקצית ישירות למכונה הווירטואלית. כתובת ה-IP הזו משמשת רק לשליחת בקשות הרשאה משרת ה-API של Kubernetes במופע אל שרתי webhook של הרשאה שפועלים מחוץ לאשכול, למשל בשירות ענן אחר או בפריסה מקומית. כתובת ה-IP הזו משמשת רק אם ה-webhooks של הגישה יוצרים קשר ישירות עם שרת ה-webhook באמצעות כתובת ה-URL של השרת או כתובת ה-IP של השרת.

כדי לשפר את מצב האבטחה של מישור הבקרה, אתם יכולים להשבית את כתובת ה-IP החיצונית במכונות הווירטואליות של מישור הבקרה. במקרה של פריצה, תוקפים פוטנציאליים לא יכולים להשתמש בכתובות ה-IP החיצוניות האלה כדי לתקשר. אפשר להתאים אישית את תנועת היציאה משרת ה-API בדרכים הבאות:

  • אין תנועת יציאה (NONE): משביתים את כתובת ה-IP החיצונית של כל מופע של מישור הבקרה ומנתבים את תנועת היציאה של שרת API לחור שחור. כל תעבורת הנתונים היוצאת (egress) הלא-קריטית משרת ה-API ליעדים חיצוניים נחסמת, כולל תעבורת נתונים לשירותי Cloud de Confiance מחוץ לאשכול. האפשרות הזו לא משפיעה על תנועה קריטית של המערכת או על תנועה מהצמתים שלכם.
  • ‫All egress traffic (VIA_CONTROL_PLANE): שמירה של כתובת ה-IP החיצונית של כל מכונה במישור הבקרה, ומתן הרשאה לשרת ה-API להשתמש בכתובת ה-IP לתעבורת נתונים יוצאת. זוהי אפשרות ברירת המחדל ב-GKE.

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

הגדרת webhook חיצוני

כשמגדירים את הגבלות היציאה של מישור הבקרה ל-NONE, שרת ה-API לא יכול לבצע קריאות ישירות לכתובות IP חיצוניות או לשמות דומיין מלאים (FQDN). להגדרה NONE יש את ההשפעות הבאות על ווּבּהוקים חיצוניים:

  • בגרסה 1.35.1-gke.1396000 ואילך,‏ GKE מונע יצירה של ValidatingWebhookConfigurations או MutatingWebhookConfigurations שמשתמשים בשדה clientConfig.url, או עדכונים שלהם.
  • הגדרות קיימות של תגובות לפעולה מאתר אחר (webhook) שמשתמשות בשדה clientConfig.url כדי ליצור קשר עם שרת חיצוני מפסיקות לפעול.

כדי ליצור שרתי webhook חיצוניים ולהשתמש בהם, צריך:

  1. מעדכנים את ValidatingWebhookConfigurations או את MutatingWebhookConfigurations כך שישתמשו בשדה clientConfig.service. השדה הזה מאפשר לשרת ה-API לשלוח בקשות לנקודת קצה של שירות, כמו my-webhook.default.svc, באשכול שלכם. הבקשות האלה לא נחסמות כי התנועה נמצאת בתוך האשכול. מידע נוסף זמין במאמר בנושא הפניה לשירות.

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

    • Proxy Pods: שימוש ב-Deployment או ב-StatefulSet כקצה העורפי של ה-Service. מגדירים את ה-Pods כך שיפעלו כשרתי proxy שמפנים בקשות כניסה נכנסות לשרת ה-webhook החיצוני. העיצוב הזה מאפשר לבצע משימות נוספות, כמו בדיקה ושינוי של בקשות הגישה.
    • ‫EndpointSlices: יוצרים את השירות בלי סלקטור, ואז מוסיפים ידנית EndpointSlice שממפה את השירות לכתובת ה-IP של שרת ה-webhook החיצוני. העיצוב הזה מנתב את התנועה בלי לשנות את הבקשות.

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

  • אימות ופרטי כניסה: כדאי לחשוב איך לבצע אימות בשרת ה-webhook החיצוני. בנוסף, תהליך העבודה של ניתוב התנועה צריך לנהל את האופן שבו פרטי הכניסה (כמו מפתחות API, אישורי mTLS וטוקנים של OAuth) מוחלים על חיבורים.
  • אבטחה ובקרת רשת: חשוב להביא בחשבון את שטח המתקפה של תכנון הניתוב ואת האפשרויות לאבטחה ולביקורת. העיצוב שתטמיעו משפיע על המגבלות שתוכלו להחיל על התנועה. לדוגמה, אפשר להשתמש ב-NetworkPolicies עם תרמילי proxy.
  • ניראות ואמינות: כדאי לחשוב איך לעקוב אחרי החיבורים. לדוגמה, אפשר להגדיר ש-Pods של proxy ישלחו מדדים, או להטמיע יכולת ניטור של רשתות עבור EndpointSlices.

גישה לצמתים ממקורות חיצוניים

בקטע הזה נסביר איך לבודד צמתים באשכול Kubernetes.

הפעלת צמתים פרטיים

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

אפשר להפעיל צמתים פרטיים ברמה של אשכול בודד או ברמה של מאגר הצמתים (במצב Standard) או עומס העבודה (במצב Autopilot). הפעלת צמתים פרטיים ברמת מאגר הצמתים או ברמת עומס העבודה מבטלת כל הגדרה של צמתים ברמת האשכול.

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

  • אשכולות ברשת VPC משותפת שבה לא מופעלת גישה פרטית ל-Google. מפעילים ידנית את הגישה הפרטית ל-Google כדי לוודא ש-GKE מוריד את קובץ האימג' של הצומת שהוקצה. במקרה של אשכולות שלא נמצאים ברשת VPC משותפת, GKE מפעיל באופן אוטומטי גישה פרטית ל-Google.

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

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

היתרונות של בידוד הרשת

אלה היתרונות של בידוד הרשת:

  • גמישות:

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

  • אבטחה:

    • נקודות קצה מבוססות-DNS עם VPC Service Controls מספקות מודל אבטחה רב-שכבתי שמגן על האשכול מפני רשתות לא מורשות וזהויות לא מורשות שניגשות למישור הבקרה. ‫VPC Service Controls משתלב עם יומני הביקורת של Cloud כדי לעקוב אחרי הגישה למישור הבקרה.
    • לא ניתן לגשת ישירות לצמתים פרטיים ולעומסי העבודה שפועלים בצמתים האלה מהאינטרנט הציבורי, ולכן הסיכון להתקפות חיצוניות על האשכול שלכם קטן משמעותית.
    • אתם יכולים לחסום גישה למישור הבקרה מCloud de Confiance כתובות IP חיצוניות או מכתובות IP חיצוניות כדי לבודד לחלוטין את מישור הבקרה של האשכול ולצמצם את החשיפה לאיומי אבטחה פוטנציאליים.
    • אתם יכולים להשבית את כתובות ה-IP החיצוניות של המכונות הווירטואליות במישור הבקרה כדי למנוע מהתוקפים להשתמש בכתובות ה-IP.

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

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

  • עלות: הפעלת צמתים פרטיים יכולה להפחית את העלויות של צמתים שלא נדרשת להם כתובת IP חיצונית כדי לגשת לשירותים ציבוריים באינטרנט.

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