סקירה כללית על אבטחה ב-GKE

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

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

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

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

אימות והרשאה

‫Kubernetes תומך בשני סוגים של אימות:

  1. חשבונות משתמש הם חשבונות שמוכרים ל-Kubernetes, אבל לא מנוהלים על ידי Kubernetes. לדוגמה, אי אפשר ליצור או למחוק אותם באמצעות kubectl.
  2. חשבונות שירות הם חשבונות שנוצרים ומנוהלים על ידי Kubernetes, אבל אפשר להשתמש בהם רק על ידי ישויות שנוצרו על ידי Kubernetes, כמו קבוצות Pod.

באשכול של GKE, חשבונות משתמשים ב-Kubernetes מנוהלים על ידי Google Cloud, ויכולים להיות אחד משני הסוגים הבאים:

  1. חשבון Google
  2. Google Cloud חשבון שירות

אחרי האימות, צריך לתת הרשאה לזהויות האלה ליצור, לקרוא, לעדכן או למחוק משאבי Kubernetes.

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

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

לקבלת מידע נוסף:

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

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

מערכת הפעלה שמותאמת לקונטיינרים

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

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

צמתים של GKE Autopilot תמיד משתמשים במערכת הפעלה שמותאמת לקונטיינרים.

שדרוגים של צמתים

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

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

הגנה על צמתים מפני עומסי עבודה לא מהימנים

במקרה של אשכולות שמריצים עומסי עבודה לא ידועים או לא מהימנים, מומלץ להגן על מערכת ההפעלה בצומת מפני עומס העבודה הלא מהימן שפועל ב-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 במרחב שמות באמצעות מדיניות רשת. כברירת מחדל, כשלא מוגדרים כללי מדיניות של רשת, כל תעבורת הנתונים הנכנסת (ingress) ותעבורת הנתונים היוצאת (egress) יכולה להיכנס לכל קבוצות ה-Pod ולצאת מהן. כללי מדיניות של רשת מאפשרים לכם להשתמש בתגים כדי להגדיר את התנועה שזורמת דרך קבוצות ה-Pod.

אחרי שמחילים מדיניות רשת במרחב שמות, כל התנועה אל ומ-Pods שלא תואמים לתוויות שהוגדרו מושמטת. במסגרת יצירת אשכולות או מרחבי שמות, אפשר להחיל דחייה של תנועה כברירת מחדל על תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) של כל Pod, כדי לוודא שכל עומסי העבודה החדשים שנוספים לאשכול יצטרכו לאשר באופן מפורש את התנועה שהם צריכים.

לקבלת מידע נוסף:

סינון תנועה עם איזון עומסים

כדי לבצע איזון עומסים של קבוצות Pod ב-Kubernetes באמצעות מאזן עומסים ברשת, צריך ליצור שירות מסוג LoadBalancer שתואם לתוויות של קבוצת ה-Pod. אחרי שיוצרים את השירות, מקבלים כתובת IP חיצונית שממפה ליציאות ב-Pods של Kubernetes. סינון תנועה מורשית מתבצע ברמת הצומת על ידי kube-proxy, שמסנן על סמך כתובת ה-IP.

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

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

מידע נוסף זמין במדריך לאיזון עומסים פנימי.

סינון תנועה מחוץ לאשכול

כדי לשלוט בזרימת תעבורת הרשת בין ישויות חיצוניות לבין האשכול, משתמשים ב-Cloud Next Generation Firewall. אתם יכולים להשתמש בהגדרות של חומת אש כדי לחסום תעבורה יוצאת מה-Pods ליעדים לא מאושרים, למשל.

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

אבטחת עומסי העבודה

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

הגבלת ההרשאות לתהליכי Pod בקונטיינרים

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

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

  • משתמש וקבוצה להרצה בתור
  • יכולות Linux זמינות
  • יכולת להרחיב את ההרשאות

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

