ריבוי דיירים באשכול

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

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

מהי ארכיטקטורת Multi-tenancy?

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

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

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

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

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

  • הפחתת תקורה ניהולית
  • צמצום הפיצול של המשאבים
  • אין צורך להמתין ליצירת אשכול לדיירים חדשים

תרחישים לדוגמה לשימוש ב-Multi-tenancy

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

ריבוי דיירים ב-Enterprise

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

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

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

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

ריבוי דיירים אצל ספק SaaS

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

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

אכיפת מדיניות של דירות שותפים

‫GKE ו-Kubernetes מספקים כמה תכונות שאפשר להשתמש בהן כדי לנהל אשכולות מרובי דיירים. בקטעים הבאים מופיעה סקירה כללית של התכונות האלה.

בקרת גישה

ל-GKE יש שתי מערכות בקרת גישה: ניהול זהויות והרשאות גישה (IAM) ובקרת גישה מבוססת-תפקידים (RBAC). ‫IAM היא מערכת בקרת הגישה של Cloud de Confianceלניהול אימות והרשאות למשאבים ב- Cloud de Confiance. משתמשים ב-IAM כדי להעניק למשתמשים גישה למשאבי GKE ולמשאבי Kubernetes. ‫RBAC מובנה ב-Kubernetes ומעניק הרשאות מפורטות למשאבים ולפעולות ספציפיות באשכולות.

מידע נוסף על האפשרויות האלה ומתי כדאי להשתמש בכל אחת מהן זמין במאמר סקירה כללית על בקרת גישה.

במאמרים מדריך לשימוש ב-RBAC ומדריך לשימוש ב-IAM מוסבר איך להשתמש במערכות האלה לבקרת גישה.

אתם יכולים להשתמש בהרשאות IAM ו-RBAC יחד עם מרחבי שמות כדי להגביל את האינטראקציות של המשתמשים עם משאבי האשכול במסוף Cloud de Confiance . מידע נוסף זמין במאמר הפעלת גישה למשאבי אשכולות והצגתם לפי מרחב שמות.

כללי מדיניות הרשת

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

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

כדי ללמוד איך לכתוב כללי מדיניות לרשת, אפשר לעיין במדריך בנושא מדיניות לרשת.

מכסות משאבים

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

מידע נוסף מופיע במאמר בנושא מכסות משאבים.

בקרת גישה ל-Pod שמבוססת על מדיניות

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

‫GKE תומך בסוגים הבאים של בקרת כניסה:

  • ‫Policy Controller: הצהרה על מדיניות מוגדרת מראש או מותאמת אישית ואכיפה שלה באשכולות בקנה מידה גדול באמצעות fleets. ‫Policy Controller הוא הטמעה של Gatekeeper open policy agent בקוד פתוח, והוא תכונה של GKE Enterprise.
  • PodSecurity admission controller: אכיפה של מדיניות מוגדרת מראש שתואמת לתקני אבטחת ה-Pod באשכולות נפרדים או במרחבי שמות ספציפיים.

אנטי-זיקה של Pod

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

אפשר להשתמש ב-Pod anti-affinity כדי למנוע תזמון של Pods מדיירים שונים באותו צומת. הגבלות אנטי-אפיניות מבוססות על תוויות של Pod. לדוגמה, מפרט ה-Pod שבהמשך מתאר Pod עם התווית "team": "billing", וכלל נגד זיקה שמונע את התזמון של ה-Pod לצד Pods ללא התווית.

apiVersion: v1
kind: Pod
metadata:
  name: bar
  labels:
    team: "billing"
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: "kubernetes.io/hostname"
        labelSelector:
          matchExpressions:
          - key: "team"
            operator: NotIn
            values: ["billing"]

החיסרון בטכניקה הזו הוא שמשתמשים זדוניים יכולים לעקוף את הכלל על ידי החלת התווית team: billing על Pod שרירותי. אי אפשר לאכוף מדיניות בצורה מאובטחת באשכולות עם דיירים לא מהימנים רק באמצעות תכונת ה-anti-affinity של ה-Pod.

מידע נוסף מופיע במאמר בנושא Pod anti-affinity.

