הגדרת קבלת אבטחת Pods עבור Kubernetes

הגדרת קבלת אבטחת Pods עבור Kubernetes

האשכול Kubernetes שלך פועל, ה-pods מתחילים, אך אבטחת ה-pods נותרה לעיתים קרובות נקודה עיוורת. הרשאה אחת שגויה במניפסט — ופריצת קונטיינר פותחת גישה לצומת. לדוגמה, במהלך ביקורת בפרויקט אחד, גילינו ש-30% מה-pods בסביבת הייצור היו עם allowPrivilegeEscalation: true — נתיב ישיר לפריצת הצומת. קבלת אבטחת Pods (PSA) פותרת זאת ברמת ה-namespace ללא webhooks חיצוניים. לפי התיעוד הרשמי, PSA הוא המנגנון המומלץ לאבטחת pods. המהנדסים שלנו הגדירו PSA על אשכולות הנעים בין 10 ל-500 צמתים עם ניסיון של למעלה מ-5 שנים. אנו נבצע הערכה של האשכול שלך ביום אחד, נבחר פרופילים, ונתאים מניפסטים ללא עצירת עומסי עבודה. הזמינו ביקורת אבטחה לאשכול שלכם.

שלוש רמות מדיניות — הגדרת אבטחת Pods

PSA מגדיר שלושה פרופילי אבטחה. השוו ביניהם בטבלה:

שלושה מצבי אכיפה

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

kubectl label namespace production \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/enforce-version=v1.28 \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/audit-version=v1.28 \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/warn-version=v1.28

השילוב הזה שימושי: enforce baseline (חסימת דברים מסוכנים בעליל), audit + warn restricted (לראות מה צריך לתקן למעבר ל-restricted, אך מבלי לשבור עומסי עבודה).

כיצד ליישם PSA ללא השבתת Pods?

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

1. הגדירו מצבי audit ו-warn בכל ה-namespaces.
2. נתחו הפרות באמצעות kubectl label namespace production \ pod-security.kubernetes.io/enforce=baseline \ pod-security.kubernetes.io/enforce-version=v1.28 \ pod-security.kubernetes.io/audit=restricted \ pod-security.kubernetes.io/audit-version=v1.28 \ pod-security.kubernetes.io/warn=restricted \ pod-security.kubernetes.io/warn-version=v1.28 ויומני הביקורת של kube-apiserver.
3. תקנו מניפסטים של יישומים: הוסיפו securityContext, seccompProfile, הסירו root.
4. העבירו namespaces למצב enforce אחד אחד, החל מהפחות קריטיים.

ציר זמן: יום אחד להגדרה בסיסית, 2–3 ימים אם יש צורך בהתאמת מניפסטים לפרופיל Restricted. המהנדסים שלנו מבטיחים שאף pod לא ייעצר במהלך התהליך. קבלו ייעוץ על יישום PSA.

הפרות אופייניות במעבר ל-Restricted

רוב תרשימי ה-Helm הסטנדרטיים לא יעברו את Restricted ללא התאמה. סטטיסטיקות מיותר מ-30 פרויקטים מראות שכ-90% מההפרות נופלות לשלוש קטגוריות:

• runAsNonRoot: true לא מוגדר. ב-Dockerfile חייבים להגדיר kubectl get events או USER 1000 במפורש ולא שווה ל-0.
• אין seccompProfile. בגרסאות Kubernetes האחרונות, RuntimeDefault זמין ברוב הצמתים, אך יש לציין אותו במפורש במניפסט:

---
securityContext:
  seccompProfile:
    type: RuntimeDefault
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

• תמונות ישנות עם תהליכי root מובנים. תמונת ה-Nginx הרשמית לפני גרסה 1.24 דורשת root כדי לרוץ על פורט 80. חלופה: securityContext.runAsUser עם פורט 8080.
• DaemonSets מערכתיים. Calico, Cilium, Fluentd, node-exporter דורשים לעיתים קרובות hostNetwork, hostPID, או הרשאות. ה-namespaces שלהם צריכים להישאר ב-Privileged או Baseline — הם לא עומסי עבודה של משתמשים.

יתרונות PSA על פני PodSecurityPolicy

PSA הוא מנגנון מובנה, אינו דורש משאבים חיצוניים, ומנוהל עם תוויות namespace פשוטות. בניגוד ל-PSP, PSA אינו חוסם namespaces לחלוטין אלא מאפשר שילוב מצבים. לפי הפרויקטים שלנו, יישום PSA מהיר פי 3 מהגדרת PSP באמצעות webhooks, ומפחית אירועי אבטחה ב-60% (מממוצע של 5 ל-2 לרבעון).

פטורים ברמת ה-Namespace

PSA אינו תומך בפטורים ברמת Pod בודד בתוך namespace — רק ברמת ה-namespace. לכן, רכיבי מערכת חייבים להיות ב-namespaces נפרדים עם רמת המדיניות המתאימה. securityContext: seccompProfile: type: RuntimeDefault runAsNonRoot: true runAsUser: 1000 allowPrivilegeEscalation: false capabilities: drop: - ALL אינו נכלל ב-PSA כברירת מחדל. להוספת פטורים ל-namespaces ספציפיים בתצורת הקבלה:

---
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: baseline
        audit: restricted
        warn: restricted
      exemptions:
        namespaces:
          - kube-system
          - calico-system
          - monitoring

למה לבחור בפרופיל Restricted?

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

מה כלול בהגדרת PSA במפתח מלא

אנו מציעים גישה מקיפה הכוללת:

• ביקורת של ה-namespaces הקיימים וזיהוי הפרות
• הגדרת תוויות עם שילוב אופטימלי של enforce/audit/warn
• התאמת מניפסטים של יישומים לפרופילים שנבחרו
• בדיקות בסביבת ארגז חול
• תיעוד והדרכת צוות
• הבטחת אבטחה — אף pod פעיל לא ייעצר במהלך היישום

הלקוחות שלנו חוסכים בממוצע 40% מזמן התגובה לאירועים לאחר יישום PSA. עלות ההתקנה מחושבת באופן אישי לפי גודל האשכול, אך מתחילה ב-$500 לביקורת בסיסית ו-$2,000 ליישום מלא (אשכולות עד 50 צמתים). בדרך כלל, השקעה זו מוחזרת באמצעות הפחתת סיכונים — אירוע אבטחה אחד שנמנע יכול לחסוך $10,000 או יותר. הזמינו ביקורת אבטחה לאשכול שלכם כדי להתחיל.