פתרון בעיות ב-webhooks של Google Distributed Cloud

בדף הזה מוסבר איך לפתור בעיות ב-webhook בעייתי או לא בטוח ב-Google Distributed Cloud.

סוגים של ווּבּהוּקים בעייתיים

Webhooks ב-Kubernetes, או webhooks של הרשאות גישה, הם סוג של בקר הרשאות גישה שאפשר להשתמש בהם באשכולות Kubernetes כדי לאמת או לשנות בקשות למישור הבקרה לפני שהבקשה נשמרת. מקובל שאפליקציות של צד שלישי משתמשות ב-webhook שפועלים במשאבים ובמרחבי שמות שחיוניים למערכת. הגדרות לא נכונות של ווּבּהוּקים עלולות להשפיע על הביצועים והמהימנות של מישור הבקרה. לדוגמה, webhook שהוגדר בצורה שגויה ונוצר על ידי אפליקציית צד שלישי יכול למנוע מ-Google Distributed Cloud ליצור ולשנות משאבים במרחב השמות המנוהל kube-system, מה שעלול לפגוע בפונקציונליות של האשכול.

סוגי ה-webhook הבעייתיים כוללים:

Webhooks that have no available endpoints

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

  1. מאתרים את ה-Pods של ההצגה בשביל השירות שמשויך ל-Webhook. כדי לתאר את השירות, מריצים את הפקודה הבאה:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
    

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

    • SERVICE_NAME בשם של השירות.
    • SERVICE_NAMESPACE בשם של מרחב השמות.

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

  2. בודקים את ה-Pods של השרתים בשירות הזה. כדי לזהות אילו פודים לא פועלים, מריצים את הפקודה הבאה כדי להציג את ה-Deployment:

    kubectl get deployment -n SERVICE_NAMESPACE
    

    לחלופין, מריצים את הפקודה הבאה כדי להציג את רשימת ה-Pods:

    kubectl get pods -n SERVICE_NAMESPACE -o wide
    

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

תגובות webhook שנחשבות לא בטוחות

אם ה-webhook מיירט משאבים כלשהם במרחבי שמות שמנוהלים על ידי המערכת, מומלץ לעדכן את ה-webhook כדי למנוע יירוט של המשאבים האלה.

  1. בודקים את ההגדרות של ה-Webhook. מריצים את הפקודה הבאה kubectl כדי לקבל את הגדרות ה-webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
    

    מחליפים את CONFIGURATION_NAME בשם של הגדרת ה-webhook.

    אם הפקודה לא מחזירה כלום, מריצים אותה שוב ומחליפים את validatingwebhookconfigurations ב-mutatingwebhookconfigurations.

    בקטע webhooks של הפלט, מופיע ווּבּהוּק אחד או יותר.

  2. עורכים את ההגדרה בהתאם לסיבה שבגללה ה-webhook נחשב לא בטוח:

    החרגה של מרחבי השמות kube-system ו-kube-node-lease

    הודעת webhook נחשבת לא בטוחה אם scope הוא *, או אם ההיקף הוא Namespaced ואחד מהתנאים הבאים מתקיים:

    • התנאי operator הוא NotIn והתנאי values משמיט את kube-system ואת kube-node-lease, כמו בדוגמה הבאה:

      webhooks:
      - admissionReviewVersions:
        ...
        namespaceSelector:
          matchExpressions:
          - key: kubernetes.io/metadata.name
            operator: NotIn
            values:
            - blue-system # add 'kube-system' and 'kube-node-lease' if `NotIn`
        objectSelector: {}
        rules:
        - apiGroups:
          ...
          scope: '*' # 'Namespaced'
        sideEffects: None
        timeoutSeconds: 3
      

      מוודאים שהערך של scope הוא Namespaced ולא *, כדי ש-webhook יפעל רק במרחבי שמות ספציפיים. מוודאים שאם operator הוא NotIn, אז kube-system ו-kube-node-lease כלולים ב-values.

    • התנאי operator הוא In והתנאי values כולל את kube-system ואת kube-node-lease, כמו בדוגמה הבאה:

      namespaceSelector:
          matchExpressions:
          - key: kubernetes.io/metadata.name
            operator: In
            values:
            - blue-system
            - kube-system # remove as operator is `In`
            - kube-node-lease # remove as operator is `In`
      

      מוודאים שהערך של scope הוא Namespaced ולא *, כדי ש-webhook יפעל רק במרחבי שמות ספציפיים. מוודאים שאם operator הוא In,‏ kube-system ו-kube-node-lease לא נכללים ב-values.

    החרגת משאבים תואמים

    התגובה לפעולה מאתר אחר (webhook) נחשבת לא בטוחה גם אם nodes,‏ tokenreviews,‏ subjectaccessreviews או certificatesigningrequests מופיעים בקטע resources, כמו בדוגמה הבאה:

    - admissionReviewVersions:
    ...
        resources:
        - 'pods' # keep, remove everything else
        - 'nodes'
        - 'tokenreviews'
        - 'subjectacessreviews'
        - 'certificatesigningrequests'
        scope: '*'
      sideEffects: None
      timeoutSeconds: 3
    

    מסירים את nodes,‏ tokenreviews,‏ subjectaccessreviews ו-certificatesigningrequests מהקטע 'משאבים'.

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

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

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