במסמך הזה מוסבר איך להשתמש בסריקת מצב האבטחה של Kubernetes כדי למצוא סיכוני אבטחה ב-GKE ולצמצם אותם. המסמך הזה מניח שאתם מכירים את הנושאים הבאים:
התכונה 'בדיקת מצב האבטחה של Kubernetes' היא חלק ממרכז הבקרה של מצב האבטחה. היא עוזרת לכם לזהות ולטפל באופן יזום בפגיעויות אבטחה באשכולות של Google Kubernetes Engine (GKE). בדיקת מצב האבטחה של Kubernetes כוללת את התכונות הבאות:
המסמך מיועד למומחי אבטחה שעוקבים אחרי אשכולות כדי לזהות בעיות אבטחה. במאמר תפקידים ומשימות נפוצים של משתמשי GKE מפורטים תפקידים נפוצים ומשימות לדוגמה שמוזכרים בתוכן שלGoogle Cloud .
במאמר ביקורת אוטומטית של עומסי עבודה לאיתור בעיות בהגדרות האישיות מוסבר איך להפעיל את סריקת מצב האבטחה של Kubernetes ולהשתמש בה.
תמחור
השירות מוצע ללא תשלום נוסף ב-GKE.
רשומות שנוספות ל-Cloud Logging כפופות לתמחור של Cloud Logging.
מידע על ביקורת הגדרות של עומסי עבודה
לעומסי העבודה שפורסים ב-GKE צריכה להיות הגדרה מאובטחת שמגבילה את שטח הפנים להתקפה. יכול להיות שיהיה קשה לבדוק באופן ידני עומסי עבודה באשכולות שונים כדי לאתר בעיות בהגדרות האישיות, במיוחד בקנה מידה גדול. אתם יכולים להשתמש במרכז הבקרה של מצב האבטחה כדי לבדוק באופן אוטומטי את ההגדרות של כל עומסי העבודה שפועלים בכמה אשכולות, ולקבל תוצאות עם ניקוד והמלצות מעשיות לשיפור מצב האבטחה.
במסגרת ביקורת על הגדרות של עומסי עבודה, כל עומס עבודה שנפרס נבדק מול קבוצת משנה של כללי מדיניות בתקני אבטחת ה-Pod. בדיקת התצורה של עומסי העבודה מתבצעת בתשתית של Google, בלי להשתמש במשאבי המחשוב של הצמתים שלכם.
היתרונות של ביקורת על הגדרות עומס העבודה
- זיהוי אוטומטי של בעיות מוכרות בהגדרות בכל עומסי העבודה.
- קבלת המלצות פרקטיות לשיפור מצב האבטחה.
- אפשר להשתמש במסוף Google Cloud כדי לקבל תצוגה ברמה גבוהה של בעיות בהגדרות.
- להשתמש ב-Logging כדי לקבל נתיב של בעיות שניתן לבדוק, לדיווח ולניראות (observability) טובים יותר.
איך פועלת ביקורת הגדרות עומסי העבודה
בכל עומס עבודה מתאים שנפרס, GKE סורק באופן רציף את המפרט של עומס העבודה ומשווה את השדות והערכים לאמצעי הבקרה שמוגדרים במדיניות האבטחה הבסיסית. לדוגמה, Pod עם spec.containers.securityContext.privileged=true מפר את תקן האבטחה הבסיסי של Pod, ו-Pod עם השדה spec.securityContext.runAsNonRoot שמוגדר כ-false מפר את התקן המוגבל. רשימת מדיניות האבטחה שנבדקת ב-GKE מופיעה במאמר מה נבדק בביקורת על הגדרות עומס העבודה?.
אחרי הסריקה והגילוי של בעיות, GKE מדרג את חומרת הבעיות בהגדרות על סמך אמצעי האבטחה המובנים. GKE מקצה דירוג חומרה שיכול לעזור לכם להבין באיזו מהירות צריך להגיב לבעיה. במסוףGoogle Cloud יוצגו התוצאות והפעולות המומלצות לתיקון הבעיות. GKE גם מוסיף רשומות ל-Cloud Logging לצורך מעקב וביקורת.
מה נבדק בביקורת של הגדרות עומסי העבודה?
| בעיה | שדות | ערכים מותרים | חוּמרה |
|---|---|---|---|
מרחבי שמות של מארחים פודים שמשתפים מרחבי שמות של מארחים מאפשרים לתהליכים של פודים לתקשר עם תהליכים של מארחים ולאסוף מידע על המארחים, מה שעלול להוביל לפריצה בקונטיינר. |
|
|
גבוהה |
קונטיינרים עם הרשאות קונטיינרים עם הרשאות מאפשרים גישה כמעט בלתי מוגבלת למארח. הם חולקים מרחבי שמות עם המארח, ואין להם קבוצת בקרה, seccomp, AppArmor והגבלות יכולות. |
|
|
גבוהה |
גישה ליציאות של המארח חשיפת יציאת מארח לקונטיינר עלולה לאפשר לקונטיינר ליירט תנועה ברשת לשירות מארח באמצעות היציאה הזו, או לעקוף כללים של בקרת גישה לרשת, כמו הכללים ב-NetworkPolicy. |
|
|
גבוהה |
יכולות שלא מוגדרות כברירת מחדל לקונטיינר הוקצו יכולות שעלולות לאפשר פריצה בקונטיינר. |
|
|
בינוני |
העלאת נפחים של נתיבי מארח |
spec.volumes[*].hostPath |
לא מוגדר או ריק | בינוני |
מסכה סוג ההרכבה שמוגדר כברירת מחדל |
|
|
בינוני |
מסכת sysctls לא בטוחה אפשר להגדיר Pod כך שיאפשר שינוי של פרמטרים לא בטוחים של ליבת המערכת באמצעות מערכת הקבצים הווירטואלית |
spec.securityContext.sysctls[*].name |
|
בינוני |
הרצה כמשתמש לא-root אפשר לאפשר באופן מפורש לקונטיינר לפעול כמשתמש root אם ההנחיה |
|
true |
בינוני |
הרחבת הרשאות אפשר להגדיר קונטיינר באופן מפורש כדי לאפשר הסלמת הרשאות (privilege escalation) בזמן ההפעלה. ההרשאה הזו מאפשרת לתהליך שנוצר בתוך הקונטיינר להפעיל קובץ הרצה של set-user-id, set-group-id או יכולת קובץ, כדי לקבל את ההרשאות שצוינו בקובץ ההרצה. היעדר אמצעי בקרה למניעת פרצות אבטחה מגביר את הסיכון לפירצה בקונטיינר. |
|
false |
בינוני |
פרופיל AppArmor לא מוגבל אפשר להגדיר קונטיינר באופן מפורש כך שלא יהיה מוגבל על ידי AppArmor. ההגדרה הזו עוזרת לוודא שאף פרופיל AppArmor לא מוחל על הקונטיינר, ולכן הוא לא מוגבל על ידם. אמצעי הבקרה המניעתי לאבטחה מושבת, ולכן יש סיכון מוגבר לפירצה בקונטיינר. |
metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"] |
false |
נמוכה |
בנוסף, מערכת GKE בודקת אם יש RoleBindings או ClusterRoleBindings של RBAC שמפנים לאחד מהמשתמשים או הקבוצות הבאים:
system:anonymoussystem:authenticatedsystem:unauthenticated
אם קיימים קישורי RBAC שמפנים למשתמשים או לקבוצות האלה, בלוח הבקרה של מצב האבטחה מופיע ממצא בשם Effectively Anonymous Users Granted GKE Cluster Access ברמת חומרה Medium. המשתמשים והקבוצות האלה הם אנונימיים, ואסור להשתמש בהם ב-RoleBindings או ב-ClusterRoleBindings. איך נמנעים מתפקידים ומקבוצות שמוגדרים כברירת מחדל
מידע על הצגת עדכוני אבטחה דחופים
כשמתגלה נקודת חולשה ב-GKE, אנחנו מתקנים אותה ומפרסמים עדכון אבטחה דחוף לגביה. במאמר תיקוני אבטחה ב-GKE מוסבר איך מזהים את הבעיות, איך מתקנים אותן ומהם לוחות הזמנים.
בלוח הבקרה של מצב האבטחה מוצגים עדכוני אבטחה דחופים שמשפיעים על האשכולות, עומסי העבודה ומאגרי הצמתים במצב רגיל. התכונה הזו היא חלק מהיכולת מצב אבטחה של Kubernetes של לוח הבקרה של מצב האבטחה, והיא מופעלת באופן אוטומטי כשיוצרים אשכול Autopilot או Standard. כדי להפעיל סריקה של מצב האבטחה ב-Kubernetes, פועלים לפי ההוראות במאמר ביקורת אוטומטית של עומסי עבודה כדי לזהות בעיות בהגדרות.
במסוף Google Cloud מוצגים פרטים כמו האשכולות והגרסאות שמושפעים, וגרסאות התיקון המומלצות לשדרוג כדי לצמצם את נקודת החולשה. אתם רואים רק הודעות על בעיות שיש פתרון לבעיה באזור או באזור הזמינות של האשכול שלכם Google Cloud .
כדי לראות את העדכונים לגבי אשכולות שרשמתם לסריקת מצב האבטחה של Kubernetes, היכנסו למרכז הבקרה של מצב האבטחה:
כל עדכון אבטחה דחוף שמשפיע על הסביבה שלכם מופיע בקטע Security bulletins.