אוטומציה של אבטחת Kubernetes: Kubesec ו-Kube-bench

Kubesec: מה מגלה ניתוח מניפסטים לפני פריסה לאשכול

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

הרשאות מיותרות של קונטיינר בדיף כמעט לא נראות: שורת securityContext או capability שנוספה נראות כמו הגדרה רגילה. בפועל, פוד כזה הופך לנקודת כניסה לצומת — דרך socket מורכב של סביבת ההרצה או מערכת הקבצים השורשית, ומשם בשרשרת ממשיכים טוקן של חשבון שירות ושרת ה-API.

לא פחות יקר — היעדר מגבלות. בלי requests ו-limits דליפת זיכרון אחת מפנה עומסי עבודה שכנים; בלי readOnlyRootFilesystem קוד שנטען לקונטיינר שורד הפעלה מחדש; automountServiceAccountToken כברירת מחדל מחדיר טוקן למקום שבו הוא לא נחוץ.

סקירה מפספסת זאת מסיבה מובנת: מניפסטים מגיעים מצ'ארטים, גנרטורים והעתק-הדבק, שינויים מגיעים בקבוצות, והבדיקה נשענת על תשומת הלב של מהנדס אחד. המהנדסים שלנו מתארים זאת כך: «מערך הליקויים חוזר ממהדורה למהדורה — משתנים רק שמות השירותים».

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

מה נותנת בדיקת אבטחה אוטומטית של האשכול

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

מה בדיוק נבדק אוטומטית

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

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

כיצד זה בא לידי ביטוי במהדורות

חלק הפריסות שמגיעות לאשכול בלי הערות תצורה עולה ל-9 מתוך 10: ממצאים קריטיים נתפסים בסקירת ההגדרות, ולא בפרודקשן. הניתוח עצמו מואץ — המהנדס מסתכל על דוח עם עדיפויות, ולא קורא מניפסט שורה אחר שורה.

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

גישות לבדיקה: Kubesec, השוואה לתקן, אכיפת מדיניות

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

ניתוח סטטי של הגדרות

Kubesec קורא תיאור YAML של פוד ומעריך את השדות שמהם נבנה הסיכון: מצב מיוחס, תיקיות מארח, היעדר readonly-rootfs, יכולות מיותרות. סף בצינור הבנייה חוסם מניפסט כזה לפני יישום, אך הבדיקה רואה רק את הקובץ עצמו — ערכי ברירת מחדל משרת ה-API והמצב בפועל של הצמתים נשארים מחוצה לה.

השוואה לדרישות תקן

kube-bench מריץ בדיקות לפי תקן CIS בנפרד לפי רכיבים — שרת API, kubelet, etcd — ומראה סטיות מהפרופיל הבסיסי. זוהי ביקורת בדיעבד: היא לא מונעת שינוי, אלא מתעדת שההגדרות סטו מהתקן, וחלק מהבדיקות דורשות גישה לקבצים ולתהליכים של הצומת.

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

כיצד בנוי תהליך הטמעת הבדיקות באשכול

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

הכנה: ספירת מלאי ותרשים

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

בדיקה על מהדורות אמיתיות

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

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

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

מדיניות וכללי אכיפה

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

תיעוד ונוהל תגובה

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

מקרה בוחן: כיצד השתנו המהדורות לאחר הטמעת הבדיקות

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

מה היה לפני ההטמעה

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

מה השתנה אחרי

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

אחרי חודשיים חלק הפריסות הפגומות ירד מ-24% ל-4%, מספר ההערות למהדורה — מתשע לשתיים, זמן הסקירה הצטמצם ל-10–15 דקות. החזרות לאחור הפכו בודדות, וניתוח תקלות תצורה חדל לדרוש פגישה נפרדת.

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

במה שונה Kubesec מ-Kube-bench ומתי נדרש כל אחד

Kubesec ו-Kube-bench מכסים אזורי כיסוי שונים של בדיקות. Kubesec קורא הגדרות של אובייקטים — YAML או תבנית Helm מרונדרת — ומעריך את מה שנראה לפני הפריסה: קונטיינרים מיוחסים, hostPath, securityContext, היעדר מגבלות משאבים. בפלט — הערכת סיכון ורשימת שורות ספציפיות שמפחיתות אותה.

Kube-bench בא מהצד השני: משווה את ההגדרות בפועל של צמתים פעילים ורכיבי בקרה לדרישות תקן ענפי. נבדקים פרמטרי הפעלה, הרשאות על קובצי תצורה, הגדרות kubelet, גישה למאגר המצב. מופעל כמשימה באשכול או ישירות על הצומת — כלומר משקף מציאות, ולא כוונה.

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

בחירת הכלי לפי המשימה נקבעת לפי סוג הכשל היקר יותר. לא להכניס סיכון לאשכול — מתחילים מ-Kubesec. לאשר עמידה בדרישות ולתפוס סחיפת תצורה — מ-Kube-bench. בפועל שניהם עומדים באותו תהליך: הראשון בודק את מה שאנחנו מתכוונים להעלות, השני — את מה שכבר עובד.

ספקות לגבי בדיקות אוטומטיות: עומס והתראות שווא

בדיקות אבטחה אוטומטיות פועלות בשתי נקודות: ניתוח מניפסטים לפני יישום והשוואת תצורת צמתים לפרופיל תקן (Kubesec ו-kube-bench). אלו סביבות שונות עם מחיר שונה לטעות, ולכן אין להפעיל אותן בשלב פריסה אחד.

בפועל ההטמעה נתקלת בארבע שאלות — מהתראות שווא ועד מי שמביא את ההערות לידי תיקון.

הבדיקות יאטו את תהליך הפריסה?

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

האם זה יעבוד על אשכול שכבר פרוס?

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

מי מתקן את מה שנמצא?

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

נדון במשימה ונחזור עם תוכנית בדיקות לאשכול

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

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

• מבהירים את המצב הנוכחי: היכן נמצאים המניפסטים, מי מבצע שינויים, והאם יש בקרה בשלב בניית האימג'.
• מנתחים דרישות: מדיניות אבטחה פנימית, תקנים ענפיים, חלון שינויים מותר בפרודקשן.
• מתאמים תוכנית בדיקות: Kubesec — מניפסטים ואימג'ים, kube-bench — הגדרות צמתים ושכבת בקרה; מה נכנס למערך מחייב ומה למצב תצפית.
• נותנים הערכת עבודות לפי שלבים: היקף, רצף, תלויות — בלי סעיפים נסתרים.
• מתארים את סדר שיתוף הפעולה: הרשאות ותפקידים, נוהל שינויים, נקודות תיאום, פורמט דיווח.
• מגדירים מסירת תוצאה: תצורות בדיקה במאגר שלכם, משולבות בצינור הבנייה, תיעוד לניתוח ממצאים.

תארו את המשימה — נחזור עם הערכה ותוכנית בדיקות לאשכול שלכם.