פתרון בעיות של עומסי עבודה (workloads) ורשימות היתרים של Autopilot עם הרשאות מיוחדות

כדי למנוע בעיות, צריך להגדיר בצורה נכונה עומסי עבודה עם הרשאות מיוחדות באשכולות Google Kubernetes Engine ‏ (GKE) Autopilot. הגדרות שגויות עלולות לגרום לכך שהסנכרון עם רשימות ההיתרים ייכשל או שעומס העבודה יידחה. הבעיות האלה יכולות למנוע מסוכנים או משירותים חיוניים לפעול עם ההרשאות הנדרשות.

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

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

בעיות בסנכרון של רשימת ההיתרים

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

קבלת הסטטוס של אובייקט AllowlistSynchronizer:

kubectl get allowlistsynchronizer ALLOWLIST_SYNCHRONIZER_NAME -o yaml

מחליפים את ALLOWLIST_SYNCHRONIZER_NAME בשם של AllowlistSynchronizer.

הפלט אמור להיראות כך:

...
status:
  conditions:
  - type: Ready
    status: "False"
    reason: "SyncError"
    message: "some allowlists failed to sync: example-allowlist-1.yaml"
    lastTransitionTime: "2024-10-12T10:00:00Z"
    observedGeneration: 2
  managedAllowlistStatus:
    - filePath: "gs://path/to/allowlist1.yaml"
      generation: 1
      phase: Installed
      lastSuccessfulSync: "2024-10-10T10:00:00Z"
    - filePath: "gs://path/to/allowlist2.yaml"
      phase: Failed
      lastError: "Initial install failed: invalid contents"
      lastSuccessfulSync: "2024-10-08T10:00:00Z"

השדה conditions.message והשדה managedAllowlistStatus.lastError מספקים מידע מפורט על השגיאה. תוכלו להיעזר במידע הזה כדי לפתור את הבעיה.

‫Multiple AllowlistSynchronizers

באשכולות GKE בגרסאות קודמות ל-1.33.4-gke.1035000, יכול להיות שההתקנה של WorkloadAllowlists תיכשל אם יש יותר מ-AllowlistSynchronizer.

כדי לפתור את הבעיה, צריך להשתמש רק בתג AllowlistSynchronizer אחד שמכיל כמה תגי allowlistPaths.

אפשרות אחרת היא לשדרג את האשכול לגרסה חדשה יותר.

מיון של מאגרי תגים של עומסי עבודה

באשכולות GKE בגרסאות קודמות ל-1.34.0-gke.0000000, אם קובץ אימג' של קונטיינר אחד או יותר של עומס עבודה תואם לקובץ אימג' של קונטיינר שצוין ב-WorkloadAllowlist באשכול, יכול להיות שקונטיינרים של עומס העבודה ייווצרו וימוינו בסדר אלפביתי הפוך.

כדי לפתור את הבעיה, נסו את האפשרויות הבאות:

  • משדרגים את האשכול לגרסה 1.34.0-gke.0000000 ומעלה.
  • משנים את השם של הקונטיינרים של עומס העבודה כך שהם ימוינו בסדר הנכון.

בעיות בפריסת עומסי עבודה עם הרשאות

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

אפשר לנסות את האפשרויות הבאות לתגובה:

  • מוודאים שגרסת ה-GKE של האשכול עומדת בדרישת הגרסה של עומס העבודה.
  • מוודאים שעומס העבודה שאתם פורסים הוא עומס העבודה שאליו חל קובץ הרשימה הלבנה.

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

  1. כדי לקבל רשימה של רשימות ההיתרים המותקנות באשכול:

    kubectl get workloadallowlist

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

  2. פותחים את קובץ ה-YAML של עומס העבודה עם הרשאות מיוחדות בכלי לעריכת טקסט. אם אין לכם גישה למניפסטים של YAML, למשל אם תהליך הפריסה של עומס העבודה משתמש בכלים אחרים, פנו לספק עומס העבודה כדי לפתוח בעיה. מדלגים על השלבים הנותרים.

  3. מוסיפים את התווית הבאה לקטע spec.metadata.labels של מפרט ה-Pod של עומס העבודה עם הרשאות:

    labels:
  cloud.google.com/matching-allowlist: ALLOWLIST_NAME

    מחליפים את ALLOWLIST_NAME בשם הרשימה הלבנה שקיבלתם בשלב הקודם. משתמשים בשם מתוך הפלט של הפקודה kubectl get workloadallowlist, ולא בנתיב לקובץ רשימת ההיתרים.

  4. שומרים את קובץ המניפסט ומחילים את עומס העבודה על האשכול:

    kubectl apply -f WORKLOAD_MANIFEST_FILE

    מחליפים את WORKLOAD_MANIFEST_FILE בנתיב לקובץ המניפסט.

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

    Error from server (GKE Warden constraints violations): error when creating "STDIN": admission webhook "warden-validating.common-webhooks.networking.gke.io" denied the request:

