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

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

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

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

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

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

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

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

  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 בקובצי YAML.

צריך להוסיף תו בריחה לכל תו מיוחד בשדות 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 במניפסט של רצף המודעות:

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

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