מעבר מ-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 זמין בגרסת בטא בגרסאות 1.23 ו-1.24 של GKE, ובגרסה יציבה בגרסה 1.25 ואילך של GKE.
  • ‫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. אם ה-Pods שלכם מפרים את מדיניות ההגבלות, צריך להחיל את מדיניות הבסיס הפחות מגבילה במצב dry-run על מרחב השמות ולבדוק אם יש הפרות.
  3. אם ה-Pods שלכם מפרים את מדיניות Baseline, אתם צריכים לשנות את מפרטי ה-Pods כדי לתקן את ההפרות.
  4. כשהמדיניות Baseline לא מחזירה יותר הפרות, צריך להחיל את המדיניות במצב enforce על מרחב השמות.

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

במצב 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

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

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

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

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

המלצות

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

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