מערכות ההפעלה של צומתי GKE, ‏ Container-Optimized OS ו-Ubuntu, מחילות את מדיניות האבטחה של Docker AppArmor כברירת מחדל על כל הקונטיינרים שמופעלים על ידי Kubernetes. אפשר לראות את תבנית הפרופיל ב-GitHub. בין היתר, הפרופיל מונע מהקונטיינרים את היכולות הבאות:

  • כתיבת קבצים ישירות ב-/proc/
  • כתיבה לקבצים שלא נמצאים בספרייה עם מזהה תהליך (/proc/<number>)
  • כתיבה לקבצים ב-/proc/sys שאינם /proc/sys/kernel/shm*
  • טעינת מערכות קבצים

לקבלת מידע נוסף:

מתן גישה ל-Pods למשאבים Google Cloud

יכול להיות שהקונטיינרים וה-Pods שלכם יצטרכו גישה למשאבים אחרים ב-Google Cloud. יש שלוש דרכים לעשות זאת.

הדרך המאובטחת ביותר להעניק הרשאה ל-Pods לגשת ל Google Cloud משאבים היא באמצעות איחוד זהויות של עומסי עבודה ל-GKE. איחוד זהויות של עומסי עבודה ל-GKE מאפשר להריץ חשבון שירות של Kubernetes בתור חשבון שירות של IAM. לפודים שפועלים כחשבון שירות של Kubernetes יש את ההרשאות של חשבון השירות ב-IAM.

אפשר להשתמש באיחוד זהויות של עומסי עבודה ל-GKE עם GKE Sandbox.

חשבון שירות של צומת

באשכולות רגילים, אפשר גם לאמת את ה-Pods ב-Google Cloud באמצעות פרטי הכניסה של חשבון השירות שבו נעשה שימוש במכונה הווירטואלית (VM) של הצומת ב-Compute Engine.

הגישה הזו לא תואמת ל-GKE Sandbox כי GKE Sandbox חוסם את הגישה לשרת המטא-נתונים של Compute Engine.

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

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

שימוש ב-Binary Authorization

‫Binary Authorization הוא שירות ב-Google Cloud שמספק אבטחה לשרשרת האספקה של תוכנות לאפליקציות שפועלות בענן. Binary Authorization פועל עם קובצי אימג' של קונטיינרים שאתם פורסים ב-GKE מ-Artifact Registry או ממאגר אחר של קובצי אימג' של קונטיינרים.

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

בעזרת אימות רציף (CV) של Binary Authorization, אתם יכולים לוודא שקובצי אימג' של קונטיינרים שמשויכים ל-Pods נבדקים באופן קבוע כדי לוודא שהם עומדים בדרישות של התהליכים הפנימיים שלכם.

רישום ביומן ביקורת

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

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

לקבלת מידע נוסף:

אמצעי אבטחה מובנים

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

שגיאות קבלה שנגרמות בגלל המדיניות הזו דומות לשגיאות הבאות:

GKE Warden rejected the request because it violates one or more constraints.

אמצעי אבטחה של אשכולות ב-Autopilot

ב-Autopilot clusters מוחלות כמה הגדרות אבטחה שמבוססות על המומחיות שלנו ועל השיטות המומלצות בתחום. פרטים נוספים זמינים במאמר בנושא אמצעי אבטחה ב-Autopilot.

אמצעי אבטחה סטנדרטיים של אשכולות

אשכולות רגילים הם יותר מתירניים כברירת מחדל מאשכולות של Autopilot. באשכולות GKE Standard יש את הגדרות האבטחה הבאות:

  • אי אפשר לעדכן את ServiceAccount שמשמש עומסי עבודה של מערכת שמנוהלים על ידי GKE, כמו עומסי עבודה במרחב השמות kube-system.
  • אי אפשר לקשר את cluster-admin ברירת המחדל של ClusterRole לקבוצות system:anonymous, system:unauthenticated או system:authenticated.