מעבר מ-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 כדי לוודא שהשדות האלה קיימים כשאתם פורסים את עומסי העבודה.

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

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

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

    אם יש 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 מסיר באופן אוטומטי את כל אובייקטי PodSecurityPolicy שנותרו, כולל אלה שנוספו על ידי GKE,‏ Policy Controller וכל אובייקט PodSecurityPolicy שהגדרתם בעבר.

המלצות

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

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