מדיניות כקוד ב-Kubernetes: הגדרת OPA Gatekeeper

OPA ומדיניות כקוד: היכן תצורות האשכול מתפצלות

כללי גישה, מגבלות משאבים ודרישות לתוויות (labels) לעיתים רחוקות יושבים במקום אחד. חלקם שוקעים ב-manifests, חלקם בהרשאות של roles, וחלקם בהתכתבות: «בסביבה הזו זה מקובל, אל תיגע». כל עוד האשכול אחד, ההסכמות נשענות על הזיכרון של המהנדסים ועל ה-review שמבצע אותו אדם שהגה אותן.

ברגע שיש כמה סביבות, התצורות מתחילות להתפצל. באשכול הבדיקות מישהו הרים pod עם הרשאות privileged כדי לבדוק השערה מהר יותר, ושכח להסיר אותו; לפרודקשן נכנס container בלי הגבלת זיכרון; בסביבת הפרה-פרודקשן רוככו כללי הרשת לצורך דיבאג. סחיפת תצורות (drift) אינה נראית בלוחות הניטור — היא מתגלה ברגע האירוע.

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

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

מה נותן ניהול מדיניות כקוד: האפקטים

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

Open Policy Agent עם Gatekeeper בודק את האובייקטים בכניסה לאשכול, ולכן מקור הכללים הוא אחד לכל הסביבות — הפער בין סביבת הבדיקות לסביבת הפרודקשן נעלם לא בזכות תשומת הלב של המהנדסים, אלא מבנית.

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

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

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

מצבי העבודה של OPA Gatekeeper: audit, חסימה, תיקון אוטומטי

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

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

סדר ההדלקה משאיר אפשרות חזרה בכל שלב: אפשר להחזיר כלל מדחייה לאזהרה בלי להסיר את הבדיקה מהאשכול.

סדר ההטמעה של מדיניות: מ-audit ועד מסירה

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

1. מלאי משאבים. אוספים פרוסה של האשכול: אילו אובייקטים נוצרים, על ידי מי ועם אילו labels. המקורות — audit log של שרת ה-API ו-manifests מ-git.

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

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

4. הדלקה הדרגתית של איסורים. קודם סביבות לא-פרודקשן, אחר כך פרודקשן — לפי namespace, לא הכול בבת אחת. חריגים מאושרים מנסחים כרשימות מפורשות, ולא בכיבוי הכלל כולו.

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

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

מארז האספקה: מדיניות, סכמות, נהלים, דוחות

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

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

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

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

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

מה היה לפני

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

מה שינינו

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

התוצאה

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

במה Gatekeeper נבדל מאמצעים מובנים של האשכול

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

המגבלה של המובנה היא בצרות ובאי-החלוקה: כלל אחד מבטא תנאי אחד. דרישה מורכבת (image רק מ-registry מהימן, labels חובה של בעלים, איסור על mount של נתיבי host) אין במה לתאר — היא מכוסה ב-review ידני או שמשלימים עם החור. סט הכללים מועתק בין אשכולות ידנית, והפערים מצטברים בלי שמבחינים.

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

Gatekeeper מוציא את הכללים אל מחוץ ל-controllers: המדיניות מתוארת דקלרטיבית, נשמרת ב-repository לצד ה-manifests ומיושמת כסט אחד על כל האשכולות.

ה-audit בודק גם אובייקטים קיימים — הפער נראה לפני האירוע; פרמטרים (registries מהימנים, labels חובה) מוציאים בנפרד, ולכן מדיניות אחת עובדת גם בסביבת הבדיקות וגם בסביבת הפרודקשן.

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

ספקות טכניים נפוצים לפני ההטמעה

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

איך הבדיקות משפיעות על אפליקציות פעילות?

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

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

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

מה יהיה עם התחזוקה אחרי המסירה?

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

נדון במשימה: audit מדיניות ותוכנית הטמעה

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

• מלאי אשכולות: distribution, ה-branch הנוכחי, מספר ה-namespaces ועומסי העבודה;
• manifests או charts של פריסה — מספיק קישור ל-repository;
• רשימת המדיניות שפועלת כעת: review, הסכמות ידניות או admission controller;
• רשימת החריגים — namespaces מערכתיים, עומסים עם הרשאות privileged, operators;
• דרישות למצב: היכן נדרש רק audit של הפרות והיכן חסימה;
• roles ואופן הגישה לשכבת הניהול של האשכול;
• חלונות זמנים שבהם מותרים שינויים בסביבת הפרודקשן.

נדייק את גבולות העבודה: אילו דרישות מעבירים לתבניות constraint של OPA, מה מריצים קודם במצב audit, מי הבעלים של החריגים ואיך הפרות צפות ב-build לפני ההעלאה. בנפרד נדבר על היכן המדיניות חיה ב-repository ואיך השינוי שלה עובר review — אחרת כעבור חודש הכללים יתנתקו מהמציאות.

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