‫CIS Benchmarks

בדף הזה מתוארת הגישה של Google Kubernetes Engine‏ (GKE) לשיפור התאימות למדדי ההשוואה של Center for Internet Security‏ (CIS) ל-Kubernetes ול-GKE. הדף הזה כולל את המידע הבא:

  • איך אנחנו מגדירים את מישור הבקרה המנוהל של GKE כך שיתאים ל-CIS Kubernetes Benchmark
  • איך להגדיר את הצמתים ועומסי העבודה ב-GKE כך שיתאימו ל-CIS Google Kubernetes Engine (GKE) Benchmark

מידע על נקודות ההשוואה של CIS

ב-CIS מפרסמים את נקודות ההשוואה הבאות, שכוללות הנחיות להגדרה מאובטחת של Kubernetes:

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

מומלץ לתת עדיפות ל-CIS GKE Benchmark, כי הוא ספציפי ל-GKE ב- Google Cloud. ה-CIS Kubernetes Benchmark מכיל המלצות רבות לבקרות שאי אפשר לראות או לשנות ב-GKE. הגישה שלנו לאבטחת אשכולות כוללת אמצעי הגנה שחורגים מההיקף של נקודת ההשוואה של Kubernetes בקוד פתוח, ועלולים לגרום להתנגשויות עם ההמלצות האלה.

נקודות השוואה אחרות שרלוונטיות ל-GKE

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

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

מודל אחריות משותפת

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

  • מישור הבקרה, כולל המכונות הווירטואליות של מישור הבקרה, שרת ה-API ורכיבים כמו מסד הנתונים של מצב האשכול (מבוסס על etcd או Spanner),‏ kube-controller-manager ו-kube-scheduler.
  • מערכת ההפעלה של הצומת.

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

הגישה שלנו לאבטחת GKE בהתאם ל-CIS Benchmark

‫GKE הוא הטמעה מנוהלת של Kubernetes בקוד פתוח. אנחנו מנהלים באופן מלא את מישור הבקרה ואחראים לאבטחת ההגדרות של הרכיבים במישור הבקרה. בטבלה הבאה מתוארות כמה מההחלטות שלנו שעשויות להשפיע על הניקוד של נקודות ההשוואה של CIS:

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

‫GKE משבית את בקרי הגישה הבאים:

  • ‫EventRateLimit: תכונה בשלב אלפא ב-Kubernetes
  • ‫AlwaysPullImages: הבקר הזה מספק הגנה מסוימת לתמונות של מאגרים פרטיים באשכולות של ריבוי דיירים (multitenancy) לא שיתופיים, במחיר של הפיכת מאגרי התמונות לנקודת כשל בודדת ליצירת Pods חדשים באשכול.
  • ‫SecurityContextDeny: עדיף להשתמש ב-Pod Security Admission controller, שזמין בכל מהדורות GKE. אפשר גם לאכוף את תקני האבטחה של Pod באמצעות Policy Controller.
  • ‫ImagePolicyWebhook: כברירת מחדל, GKE משבית את ImagePolicyWebhook כי יש לו מנגנונים משלו לניהול תמונות ולאבטחה. כך GKE יכול לשמור על שליטה קפדנית יותר בסביבה ולוודא שנוהלי האבטחה מיושמים באופן עקבי. עם זאת, אתם יכולים להשתמש ב-Binary Authorization או ב-Policy Controller לניהול המדיניות.
רישום ביומן ביקורת ‫GKE מתעד יומני ביקורת באמצעות מדיניות הביקורת של GKE. לכן, אנחנו לא צריכים להגדיר דגלים של רישום ביומן ביקורת בשרת ה-API של Kubernetes.
ניפוי באגים ב-GKE, יצירת פרופילים משמשת לניפוי באגים.
הצפנה
etcd

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

  • ‫etcd: האשכול מריץ מכונות etcd במישור הבקרה.
  • ‫Spanner: ‏GKE שומר את מצב האשכול במסד נתונים שמבוסס על Spanner, בנפרד מהמכונות הווירטואליות של מישור הבקרה.

כל אשכולות GKE מפעילים את ה-API של etcd במכונות וירטואליות במישור הבקרה. כל האינטראקציות של הלקוח עם Kubernetes API זהות לאלה שבקוד הפתוח של Kubernetes. בהתאם לטכנולוגיית מסד הנתונים שמשמשת כקצה העורפי של ה-API של etcd באשכול, יכול להיות שתבחינו בפערים בניקוד שקשור ל-etcd ב-CIS Kubernetes Benchmark בקוד פתוח.
kubelet
  • ‫GKE מפעיל את יציאת kubelet לקריאה בלבד ללא אימות. כדי להשבית את היציאה, צריך להגדיר את --no-autoprovisioning-enable-insecure-kubelet-readonly-port. היציאה לקריאה בלבד תושבת כברירת מחדל בגרסה עתידית, אחרי שניתן לכם קצת זמן לבצע את ההעברה.
  • במצב GKE Standard, עומסי העבודה יכולים לשנות את ברירות המחדל של הליבה לפי הצורך.
  • כדי לצמצם את הסיכון להתקפות מסוג מניעת שירות (DoS), ב-GKE יש הגבלה על מספר האירועים של Kubernetes ב-kubelet.
  • ב-GKE משתמשים ב-mTLS כדי לאבטח את תעבורת הנתונים בין ה-kubelet לשרת ה-API.
  • כברירת מחדל, GKE מחליף את אישורי השרת, ומחליף את אישורי הלקוח כשמופעלים צומתי GKE מוגנים.
  • ‫GKE משתמש בקבוצת ההצפנות המותרות שמוגדרת כברירת מחדל ב-golang, שהיא גם ברירת המחדל של Kubernetes.

הערכת GKE בהשוואה לנקודות ההשוואה של CIS

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

  • ‫CIS GKE Benchmark:
    • מריצים את kube-bench כדי להעריך את צומתי העובדים ביחס להערכת הביצועים. לפרטים נוספים, ראו את מאגר kube-bench ב-GitHub.
    • אפשר להשתמש בכלי של צד שלישי כמו Twistlock Defender כדי להעריך את הצמתים בהשוואה לנקודת ההשוואה.
  • ‫CIS Kubernetes Benchmark: מריצים את kube-bench כדי להעריך את צומתי העובדים בהשוואה ל-Benchmark. אי אפשר להעריך את מישור הבקרה המנוהל בהשוואה להמלצות האלה ב-Benchmark.

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