הגדרת Kubernetes Policy Engine (OPA Gatekeeper/Kyverno)

Kubernetes policy engine: היכן נשברים כללי הגישה

Kubernetes policy engine נדרש במקומות שבהם כללי הגישה לאשכול חיים בהתכתבות ובראשו של התורן, ולא במדיניות הצהרתית.

כל עוד הבדיקות נשענות על אנשים, סחיפת תצורות האשכול בלתי נמנעת: מישהו הסיר מגבלות משאבים, מישהו עשה mount ל-volume privileged, מישהו פרס image ללא label — וכל זה הגיע לפרודקשן.

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

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

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

מה משתנה אחרי הטמעה: מהירויות, דחיות, בקרת גישה

לפני הטמעת מדיניות, שגיאות תצורה נתפסות בשלושה מקומות: ב-review של manifests, בזמן deploy וכבר בפרודקשן — על ידי התורן בלילה. היקר ביותר הוא השלישי: אובייקט בלי readiness probes או עם resource requests מנופחים עובר לאשכול, מפיל שכנים על אותו node, והזמן השבתה נספר בדיעבד.

מנוע מדיניות ל-Kubernetes מעביר את הבדיקות לכניסה, לפני יצירת האובייקט. כללים ב-Kyverno מתוארים באופן דקלרטיבי ונמצאים באותו repository כמו האפליקציות, לכן נוסעים בין סביבות יחד עם הקוד. Manifest שמפר כללים לא מקבל admission — סוג הדחייה «תצורה שבורה» מיורט לפני הפרודקשן.

Review מפסיק להיות צוואר בקבוק. דרישות טיפוסיות — מגבלות משאבים, labels, network policies, איסור containers privileged — נבדקות על ידי המנוע, והאדם מסתכל על לוגיקת השינוי.

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

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

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

השוואת גישות: מנגנונים מובנים של Kubernetes ומנועים חיצוניים

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

מנועי מדיניות חיצוניים (OPA Gatekeeper, Kyverno) מוסיפים את מה שחסר למובנה: כללים כקוד, ניהול גרסאות, סט אחיד לכמה אשכולות ומצבי בדיקה. זו לא תחליף אלא תוספת — הבקרה המובנית נשארת במקום.

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

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

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

1. אינוונטריזציה של עומסים. אוספים לפי namespaces מי יוצר pods, עם אילו הרשאות, איפה משתמשים ב-hostPath וב-privileged, אילו resource requests לא הוגדרו. בפלט — מפה של מה שבאמת חי באשכול, ולא של מה שמתואר בתיעוד.
2. סכמת מדיניות. מתוך האינוונטריזציה נוצרת רשימת כללים עם עדיפויות: חובה לאבטחה, מומלצים להיגיינת משאבים, חריגים ל-namespaces מערכתיים. מתאמים ניסוחים לפני כתיבת templates — עריכת טקסט זולה מעריכת קוד.
3. הגדרת כללים. מממשים templates של מגבלות ואובייקטי מדיניות: selectors של namespaces, אזורי חריגים, מצבי אזהרה וחסימה. הגדרת כללי גישה לאשכול הולכת יחד איתם, כדי שמפתח יקבל הודעת דחייה ברורה עם הפניה לנוהל.
4. בדיקה בסביבת סטנד. מריצים את המדיניות במצב אזהרות על עותק של האשכול ועל היסטוריית manifests, מנתחים דוח ביקורת: כמה הפרות, איפה false positives. אחר כך מעבירים למצב חוסם כלל אחד בכל פעם, עם rollback מהיר.
5. מסירת נהלים. מוסרים תיאור של המדיניות והסיבות להיווצרותן, סדר הוספת חריגים, פעולות התורן בעת דחיית admission, מדדים והתראות על בריאות ה-controllers. בהמשך הצוות מתחזק את הכללים בעצמו.

ארטיפקטים נמסרים: תצורות, סכמות, נהלים

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

• תצורות מדיניות — לכל כלל: מה אסור או חובה, תחומי פעולה, רמת תגובה (אזהרה או חסימה) והסבר קצר של הסיבה, שמוצג בטקסט הדחייה.
• סכמות גישה — מפה של roles באשכול, service accounts ואזורי ההשפעה שלהם: רואים מי רשאי לשנות מדיניות ומי רק לקרוא.
• מטריצת חריגים — טבלה «כלל / תחום / מועד / בעלים»: הקלות זמניות לעומסים בירושה עם תאריך בדיקה מחייבת.
• תיעוד כללים — ספרייה אחידה: ניסוח, נימוק, סדר הסרה ואחראי לכל מגבלה.
• הוראות לצוותים — איך מפתח קורא הודעת דחייה, מה לתקן ב-manifest ובאיזו צורה לבקש עקיפה.
• נוהל שינוי מדיניות — מי מאשר עריכה, איך היא רצה בסביבת בדיקה ואיך מבצעים rollback לגרסה הקודמת של הסט.
• דוח ריצה ראשונית — אילו כללים מופעלים על העומסים הנוכחיים ומה צריך לתקן לפני העברתם למצב חוסם.

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

