‫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 כוללת הרבה המלצות לבקרות שאי אפשר לראות או לשנות ב-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. האסימונים האלה נוצרים בכל פעם שמכונת VM מופעלת או מופעלת מחדש.
בקרי אישור בקשות

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

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

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

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

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

הערכת GKE בהשוואה ל-CIS Benchmarks

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

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

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