Google Kubernetes Engine (GKE) מספק הרבה דרכים לעזור לכם לאבטח את עומסי העבודה. הגנה על עומסי עבודה ב-GKE כוללת הרבה שכבות של המערכת, כולל התוכן של קובץ אימג' של קונטיינר, זמן הריצה של הקונטיינר, רשת האשכולות והגישה לשרת ה-API של האשכול.
מומלץ להשתמש בגישה רב-שכבתית כדי להגן על האשכולות ועומסי העבודה. אתם יכולים להחיל את העיקרון של הרשאות מינימליות על רמת הגישה שניתנת למשתמשים ולאפליקציה. בכל שכבה, יכול להיות שהארגון שלכם יצטרך להתפשר על דברים שונים כדי לאפשר את הרמה הנכונה של גמישות ואבטחה, וכך לפרוס ולתחזק את עומסי העבודה בצורה מאובטחת. לדוגמה, יכול להיות שהגדרות אבטחה מסוימות מגבילות מדי את הפעולה של סוגים מסוימים של אפליקציות או תרחישי שימוש, כך שנדרש ארגון הקוד מחדש משמעותי כדי שהן יפעלו.
במסמך הזה מפורטת סקירה כללית של כל שכבה בתשתית, ומוסבר איך אפשר להגדיר את אמצעי האבטחה שלה כך שיתאימו לצרכים שלכם.
המסמך הזה מיועד למומחי אבטחה שמגדירים, מנהלים ומטמיעים מדיניות ונהלים כדי להגן על הנתונים של הארגון מפני גישה לא מורשית. כדי לקבל מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם ב Cloud de Confiance by S3NS תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשי GKE ומשימות.
אימות והרשאה
Kubernetes תומך בשני סוגים של אימות:
- חשבונות משתמשים הם חשבונות שמוכרים ל-Kubernetes, אבל לא מנוהלים על ידי Kubernetes. לדוגמה, אי אפשר ליצור או למחוק אותם באמצעות
kubectl. - חשבונות שירות הם חשבונות שנוצרים ומנוהלים על ידי Kubernetes, אבל אפשר להשתמש בהם רק על ידי ישויות שנוצרו על ידי Kubernetes, כמו קבוצות Pod.
באשכול GKE, חשבונות המשתמשים של Kubernetes מנוהלים על ידי Cloud de Confiance by S3NS, ויכולים להיות אחד משני הסוגים הבאים:
אחרי האימות, צריך לתת לזהויות האלה הרשאה ליצור, לקרוא, לעדכן או למחוק משאבים ב-Kubernetes.
למרות השמות הדומים, חשבונות שירות של Kubernetes ו Cloud de Confiance חשבונות שירות הם ישויות שונות. חשבונות שירות של Kubernetes הם חלק מהאשכול שבו הם מוגדרים, ובדרך כלל משתמשים בהם באשכול הזה. לעומת זאת,Cloud de Confiance חשבונות שירות הם חלק מפרויקט Cloud de Confiance , ואפשר לתת להם בקלות הרשאות בתוך אשכולות, לאשכולות של הפרויקט עצמו Cloud de Confiance ולכל משאב של Cloud de Confiance באמצעות ניהול זהויות והרשאות גישה (IAM). לכן, לחשבונות שירות של Cloud de Confiance יש יותר הרשאות מאשר לחשבונות שירות של Kubernetes. כדי לפעול לפי העיקרון של הרשאות מינימליות, כדאי להשתמש בחשבונות שירות של Cloud de Confiance רק כשצריך את היכולות שלהם.
כדי להגדיר גישה מפורטת יותר למשאבי Kubernetes ברמת האשכול או במרחבי שמות של Kubernetes, משתמשים בבקרת גישה מבוססת-תפקידים (RBAC). RBAC מאפשר ליצור מדיניות מפורטת שמגדירה לאילו פעולות ומשאבים משתמשים וחשבונות שירות יכולים לגשת. באמצעות RBAC, אתם יכולים לשלוט בגישה לחשבונות Google, לחשבונות שירות ולחשבונות שירות של Kubernetes. Cloud de Confiance כדי לפשט ולייעל עוד יותר את אסטרטגיית האימות וההרשאה שלכם ב-GKE, חשוב לוודא שבקרת הגישה מבוססת-המאפיינים מדור קודם מושבתת, כך ש-Kubernetes RBAC ו-IAM יהיו מקורות האמת.
מידע נוסף:
- קוראים את מאמרי העזרה בנושא RBAC ב-GKE.
- במאמר אימות לשרת ה-API של Kubernetes מוסבר על שיטות האימות הנתמכות כשמתחברים לשרת ה-API של Kubernetes.
אבטחה במישור הבקרה
ב-GKE, Google מנהלת ומתחזקת את הרכיבים של מישור הבקרה של Kubernetes. הרכיבים של מישור הבקרה מארחים את התוכנה שמריצה את מישור הבקרה של Kubernetes, כולל שרת ה-API, המתזמן, מנהל הבקרים ו-etcd API. אם האשכול מריץ מופעים של מסד הנתונים etcd במכונות וירטואליות של מישור הבקרה, Google גם מנהלת ומתחזקת את המופעים האלה.
אפשר לגשת למישור הבקרה באמצעות נקודת קצה מבוססת DNS (מומלץ), נקודות קצה מבוססות IP או שניהם. אם אתם משתמשים בנקודות קצה שמבוססות על IP, אתם יכולים להגן על שרת ה-API של Kubernetes באמצעות רשתות מורשות ולא להפעיל את נקודת הקצה החיצונית של מישור הבקרה. כך תוכלו להקצות כתובת IP פנימית למישור הבקרה ולהשבית את הגישה לכתובת ה-IP החיצונית. אם אתם משתמשים בנקודת קצה (endpoint) שמבוססת על DNS, אתם יכולים להשתמש ב-IAM וב-VPC Service Controls כדי לאבטח את הגישה למישור הבקרה באמצעות מדיניות שמבוססת על זהות ומדיניות שמבוססת על רשת.
אתם יכולים לטפל באימות של אשכולות ב-Google Kubernetes Engine באמצעות IAM כספק הזהויות. למידע על אימות, קראו את המאמר אימות לשרת Kubernetes API.
דרך נוספת לאבטח את מישור הבקרה היא לוודא שאתם מבצעים רוטציית פרטי כניסה באופן קבוע. כשמתחילה רוטציית פרטי כניסה, מתבצעת רוטציה של אישורי ה-SSL ושל רשות האישורים של האשכול. התהליך הזה מתבצע באופן אוטומטי על ידי GKE, והוא גם עוזר לוודא שכתובת ה-IP של מישור הבקרה מתחלפת.
מידע נוסף:
- מידע נוסף על אבטחת מישור הבקרה
- קוראים את המסמכים בנושא בקרת גישה מבוססת-תפקידים.
- פועלים לפי המדריך לרוטציית פרטי כניסה.
אבטחת הצומת
GKE פורס את עומסי העבודה במכונות של Compute Engine שפועלות בפרויקט ב- Cloud de Confiance . המופעים האלה מצורפים לאשכול GKE בתור צמתים. בקטעים הבאים מוסבר איך להשתמש באמצעי האבטחה ברמת הצומת שזמינים ב- Cloud de Confiance.
מערכת הפעלה שמותאמת לקונטיינרים
כברירת מחדל, צומתי GKE משתמשים במערכת ההפעלה שמותאמת לקונטיינרים של Google כמערכת ההפעלה שבה מריצים את Kubernetes ואת הרכיבים שלו. במערכת הפעלה שמותאמת לקונטיינרים יש כמה תכונות מתקדמות שמשפרות את האבטחה של אשכולות GKE, כולל:
- חומת אש נעולה
- מערכת קבצים לקריאה בלבד, אם אפשר
- חשבונות משתמשים מוגבלים והתחברות בסיסית מושבתת
צמתים של GKE Autopilot תמיד משתמשים במערכת הפעלה שמותאמת לקונטיינרים כמערכת ההפעלה.
שדרוגים של צמתים
מומלץ לתקן את מערכת ההפעלה באופן קבוע. מעת לעת, בעיות אבטחה בזמן הריצה של הקונטיינר, ב-Kubernetes עצמה או במערכת ההפעלה של הצומת עשויות לחייב אתכם לשדרג את הצמתים בדחיפות רבה יותר. כשמשדרגים את הצומת, התוכנה של הצומת משודרגת לגרסאות העדכניות שלה.
אשכולות GKE תומכים בשדרוגים אוטומטיים. באשכולות Autopilot, שדרוגים אוטומטיים תמיד מופעלים. אפשר גם לשדרג ידנית את הצמתים באשכול Standard.
הגנה על צמתים מפני עומסי עבודה לא מהימנים
באשכולות שבהם פועלים עומסי עבודה לא ידועים או לא מהימנים, מומלץ להגן על מערכת ההפעלה בצומת מפני עומס העבודה הלא מהימן שפועל ב-Pod.
לדוגמה, אשכולות עם כמה דיירים, כמו ספקי תוכנה כשירות (SaaS), מריצים לעיתים קרובות קוד לא ידוע שנשלח על ידי המשתמשים שלהם. מחקר אבטחה הוא עוד אפליקציה שבה עומסי העבודה עשויים לדרוש בידוד חזק יותר מזה שהצמתים מספקים כברירת מחדל.
אתם יכולים להפעיל את GKE Sandbox באשכול כדי לבודד עומסי עבודה לא מהימנים בארגזי חול בצומת. GKE Sandbox מבוסס על gVisor, פרויקט קוד פתוח.
מטא-נתונים מאובטחים של מופעים
GKE משתמש במטא-נתונים של מכונות ממכונות Compute Engine הבסיסיות כדי לספק לצמתים פרטי כניסה והגדרות שמשמשים לאתחול צמתים ולחיבור למישור הבקרה. המטא-נתונים האלה מכילים מידע רגיש שהפודים בצומת לא צריכים גישה אליו, כמו המפתח של חשבון השירות של הצומת.
אפשר לנעול נתיבים רגישים של מטא-נתונים של מופעים באמצעות איחוד זהויות של עומסי עבודה ל-GKE.
איחוד זהויות של עומסי עבודה ל-GKE מאפשר להשתמש בשרת המטא-נתונים של GKE באשכול, שמסנן בקשות לשדות רגישים כמו kube-env.
איחוד זהויות של עומסי עבודה ל-GKE תמיד מופעל באשכולות Autopilot. באשכולות Standard, לפודים יש גישה למטא-נתונים של המכונה, אלא אם מפעילים באופן ידני את איחוד הזהויות של עומסי עבודה ל-GKE.
אבטחת רשת
רוב עומסי העבודה שפועלים ב-GKE צריכים לתקשר עם שירותים אחרים שיכולים לפעול בתוך האשכול או מחוצה לו. יש כמה שיטות שונות שבהן אפשר להשתמש כדי לקבוע איזו תנועה תעבור דרך האשכולות וה-Pods שלהם.
הגבלת התקשורת בין Pods
כברירת מחדל, אפשר להגיע לכל ה-Pods באשכול דרך הרשת באמצעות כתובת ה-IP של ה-Pod. באופן דומה, כברירת מחדל, תעבורת נתונים יוצאת מאפשרת חיבורים יוצאים לכל כתובת שאפשר לגשת אליה ב-VPC שבו נפרס האשכול.
אדמינים ומשתמשים של אשכולות יכולים לנעול את חיבורי הכניסה והיציאה שנוצרו אל Pods ומ-Pods במרחב שמות, באמצעות מדיניות רשת ב-Kubernetes. כברירת מחדל, אם לא מוגדרות כללי מדיניות רשת ב-Kubernetes, כל תעבורת הנתונים הנכנסת (ingress) והיוצאת (egress) יכולה לזרום אל כל קבוצות ה-Pod ומחוצה להן. מדיניות רשת ב-Kubernetes מאפשרת לכם להשתמש בתגים כדי להגדיר את תעבורת הנתונים שעוברת דרך קבוצות ה-Pod.
אחרי שמחילים מדיניות רשת ב-Kubernetes במרחב שמות, כל התנועה אל ומ-Pods שלא תואמים לתוויות שהוגדרו נחסמת. במסגרת יצירת אשכולות או מרחבי שמות, אפשר להחיל דחייה של תעבורת נתונים כברירת מחדל על תעבורת נתונים נכנסת ותעבורת נתונים יוצאת של כל Pod, כדי לוודא שכל עומסי העבודה החדשים שנוספים לאשכול צריכים לאשר באופן מפורש את התעבורה שהם דורשים.
מידע נוסף:
- מידע נוסף על מדיניות רשת ב-Kubernetes
- פועלים לפי המדריך למדיניות הרשת ב-Kubernetes
- מידע נוסף על כללי מדיניות ברירת המחדל
סינון תנועה מאוזנת עומסים
כדי לבצע איזון עומסים של קבוצות Pod ב-Kubernetes באמצעות מאזן עומסים ברשת, צריך ליצור שירות מסוג LoadBalancer שתואם לתוויות של קבוצת ה-Pod. אחרי שיוצרים את השירות, מקבלים כתובת IP חיצונית שממופה ליציאות ב-Pods של Kubernetes. סינון תנועה מורשית מתבצע ברמת הצומת באמצעות kube-proxy, שמסנן לפי כתובת IP.
כדי להגדיר את הסינון הזה, אתם יכולים להשתמש בהגדרה loadBalancerSourceRanges של אובייקט השירות. פרמטר ההגדרה הזה מאפשר לספק רשימה של טווחי CIDR שרוצים לאפשר להם גישה לשירות. אם לא מגדירים את
loadBalancerSourceRanges, כל הכתובות יכולות לגשת לשירות דרך כתובת ה-IP החיצונית שלו.
במקרים שבהם לא נדרשת גישה חיצונית לשירות, כדאי להשתמש במאזן עומסים פנימי.
מאזן העומסים הפנימי גם מכבד את loadBalancerSourceRanges כשצריך לסנן תנועה מתוך ה-VPC.
למידע נוסף, עיינו במדריך לאיזון עומסים פנימי.
סינון תנועה מחוץ לאשכול
כדי לשלוט בזרימת תעבורת הרשת בין ישויות חיצוניות לבין האשכול, משתמשים ב-Cloud Next Generation Firewall. אתם יכולים להשתמש בהגדרות של חומת האש כדי לחסום תעבורה יוצאת מה-Pods ליעדים לא מאושרים, למשל.
הגדרות חומת האש לא מספיקות כדי לשלוט במאגרי הרישום שמהם מגיעים קובצי האימג' של הקונטיינרים באשכול. כדי להגביל את משיכת קובצי האימג' של קונטיינרים לקבוצה של מאגרי רישום מאושרים, קראו את המאמר חסימת קובצי אימג' של קונטיינרים ממאגרי רישום לא מאושרים.
אבטחת עומסי העבודה
Kubernetes מאפשר למשתמשים להקצות, לשנות את קנה המידה ולעדכן במהירות עומסי עבודה מבוססי-קונטיינרים. בקטע הזה מתוארות טקטיקות שאדמינים ומשתמשים יכולים להשתמש בהן כדי להגביל את ההשפעה של מאגר פעיל על מאגרים אחרים באותו אשכול, על הצמתים שבהם מאגרים יכולים לפעול ועל Cloud de Confianceהשירותים שמופעלים בפרויקטים של המשתמשים.
הגבלת ההרשאות לתהליכים של Pod בקונטיינר
חשוב להגביל את ההרשאות של תהליכים בקונטיינרים כדי לשמור על האבטחה הכוללת של האשכול. אשכולות GKE Autopilot תמיד מגבילים הרשאות ספציפיות, כמו שמתואר במאמר יכולות האבטחה של Autopilot.
ב-GKE אפשר גם להגדיר אפשרויות שקשורות לאבטחה באמצעות הקשר האבטחה גם ב-Pods וגם בקונטיינרים. ההגדרות האלה מאפשרות לכם לשנות את הגדרות האבטחה של התהליכים, למשל:
- משתמש וקבוצה להרצה בתור
- היכולות הזמינות של Linux
- יכולת להרחיב הרשאות
כדי לאכוף את ההגבלות האלה ברמת האשכול ולא ברמת ה-Pod או הקונטיינר, צריך להשתמש בבקר PodSecurityAdmission. אדמינים של אשכולות יכולים להשתמש ב-PodSecurityAdmission כדי לוודא שכל ה-Pods באשכול או במרחב שמות עומדים בדרישות של מדיניות מוגדרת מראש בתקני אבטחת ה-Pods.
מערכות ההפעלה של צומתי GKE, גם מערכת הפעלה שמותאמת לקונטיינרים וגם Ubuntu, מחילות את מדיניות האבטחה של Docker AppArmor שמוגדרת כברירת מחדל על כל הקונטיינרים שמופעלים על ידי Kubernetes. אפשר לראות את תבנית הפרופיל ב-GitHub. בין היתר, הפרופיל מונע מהקונטיינרים את היכולות הבאות:
- כתיבת קבצים ישירות ב-
/proc/ - כתיבה לקבצים שלא נמצאים בספרייה עם מזהה תהליך (
/proc/<number>) - כתיבה בקבצים ב-
/proc/sysשאינם/proc/sys/kernel/shm* - טעינת מערכות קבצים
מידע נוסף:
- למאמרי העזרה בנושא הקשר האבטחה של Pod
- מידע נוסף על אמצעי ההגנה הקיימים זמין במסמכי התיעוד של AppArmor במערכת ההפעלה שמותאמת לקונטיינרים.
מתן גישה ל-Pods Cloud de Confiance למשאבים
יכול להיות שהקונטיינרים וה-Pods שלכם יצטרכו גישה למשאבים אחרים ב-Cloud de Confiance. יש שלוש דרכים לעשות את זה.
איחוד זהויות של עומסי עבודה ל-GKE (מומלץ)
הדרך הכי מאובטחת לאשר לפודים לגשת למשאבי Cloud de Confiance היא באמצעות איחוד זהויות של עומסי עבודה ל-GKE. איחוד זהויות של עומסי עבודה ל-GKE מאפשר להריץ חשבון שירות של Kubernetes בתור חשבון שירות של IAM. לפודים שפועלים כחשבון השירות של Kubernetes יש את ההרשאות של חשבון השירות ב-IAM.
אפשר להשתמש באיחוד זהויות של עומסי עבודה ל-GKE עם GKE Sandbox.
חשבון שירות של צומת
באשכולות Standard, הפודים יכולים גם לאמת אתCloud de Confiance באמצעות פרטי הכניסה של חשבון השירות שמשמש את המכונה הווירטואלית (VM) של Compute Engine של הצומת.
הגישה הזו לא תואמת ל-GKE Sandbox כי GKE Sandbox חוסם את הגישה לשרת המטא-נתונים של Compute Engine.
מפתח JSON של חשבון שירות (לא מומלץ)
אתם יכולים לתת לאפליקציות פרטי כניסה למשאבים של Cloud de Confiance באמצעות המפתח של חשבון השירות. לא מומלץ להשתמש בגישה הזו כי קשה לנהל מפתחות לחשבון בצורה מאובטחת.
אם אתם בוחרים בשיטה הזו, השתמשו בחשבונות שירות מותאמים אישית של IAM לכל אפליקציה, כדי שלאפליקציות יהיו ההרשאות המינימליות הנדרשות. מקצים לכל חשבון שירות את תפקידי ה-IAM המינימליים שנדרשים כדי שהאפליקציה המקבילה שלו תפעל בהצלחה. כשמשתמשים בחשבונות שירות ספציפיים לאפליקציה, קל יותר לבטל את הגישה במקרה של פריצה, בלי להשפיע על אפליקציות אחרות. אחרי שמקצים לחשבון השירות את התפקידים הנכונים ב-IAM, אפשר ליצור מפתח JSON לחשבון השירות, ואז לצרף את המפתח ל-Pod באמצעות Secret של Kubernetes.
רישום ביומן ביקורת
יומני ביקורת מאפשרים לאדמינים לשמור, לשלוח שאילתות, לעבד ולקבל התראות לגבי אירועים שמתרחשים בסביבות GKE. אדמינים יכולים להשתמש במידע שנרשם ביומן כדי לבצע ניתוח משפטי, לקבל התראות בזמן אמת או לקטלג את אופן השימוש בצי של אשכולות GKE ואת המשתמשים בהם.
כברירת מחדל, יומני Admin Activity נרשמים ב-GKE. אפשר גם לתעד אירועים של גישה לנתונים, בהתאם לסוגי הפעולות שרוצים לבדוק.
מידע נוסף:
אמצעי אבטחה מובנים
ב-GKE יש הגבלות ספציפיות על הפעולות שאפשר לבצע באובייקטים של המערכת באשכולות. כשמבצעים פעולה כמו יצירה או תיקון של עומס עבודה, webhook של אישור בקשות בשם warden-validating מאמת את הבקשה מול קבוצה של פעולות מוגבלות ומחליט אם לאשר את הבקשה.
שגיאות קבלה שנגרמות בגלל המדיניות הזו דומות לשגיאות הבאות:
GKE Warden rejected the request because it violates one or more constraints.
אמצעי אבטחה של אשכולות ב-Autopilot
אשכולות של Autopilot מחילים הגדרות אבטחה רבות על סמך המומחיות שלנו והשיטות המומלצות בתחום. פרטים נוספים מופיעים במאמר אמצעי אבטחה ב-Autopilot.