מעבר מ-PodSecurityPolicy אל בקרת הכניסה PodSecurity

בדף הזה מוסבר איך להמשיך לאכוף אמצעי בקרה רבים ברמת ה-Pod באשכולות Google Kubernetes Engine ‏ (GKE) על ידי מעבר מ-PodSecurityPolicy אל בקרת הכניסה PodSecurity.

סקירה כללית

‫PodSecurityPolicy היה בקר כניסה של Kubernetes שאיפשר לאכוף אמצעי בקרה לאבטחת Pod, כמו תקני האבטחה של Kubernetes Pod, וסיפק שליטה פרטנית בהגדרת האבטחה של עומסי העבודה שנפרסו. הפרויקט Kubernetes הוציא משימוש את PodSecurityPolicy והסיר את התכונה לגמרי ב-Kubernetes v1.25.

אם אתם משתמשים כרגע ב-PodSecurityPolicy באשכולות GKE, כדאי להשבית את התכונה לפני שמשדרגים לגרסה 1.25 של GKE או לגרסאות מאוחרות יותר.

מידע נוסף על הוצאה משימוש והסרה של PodSecurityPolicy זמין במאמר הוצאה משימוש של PodSecurityPolicy.

‫PodSecurity ו-PodSecurityPolicy

אמצעי אישור הבקשות PodSecurity זמין ומופעל כברירת מחדל באשכולות שמריצים את הגרסאות הבאות של GKE:

  • גרסה 1.25 ואילך: יציבה
  • גרסה 1.23 וגרסה 1.24: בטא

‫PodSecurity מאפשר לאכוף את המדיניות שמוגדרת בתקנים לאבטחת Pod בעומסי העבודה שפרסתם. ‫PodSecurity מאפשר לכם להמשיך להטמיע הגדרות אבטחה מומלצות ברמת ה-Pod באשכולות שלכם אחרי המעבר מ-PodSecurityPolicy. בניגוד ל-PodSecurityPolicy, ‏ PodSecurity לא תומך בהגדרות בהתאמה אישית.

דרישות ומגבלות

  • ‫PodSecurity זמין בגרסת בטא ב-GKE מגרסה 1.23 ומגרסה 1.24, ובגרסה יציבה ב-GKE מגרסה 1.25 ואילך.
  • ‫PodSecurity לא מפסיק את הפעלת ה-Pods שכבר פועלים בצמתים, גם אם הם מפרים את המדיניות שחלה עליהם.
  • ‫PodSecurity לא משנה שדות. אם אתם משתמשים בשדות משתנים ב-PodSecurityPolicy, אתם צריכים לשנות את מפרט ה-Pod כדי לוודא שהשדות האלה קיימים כשאתם פורסים את עומסי העבודה.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • מוודאים שיש לכם אשכול GKE Autopilot או Standard בגרסה 1.23 ואילך.
  • בודקים את המשאבים של PodSecurityPolicy כדי לשנות את ההגדרות של השדות. מוסיפים את השדות האלה למניפסטים של ה-Pod כדי שעומסי עבודה שכבר פועלים בצמתים יתאימו למדיניות שמוגדרת בתקני אבטחת ה-Pod. להוראות, עיין ב-פישוט ותקנון של מדיניות אבטחת Pod.

הגדרת בקרת הכניסה של PodSecurity באשכול

בקרת הכניסה PodSecurity אוכפת את תקני האבטחה של ה-Pod ברמת מרחב השמות. צריך להגדיר את בקר הגישה כך שיאכוף בכל מרחב שמות אחת מהמדיניות שהוגדרה בתקני האבטחה של ה-Pod. אלה המדיניות וההנחיות שזמינות:

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

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

  1. מחילים את מדיניות ההגבלה במצב dry-run על מרחב השמות ובודקים אם יש הפרות.
  2. אם הפודים שלכם מפרים את מדיניות ההגבלות, אתם יכולים להחיל את מדיניות הבסיס הפחות מגבילה במצב dry-run על מרחב השמות ולבדוק אם יש הפרות.
  3. אם ה-Pods שלכם מפרים את מדיניות הבסיס, אתם צריכים לשנות את מפרטי ה-Pods כדי לתקן את ההפרות.
  4. כשהמדיניות Baseline לא מחזירה יותר הפרות, מפעילים את המדיניות במצב enforce במרחב השמות.

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