מקרה בוחן: איך צמצמנו הפרות מדיניות בשחרור שינויים

לפני: הבקרה נשענה על review ידני

ארבעים מהנדסים בשנים עשר צוותים עשו deploy שינויים לאשכול משותף, והכללים חיו כמסמך וצ'קליסט ב-review לפני merge. הבדיקה הייתה סלקטיבית: לפרודקשן הגיעו containers בלי requests/limits, images עם tag מרחף במקום tag מקובע ו-pods עם הרשאות יתר. לפי סטטיסטיקה פנימית — חמש־שבע הפרות כאלה בחודש, וכל אחת צפה כבר ברגע התקרית, לא בכניסה.

אחרי: בדיקה בכניסה לאשכול

הטמענו מנוע מדיניות Kyverno כנקודת admission לאובייקטים: הוא מיירט manifest לפני כתיבה לאשכול, או מכניס אותו, או דוחה אותו בציון השדה המדויק והכלל שהופעל. המדיניות נמצאת ב-git לצד manifests ועוברת אותו review, וה-build pipeline מריץ אותן מראש — המהנדס רואה הפרה לפני merge.

חלק האובייקטים שנבדקים אוטומטית עלה מדגם של ~20% ל-100% בכניסה. ההפרות שהגיעו לפרודקשן ירדו מחמש־שבע בחודש לאחת־שתיים, וגם הן — מחריגים מאושרים.

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

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

במה שונה validation מ-mutation בעת שינוי אובייקט

Validation עונה על השאלה «אפשר להכניס אובייקט לאשכול», mutation — «באיזו צורה הוא יגיע לשם». כלל validation קורא את ה-manifest כולו, או מכניס אותו, או דוחה אותו עם סיבה ברורה: אין owner, לא הוגדרו limits, image מ-registry לא מהימן. את האובייקט עצמו הוא לא משנה — הפסיקה נשארת צפויה ומשוחזרת בשליחה חוזרת.

Mutation עובדת לפני שמירת האובייקט: מוסיפה או כותבת מחדש שדות — שמה labels לפי convention, מכניסה מגבלות משאבים כברירת מחדל, מפעילה policies אבטחה נדרשות. תופעת לוואי — פער בין מה שהמהנדס כתב בקובץ לבין מה שבאמת חי באשכול.

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

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

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

חריגים לצוותים מסוימים ניתנים ממוקד — לפי label של namespace, עם בעלים ומועד, ולא «לנצח לכולם»: אחרת מנוע מדיניות ב-Kubernetes מאבד מהר משמעות ומתחילים לעקוף אותו.

ספקות טכניים: תאימות, עומס, rollback

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

איך המדיניות משפיעה על העומס באשכול?

הבדיקה מתווספת בשלב ה-admission של האובייקט — כלומר שברי שנייה ורק ביצירה או שינוי של משאב. Cache ומספר סביר של כללים מחזיקים את התרומה בתוך אחוזים בודדים ממשאבי ה-control nodes; מודדים לפני ואחרי בפרופיל שיא.

איך עושים rollback למדיניות אם היא מפריעה לשחרור?

את המדיניות שומרים ב-repository ומיישמים אוטומטית: rollback הוא החזרת המצב הקודם של התצורה, דקות ובלי עריכות ידניות באשכול. בנוסף חריג חירום לפי label על namespace, כדי לשחרר את הצוות עד לבירור.

מי אחראי לכללים אחרי ההטמעה?

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

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

כדי שההערכה תהיה עניינית ולא «ממוצע בתעשייה», די לנו בתיאור המצב הנוכחי: כמה אשכולות בעבודה ומי מנהל את שכבת הניהול, איך מופרדים סביבות ו-namespaces, אילו בדיקות כבר פועלות — admission controllers מובנים, webhooks משלכם או אישורים ידניים לפני deploy. כדאי לדעת גם את הצד השני: אילו כללים עוקפים היום ולמה צוותים מבקשים חריגים.

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

• ניתוח המצב הנוכחי: איפה הבדיקות כבר קיימות, איפה עוקפים אותן, אילו משאבים ו-namespaces יהיה צריך להוציא לחריגים.
• היקף העבודה: רשימת מדיניויות — containers privileged, מגבלות משאבים, labels חובה, כללי רשת — והמצב שבו כל אחת מופעלת.
• סדר ההפעלה: קודם ביקורת עם דוח הפרות, אחר כך חסימה לפי רשימה מוסכמת, כדי שהשחרורים לא ייעצרו ביום הראשון.
• פיילוט בסטנד: פורסים את מנוע המדיניות בסביבת בדיקה, מעבירים חלק מהכללים, מסתכלים על זרם הדחיות וה-false positives.
• לוחות זמנים להטמעה לפי שלבים: סטנד, ביקורת, חסימה, מסירה לתפעול — עם נקודה ברורה שאחריה אפשר לעצור.
• מה נשאר אצל הצוות שלכם: repository עם המדיניות, סכמת חריגים, סדר rollback והוראות לתורנים.

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