===========================================================================
Workload Mismatches Found for Allowlist (example-allowlist-1):
===========================================================================
HostNetwork Mismatch: Workload=true, Allowlist=false
HostPID Mismatch: Workload=true, Allowlist=false
Volume[0]: data
         - data not found in allowlist. Verify volume with matching name exists in allowlist.
Container[0]:
- Envs Mismatch:
        - env[0]: 'ENV_VAR1' has no matching string or regex pattern in allowlist.
        - env[1]: 'ENV_VAR2' has no matching string or regex pattern in allowlist.
- Image Mismatch: Workload=k8s.gcr.io/diff/image, Allowlist=k8s.gcr.io/pause2. Verify that image string or regex match.
- SecurityContext:
        - Capabilities.Add Mismatch: the following added capabilities are not permitted by the allowlist: [SYS_ADMIN SYS_PTRACE]
- VolumeMount[0]: data
        - data not found in allowlist. Verify volumeMount with matching name exists in allowlist.

    בדוגמה הזו, יש את ההפרות הבאות:

    • חלוקת העבודה מציינת את hostNetwork: true, אבל רשימת ההיתרים לא מציינת את hostNetwork: true.
    • עומס העבודה מציין hostPID: true, אבל רשימת ההיתרים לא מציינת את hostPID: true.
    • עומס העבודה מציין נפח אחסון בשם data, אבל ברשימת ההיתרים לא מצוין נפח אחסון בשם data.
    • המאגר מציין משתני סביבה בשמות ENV_VAR1 ו-ENV_VAR2, אבל ברשימת ההיתרים לא מצוינים משתני הסביבה האלה.
    • הקונטיינר מציין את התמונה k8s.gcr.io/diff/image, אבל ברשימת ההיתרים מצוין k8s.gcr.io/pause2.
    • מאגר התגים מוסיף את היכולות SYS_ADMIN ו-SYS_PTRACE, אבל רשימת ההיתרים לא מאפשרת להוסיף את היכולות האלה.
    • מאגר התגים מציין נקודת טעינה של נפח אחסון בשם data, אבל ברשימת ההיתרים לא מצוינת נקודת טעינה של נפח אחסון בשם data.

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

גרסת GKE לא תואמת

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

  1. בודקים אם ברשימת ההיתרים מצוינת גרסת GKE מינימלית:

    kubectl describe workloadallowlist ALLOWLIST_NAME | grep "minGKEVersion"

    מחליפים את ALLOWLIST_NAME בשם של הרשימה הלבנה.

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

  2. בודקים את גרסת GKE של האשכול:

    gcloud container clusters describe CLUSTER_NAME \
    --location=CLUSTER_LOCATION \
    --format="value(currentMasterVersion)"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫CLUSTER_LOCATION: Google Cloud המיקום של האשכול.

    הפלט אמור להיראות כך:

    1.32.3-gke.1006000

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

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

חוסר התאמה במחרוזות

שדות ספציפיים במפרט של WorkloadAllowlist צריכים להיות זהים למחרוזות של השדות התואמים במפרט של עומס העבודה.

  1. פותחים את דף העזר של WorkloadAllowlist CustomResourceDefinition (CRD).
  2. לגבי כל שדה במפרט WorkloadAllowlist, בודקים אם ה-CRD דורש התאמה מדויקת של מחרוזת.

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

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

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

אי התאמות של ביטויים רגולריים

שדות ספציפיים במפרט WorkloadAllowlist תומכים בהתאמה של ביטויים רגולריים.

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

  2. מוודאים שהתחביר של הביטוי הרגולרי נכון. ה-CRD‏ WorkloadAllowlist תומך בתחביר של ביטויים רגולריים ב-Google RE2. מוודאים שלביטויים יש את המאפיינים הבאים:

    • הביטוי הרגולרי מתחיל בתו ^ ומסתיים בתו $. לדוגמה: ^example-auth\.google\.com\/go_[a-z0-9]+\/google\/path$.
    • כל תו מיוחד מסומן בתו בריחה (escape) \. בודקים אם יש תווים מיותרים או חסרים של \.
    • נתיבי התמונות ברשימת ההיתרים לא כוללים תגים או סיכומים. לדוגמה, במקום k8s.gcr.io/pause:3.1 או k8s.gcr.io/pause@sha256:1234567890, צריך להשתמש ב-k8s.gcr.io/pause.

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