במצב audit, המדיניות לא נאכפת. ‫GKE פורס את ה-Pods ומוסיף רשומות ליומני הביקורת של GKE.

הצגת רשימה של כל מרחבי השמות באשכול

מקבלים רשימה של כל מרחבי השמות באשכול. חוזרים על השלבים שבקטעים הבאים לכל מרחב שמות ברשימה:

kubectl get ns

בגרסאות GKE הבאות, מערכת GKE מתעלמת ממדיניות שמחילים על מרחב השמות kube-system:

  • ‫1.23.6-gke.1900 ואילך
  • ‫1.24.0-gke.1200 ואילך

בגרסאות קודמות של GKE, מומלץ להימנע מאכיפת מדיניות ב-kube-system.

החלת כל כללי המדיניות של תקני אבטחת ה-Pod במצב הרצת בדיקה

בשלבים הבאים תפעילו כל מדיניות במצב dry-run, החל ממדיניות מוגבלת שהיא המגבילה ביותר. אם הפלט מציג אזהרה, צריך לשנות את מפרט ה-Pod שמפר את המדיניות כדי לפעול בהתאם למדיניות, או לנסות את מדיניות הבסיס שהיא פחות מגבילה. אם לא מוצגת אזהרה בפלט, אפשר להחיל את מדיניות הבסיס בלי מצב dry-run.

  1. החלת המדיניות מוגבל במצב dry-run:

    kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=restricted

    אם יש Pod במרחב השמות שמפר את המדיניות המוגבלת, הפלט יהיה דומה לזה:

    Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "restricted:latest"
namespace/NAMESPACE labeled

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

  2. החלת מדיניות הגדרות בסיסיות במצב dry-run:

    kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=baseline

    אם יש Pod במרחב השמות שמפר את מדיניות הבסיס, הפלט יהיה דומה לזה:

    Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "baseline:latest"
namespace/NAMESPACE labeled

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

אכיפת המדיניות במרחב שמות

אחרי שמזהים את המדיניות שמתאימה למרחב שמות, מחילים את המדיניות על מרחב השמות במצב enforce:

kubectl label --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=POLICY

מחליפים את POLICY בשם המדיניות, שיכול להיות אחד מהשמות הבאים: restricted, baseline או privileged.

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

השבתת התכונה PodSecurityPolicy באשכול

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

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-pod-security-policy

מחליפים את CLUSTER_NAME בשם של אשכול GKE.

כשמשדרגים את האשכול ל-GKE גרסה 1.25,‏ GKE מסיר באופן אוטומטי את כל האובייקטים שנותרו, כולל אלה שנוספו על ידי GKE,‏ Policy Controller וכל אובייקט PodSecurityPolicy שהגדרתם בעבר.PodSecurityPolicy

המלצות

  • כדאי לנסות לפעול בהתאם למדיניות המוגבלת ככל האפשר. כדאי לבצע ביקורת באפליקציות כדי לבדוק אם אפשר להגביר את האבטחה של ההגדרות.
  • אפשר לנעול את מצב האבטחה של ה-Pod לגרסה משנית ספציפית של Kubernetes על ידי הוספת התווית pod-security.kubernetes.io/MODE-version: VERSION לפקודות kubectl label בשלבים הקודמים. מחליפים את VERSION במספר הגרסה של Kubernetes, לדוגמה v1.24.
  • אחרי שמשביתים את התכונה PodSecurityPolicy, כדאי לבדוק את האפליקציות הפעילות כדי לוודא שאין שיבושים או פערים בהגדרות האבטחה.
  • אחרי שמגדירים את PodSecurity, מעדכנים את תהליך יצירת מרחב השמות כדי להחיל באופן אוטומטי תווית PodSecurity על כל מרחבי השמות החדשים. מידע נוסף זמין במאמר בדיקת תהליך יצירת מרחב שמות

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