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

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

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

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

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

שיטה מומלצת:

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

גישה למישור הבקרה

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

לכל אשכול GKE יש מישור בקרה שמטפל בבקשות של Kubernetes API. מישור הבקרה פועל במכונה וירטואלית (VM) שנמצאת ברשת VPC בפרויקט שמנוהל על ידי Google. באשכול אזורי יש כמה רפליקות של מישור הבקרה, וכל אחת מהן פועלת ב-VM משלה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

טרמינולוגיה שקשורה לאשכולות ולכתובות IP

  • Google Cloud כתובות IP חיצוניות:

    • כתובות IP חיצוניות שמוקצות לכל מכונה וירטואלית שבה משתמש לקוח כלשהו שמתארח ב-Google Cloud. Google Cloud הן בבעלות של איפה אפשר למצוא טווחי כתובות IP של Compute Engine?

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

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

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

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

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

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

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

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

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

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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

גישה לרשת של האשכול

בקטע הזה נסביר איך לבודד צמתים באשכול 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 כדי לעקוב אחרי הגישה למישור הבקרה.
    • לא ניתן לגשת ישירות לצמתים פרטיים ולעומסי העבודה שפועלים בצמתים האלה מהאינטרנט הציבורי, ולכן הסיכון להתקפות חיצוניות על האשכול שלכם קטן משמעותית.
    • אתם יכולים לחסום גישה למישור הבקרה מGoogle Cloud כתובות IP חיצוניות או מכתובות IP חיצוניות כדי לבודד לחלוטין את מישור הבקרה של האשכול ולהפחית את החשיפה לאיומי אבטחה פוטנציאליים.

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

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

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

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