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 , וגם לכל Cloud de Confiance משאב באמצעות ניהול זהויות והרשאות גישה (IAM). בגלל זה, Cloud de Confiance חשבונות שירות הם חזקים יותר מחשבונות שירות של Kubernetes. כדי לפעול בהתאם לעקרון האבטחה של הרשאות מינימליות, מומלץ להשתמש בחשבונות שירות רק כשנדרשות היכולות שלהם. Cloud de Confiance
כדי להגדיר גישה מפורטת יותר למשאבי Kubernetes ברמת האשכול או במרחבי שמות של Kubernetes, משתמשים בבקרת גישה מבוססת-תפקידים (RBAC). RBAC מאפשר ליצור מדיניות מפורטת שמגדירה לאילו פעולות ומשאבים משתמשים וחשבונות שירות יכולים לגשת. באמצעות RBAC, אפשר לשלוט בגישה לחשבונות Google, Cloud de Confiance לחשבונות שירות ולחשבונות שירות של Kubernetes. כדי לפשט ולייעל עוד יותר את אסטרטגיית האימות וההרשאה שלכם ב-GKE, כדאי לוודא שבקרת הגישה מבוססת-מאפיינים מדור קודם מושבתת, כך ש-RBAC של Kubernetes ו-IAM יהיו מקורות האמת.
לקבלת מידע נוסף:
- קוראים את התיעוד בנושא GKE RBAC.
- במאמר אימות לשרת Kubernetes API מוסבר על שיטות האימות הנתמכות כשמתחברים לשרת Kubernetes API.
אבטחה של מישור הבקרה
ב-GKE, רכיבי מישור הבקרה של Kubernetes מנוהלים ומתוחזקים על ידי Google. רכיבי מישור הבקרה מארחים את התוכנה שמפעילה את מישור הבקרה של Kubernetes, כולל שרת ה-API, מתזמן, מנהל הבקרה ו-etcd API. אם האשכול מריץ מופעים של מסד הנתונים etcd במכונות וירטואליות של מישור הבקרה, Google גם מנהלת ומתחזקת את המופעים האלה.
אפשר לגשת למישור הבקרה באמצעות נקודת קצה מבוססת DNS (מומלץ), נקודות קצה מבוססות IP או שניהם. אם משתמשים בנקודות קצה מבוססות-IP, אפשר להגן על שרת ה-API של Kubernetes באמצעות רשתות מורשות ולא להפעיל את נקודת הקצה החיצונית של מישור הבקרה. כך תוכלו להקצות כתובת IP פנימית למישור הבקרה ולהשבית את הגישה בכתובת ה-IP החיצונית. אם אתם משתמשים בנקודת קצה מבוססת 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 הבסיסיות כדי לספק לצמתים פרטי כניסה והגדרות שמשמשים לאתחול צמתים ולחיבור למישור הבקרה. המטא-נתונים האלה מכילים מידע רגיש שאין צורך להעניק לו גישה ל-Pods בצומת, כמו מפתח חשבון השירות של הצומת.
אפשר לנעול נתיבים רגישים של מטא-נתונים של מופעים באמצעות איחוד זהויות של עומסי עבודה ל-GKE.
איחוד זהויות של עומסי עבודה ל-GKE מאפשר להשתמש בשרת המטא-נתונים של GKE באשכול, שמסנן בקשות לשדות רגישים כמו kube-env.
איחוד זהויות של עומסי עבודה ל-GKE תמיד מופעל באשכולות Autopilot. באשכולות רגילים, ל-Pods יש גישה למטא-נתונים של המופע, אלא אם מפעילים באופן ידני את איחוד הזהויות של עומסי עבודה ל-GKE.
אבטחת רשת
רוב עומסי העבודה שפועלים ב-GKE צריכים לתקשר עם שירותים אחרים שיכולים לפעול בתוך האשכול או מחוצה לו. אתם יכולים להשתמש בכמה שיטות שונות כדי לקבוע איזו תנועת גולשים מורשית לעבור דרך האשכולות וה-Pods שלהם.
הגבלת התקשורת בין Pods
כברירת מחדל, אפשר להגיע לכל ה-Pods באשכול דרך הרשת באמצעות כתובת ה-IP של ה-Pod. באופן דומה, כברירת מחדל, תעבורת נתונים יוצאת מאפשרת חיבורים יוצאים לכל כתובת שאפשר לגשת אליה ב-VPC שבו האשכול נפרס.
אדמינים ומשתמשים של אשכולות יכולים לנעול את החיבורים הנכנסים והיוצאים שנוצרו אל ומתוך ה-Pods במרחב שמות באמצעות מדיניות רשת. כברירת מחדל, אם לא מוגדרים כללי מדיניות של רשת, כל תעבורת הנתונים הנכנסת והיוצאת יכולה להיכנס לכל קבוצות ה-Pod ולצאת מהן. כללי מדיניות של רשת מאפשרים לכם להשתמש בתגים כדי להגדיר את התנועה שזורמת דרך קבוצות ה-Pod.
אחרי שמחילים מדיניות רשת במרחב שמות, כל התנועה מבוטלת אל ומ-Pods שלא תואמים לתוויות שהוגדרו. במסגרת יצירת אשכולות או מרחבי שמות, אפשר להחיל דחייה של תעבורת נתונים כברירת מחדל על תעבורת נתונים נכנסת ויוצאת של כל Pod, כדי לוודא שכל עומסי העבודה החדשים שנוספים לאשכול יצטרכו לאשר באופן מפורש את התעבורה שהם צריכים.
לקבלת מידע נוסף:
- מידע נוסף על מדיניות הרשת
- פועלים לפי ההדרכה בנושא המדיניות בנושא התנהלות פוגעת ברשת
- מידע נוסף על מדיניות ברירת המחדל
סינון תנועה עם איזון עומסים
כדי לבצע איזון עומסים של קבוצות 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 באשכול או במרחב שמות עומדים בדרישות של מדיניות מוגדרת מראש בתקני האבטחה של Pod.
מערכות ההפעלה של צומתי GKE, גם מערכת הפעלה שמותאמת לקונטיינרים וגם Ubuntu, מחילות את מדיניות האבטחה של Docker AppArmor כברירת מחדל על כל הקונטיינרים שמופעלים על ידי Kubernetes. אפשר לראות את תבנית הפרופיל ב-GitHub. בין היתר, הפרופיל מונע מהקונטיינרים את היכולות הבאות:
- כתיבת קבצים ישירות ב-
/proc/ - כתיבה לקבצים שלא נמצאים בספרייה עם מזהה תהליך (
/proc/<number>) - כתיבה לקבצים ב-
/proc/sysחוץ מ-/proc/sys/kernel/shm* - טעינת מערכות קבצים
לקבלת מידע נוסף:
- קוראים את התיעוד בנושא Pod Security Context.
- מידע נוסף על אמצעי ההגנה הקיימים זמין במסמכי התיעוד של AppArmor במערכת הפעלה שמותאמת לקונטיינרים.
מתן גישה ל-Pods למשאבים Cloud de Confiance
יכול להיות שהקונטיינרים וה-Pods שלכם יצטרכו גישה למשאבים אחרים ב-Cloud de Confiance. יש שלוש דרכים לעשות זאת.
איחוד זהויות של עומסי עבודה ל-GKE (מומלץ)
הדרך הכי מאובטחת להעניק הרשאה ל-Pods לגשת ל Cloud de Confiance משאבים היא באמצעות איחוד זהויות של עומסי עבודה ל-GKE. איחוד זהויות של עומסי עבודה ל-GKE מאפשר להריץ חשבון שירות של Kubernetes בתור חשבון שירות של IAM. לפודים שפועלים כחשבון השירות של Kubernetes יש את ההרשאות של חשבון השירות ב-IAM.
אפשר להשתמש באיחוד זהויות של עומסי עבודה ל-GKE עם GKE Sandbox.
חשבון שירות של צומת
באשכולות רגילים, אפשר גם לאמת את ה-Pods ב-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 ואת המשתמשים בהם.
כברירת מחדל, GKE רושם ביומן את פעילות האדמין. אפשר גם לרשום ביומן אירועים של גישה לנתונים, בהתאם לסוגי הפעולות שאתם רוצים לבדוק.
לקבלת מידע נוסף:
אמצעי אבטחה מובנים
ב-GKE יש הגבלות ספציפיות על הפעולות שאפשר לבצע באובייקטים של המערכת באשכולות. כשמבצעים פעולה כמו יצירה או תיקון של עומס עבודה, webhook של הרשאה בשם warden-validating מאמת את הבקשה מול קבוצה של פעולות מוגבלות ומחליט אם לאשר את הבקשה.
שגיאות קבלה שנגרמות בגלל המדיניות הזו דומות לשגיאות הבאות:
GKE Warden rejected the request because it violates one or more constraints.
אמצעי אבטחה של אשכולות במצב טייס אוטומטי
ב-Autopilot clusters מוחלות כמה הגדרות אבטחה שמבוססות על המומחיות שלנו ועל השיטות המומלצות בתחום. פרטים נוספים מופיעים במאמר בנושא אמצעי אבטחה ב-Autopilot.