צמתים ייעודיים עם דחיות (taints) וטולרנטיות

הכתמים של הצמתים הם דרך נוספת לשלוט בתזמון של עומסי העבודה. אפשר להשתמש ב-taints של צמתים כדי לשריין צמתים מיוחדים לשימוש של דיירים מסוימים. לדוגמה, אפשר להקצות צמתים עם GPU לדיירים ספציפיים שעומסי העבודה שלהם דורשים GPU. ב-Autopilot clusters, תמיכה ב-node tolerations זמינה רק עבור workload separation. הקצאת צמתים אוטומטית (NAP) מוסיפה באופן אוטומטי דחיות (taints) של צמתים לפי הצורך.

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

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

מידע נוסף זמין במאמר בנושא Taints and Tolerations במאמרי העזרה של Kubernetes.

GKE Sandbox

‫GKE Sandbox מספק שכבת אבטחה נוספת לאשכולות מרובי דיירים, על ידי בידוד עומסי עבודה לא מהימנים מליבת המארח בצמתי האשכול. ‫GKE Sandbox משתמש ב-gVisor, טכנולוגיית ארגז חול (sandbox) של קונטיינרים בקוד פתוח, כדי לספק ליבת סביבת משתמש נפרדת לכל Pod.

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

ניהול זיכרון של דירות שותפים

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

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

משאבי GPU ו-TPU רגילים לא מנקים באופן אוטומטי את הזיכרון שלהם (HBM), את ה-SRAM או את רגיסטרי הבקרה בין הקצאות של Pod. יכול להיות שיישארו נתונים משאריות של עומס עבודה קודם בזיכרונות של המאיץ. אם לא מפעילים מחדש את ה-VM בין עומסי העבודה, התצורה מתאימה רק לריבוי דיירים מהימן, שבו כל עומסי העבודה שמתוזמנים באותו מאיץ חולקים את אותה רגישות אבטחה.

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

שיתוף מאיצים כמו GPU ו-TPU

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

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

ארכיטקטורה שטח ההתקפה הראשי סיכום אבטחה
תאי Pod באותו צומת חולקים ישירות מאיץ, כולל שיתוף זמן של GPU ו-NVIDIA MPS. זיכרון GPU ומצב גלובלי הפודים פגיעים זה לזה, והם צריכים להיות מהימנים זה לזה.
ל-Pods באותו צומת יש גישה ישירה למאיץ והם משתמשים ב-GKE Sandbox, כולל שיתוף זמן ב-GPU ו-NVIDIA MPS. זיכרון GPU ומנהל התקן של המארח ‫GKE Sandbox מבודד את ליבת עומס העבודה מליבת המארח. למרות ש-gVisor מצמצם את שטח הפנים של ה-GPU שחשוף לאפליקציה, הוא לא מספק הפרדה בתוך סביבת ה-GPU, שנשארת משותפת. מידע נוסף זמין במאמר תמיכה ב-GPU – אבטחה.
ל-Pods באותו צומת יש מאיצים ייעודיים, כולל NVIDIA MIG. ליבת המארח (דרך מנהל ההתקן) יכול להיות שעדיין תהיה פריצה ל-Pods בגלל נקודות חולשה במאיץ או במנהל ההתקן שמאפשרות הסלמה לליבת המארח.
ל-Pods באותו צומת יש מאיצים ייעודיים, כולל NVIDIA MIG, והם משתמשים ב-GKE Sandbox. ממשק מנהל ההתקן של המארח (nvproxy) GKE Sandbox מבודד את הליבה, אבל ממשק מנהל ההתקן של המארח ל-GPU ‏ (nvproxy) נשאר שטח התקפה משותף. ניצול לרעה של מנהל התקן עשוי לאפשר חדירה לליבת המארח. יכול להיות גם שיהיו דליפות בערוץ הצדדי בין מופעים של MIG.
כל Pod פועל בצומת ייעודי עם מאיצים ייעודיים. גבולות המכונה הווירטואלית / Hypervisor מומלץ לעומסי עבודה לא מהימנים. כל פריצה מוגבלת למכונה וירטואלית אחת.

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