תו בריחה (escape) לתווים בפקודות ובארגומנטים

אם לא משתמשים בתו בריחה (escape) לסימון התווים המיוחדים, GKE לא יכול להתאים בין פקודות לארגומנטים. הדרישות לשימוש בתווי escape תלויות באופן שבו אתם משתמשים ברשימת ההיתרים. לדוגמה, כשמחילים רשימת היתרים כקובץ YAML או JSON, יש דרישות שונות לשימוש בתווי escape בהשוואה ליצירת מפרט של רשימת היתרים באמצעות כלי שורת פקודה. בקטע הזה מתוארות הדרישות לשימוש בתווי Escape בקובצי YAML.

צריך להוסיף תווי בריחה (escape) לכל תו מיוחד בשדות commands ו-args של המפרט WorkloadAllowlist, גם אם לא משתמשים בביטוי רגולרי. כדי להשתמש בתו בריחה (escape) עם תווים מיוחדים, משתמשים בתו \, כמו בדוגמאות הבאות:

  • פקודה: kubectl describe \$\{POD_NAME\}
  • ארגומנט: hostname \$NODE_NAME; dcgm-exporter --remote-hostengine-info \$\(NODE_IP\) --collectors /etc/dcgm-exporter/counters.csv

הפרעה של תגובה לפעולה מאתר אחר (webhook) לעומסי עבודה (workloads) ברשימת ההיתרים

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

הבעיה הזו נפוצה בקרב סוכני ניטור ואבטחה של צד שלישי שמזריקים קונטיינרים של sidecar או משתני סביבה ל-Pods.

הסימפטום הנפוץ ביותר הוא שנוצר בקר עומס העבודה (כמו DaemonSet או Deployment) בהצלחה, אבל הוא לא מצליח ליצור אף Pod. כשבודקים את האירועים של בקר, רואים הודעות שמציינות שה-Pods נדחו על ידי ה-webhook של בקרת הכניסה.

  1. פועלים לפי השלבים בקטע בעיות בהטמעה של עומסי עבודה עם הרשאות כדי להוסיף את התווית cloud.google.com/matching-allowlist לעומס העבודה.
  2. מעתיקים את spec.template ממניפסט ה-YAML של עומס העבודה.
  3. יוצרים מניפסט חדש של Pod ומדביקים את המפרט שהועתק בשדה spec.

  4. מגדירים את השדות apiVersion,‏ kind ו-metadata.name במניפסט של ה-Pod:

    apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
  labels:
    cloud.google.com/matching-allowlist: ALLOWLIST_NAME
spec:
  # Paste the content of spec.template here

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫POD_NAME: השם של ה-Pod לבדיקה.
    • ‫ALLOWLIST_NAME: השם של רשימת ההיתרים.

  5. החלת מניפסט ה-Pod:

    kubectl apply -f YOUR_POD_MANIFEST_FILE

    מחליפים את הערך ב-YOUR_POD_MANIFEST_FILE בנתיב לקובץ המניפסט של ה-Pod.

  6. בודקים את הפלט מהשלב הקודם. אם בקטע Workload Mismatches (אי התאמות בעומס העבודה) מופיעים שדות לא צפויים, כמו משתני סביבה נוספים (לדוגמה, DD_AGENT_HOST), קונטיינרים או נפחים, זהו סימן מובהק לכך ש-Webhook אחר משנה את ה-Pods.

כדי לפתור את הבעיה, צריך להגדיר את ה-webhook שגורם להתנגשות כך שהוא לא ישנה את ה-Pods של עומס העבודה שנוסף לרשימת ההיתרים. בדרך כלל עושים את זה על ידי הוספת תווית או הערה לעומס העבודה או למרחב השמות שלו, כדי לסמן ל-webhook שהוא צריך להיות מוחרג משינוי. לדוגמה, ב-Datadog, מוסיפים את התווית admission.datadoghq.com/enabled: "false" למרחב השמות של עומס העבודה.

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

מניעת שינוי של ה-Pods על ידי ה-Webhook השני עוזרת לוודא שהם ממשיכים להתאים לרשימת ההיתרים ושהפריסה שלהם באשכול Autopilot מצליחה.

באגים ובקשות להוספת תכונות לעומסי עבודה עם הרשאות ולרשימות היתרים

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

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