פתרון בעיות שקשורות לגישת משתמשים

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

‫gcloud anthos create-login-config לא מצליח לקבל clientconfig

הבעיה הזו מתרחשת באחד מהמקרים הבאים:

  • קובץ ה-kubeconfig שהועבר אל gcloud anthos create-login-config שגוי.
  • המקור המותאם אישית ClientConfig לא קיים באשכול (האימות של צד שלישי לא מוגדר באשכול).

הודעת השגיאה

  failed to get clientconfig default in namespace kube-public

פתרון

כדי לפתור את הבעיה:

  1. מוודאים שיש לכם את קובץ ה-kubeconfig הנכון עבור האשכול.

  2. כדי לוודא שהמשאב המותאם אישית ClientConfig נמצא באשכול, מריצים את הפקודה הבאה:

    kubectl --kubeconfig KUBECONFIG  get clientconfig default -n kube-public

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

gcloud anthos create-login-config נכשל בגלל שם אשכול כפול

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

הודעת השגיאה

  error merging with file FILENAME because FILENAME contains a
    cluster with the same name as the one read from KUBECONFIG.

פתרון

כדי לפתור את הבעיה, משתמשים בדגל --output כדי לציין קובץ יעד חדש.

אם לא מספקים את --output, נתוני ההגדרה של הכניסה נכתבים לקובץ בשם kubectl-anthos-config.yaml בספרייה הנוכחית.

gcloud anthos auth login נכשל עם proxyconnect tcp

הבעיה הזו מתרחשת כשיש שגיאה בהגדרות של משתני הסביבה https_proxy או HTTPS_PROXY. אם יש https:// שצוין במשתני הסביבה, יכול להיות שספריות לקוח ה-HTTP של GoLang ייכשלו אם ה-proxy מוגדר לטפל בחיבורי HTTPS באמצעות פרוטוקולים אחרים, כמו SOCK5.

הודעת השגיאה

  proxyconnect tcp: tls: first record does not look like a TLS handshake

פתרון

כדי לפתור את הבעיה, צריך לשנות את משתני הסביבה https_proxy ו-HTTPS_PROXY כדי להשמיט את https:// prefix. ב-Windows, משנים את משתני הסביבה של המערכת. לדוגמה, שינוי הערך של משתנה הסביבה https_proxy מ-https://webproxy.example.com:8000 ל-webproxy.example.com:8000.

הגישה לאשכול נכשלת כשמשתמשים ב-kubeconfig שנוצר על ידי gcloud anthos auth login

הבעיה הזו מתרחשת כששרת ה-API של Kubernetes לא מצליח לאשר את המשתמש בגלל אחת מהסיבות הבאות:

  • יש שגיאה בהגדרה שמשמשת לכניסה באמצעות הפקודה gcloud anthos auth login.
  • כללי המדיניות הנדרשים של RBAC שגויים או חסרים עבור המשתמש.

הודעת השגיאה

  Unauthorized

פתרון

כדי לפתור את הבעיה:

  1. אימות ההגדרה שמשמשת לכניסה.

    הגדרת OIDC

    בקטע authentication.oidc בקובץ התצורה של אשכול המשתמשים יש שדות group ו-username שמשמשים להגדרת הדגלים --oidc-group-claim ו---oidc-username-claim בשרת ה-API של Kubernetes. כששרת ה-API מקבל אסימון זהות של משתמש, הוא מעביר את האסימון לאשכול, שמחזיר את הערכים שחולצו group-claim ו-username-claim לשרת ה-API. שרת ה-API משתמש בתשובה כדי לוודא שלקבוצה או למשתמש המתאימים יש את ההרשאות הנכונות.

    מוודאים שהטענות שמוגדרות עבור group ו-user בקטע authentication.oidc של קובץ ההגדרה של האשכול מופיעות בטוקן המזהה.

  2. אימות מדיניות RBAC שהוחלה.

    במאמר הגדרת בקרת גישה מבוססת-תפקידים (RBAC) מוסבר איך להגדיר את מדיניות ה-RBAC הנכונה.

תפקידי RBAC לקבוצות לא פועלים ב-Google Groups

  1. מוודאים שהצי או האשכול מוגדרים לאימות של צד שלישי.

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

  2. מוודאים שהגדרתם את הקבוצות ב-Google Workspace בצורה נכונה:

תפקידי RBAC לקבוצות לא פועלים בספקי OIDC

  1. אימות אם יש בטוקן המזהה את פרטי הקבוצה

    אחרי שמריצים את הפקודה gcloud anthos auth login כדי להתחיל את תהליך האימות של OIDC, אסימון הזהות נשמר בקובץ kubeconfig בשדה id-token. משתמשים ב-jwt.io כדי לפענח את האסימון המזהה ולוודא שהוא מכיל את פרטי הקבוצה של המשתמש כצפוי.

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

  3. אם באסימון המזהה יש פרטי קבוצה, צריך לוודא שמפתח פרטי הקבוצה באסימון המזהה תואם לשדה groupsClaim שהוגדר בקטע oidc.

    לדוגמה, אם אסימון ה-ID מכיל מידע על קבוצה במפתח groups:

    "groups" : ["group1", "group2" ...]

    אז הערך בשדה groupsClaim צריך להיות groups בקטע oidc.

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

פתרון בעיות שקשורות לספקי זהויות

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

הפעלת יומן ניפוי הבאגים

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

  1. מבצעים תיקון באשכול הקיים באמצעות kubectl patch:

    kubectl patch deployment ais \
  -n anthos-identity-service --type=json \
  -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value":"--vmodule=cloud/identity/hybrid/charon/*=LOG_LEVEL"}]' \
  --kubeconfig KUBECONFIG

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

    • ‫LOG_LEVEL: כדי לקבל את היומנים המפורטים ביותר, צריך להגדיר את הערך הזה לרמה 3 כשמנסים לפתור בעיות.

    • ‫KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול המשתמשים.

בדיקת יומן הקונטיינר

בודקים את התוכן של יומני מאגרי התגים כדי לראות אם יש שגיאות או אזהרות.

  1. כדי לבדוק את היומנים, משתמשים ב-kubectl logs:

    kubectl logs -f -l k8s-app=ais \
  -n anthos-identity-service \
  --kubeconfig KUBECONFIG

    מחליפים את KUBECONFIG בנתיב לקובץ kubeconfig של אשכול המשתמשים.

הפעלה מחדש של ה-Pod

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

  1. כדי להפעיל מחדש את ה-Pod, מוחקים את ה-Pod הקיים. תיווצר באופן אוטומטי יחידת Pod חדשה כתחליף.

    kubectl delete pod -l k8s-app=ais \
  -n anthos-identity-service \
  --kubeconfig KUBECONFIG

    מחליפים את KUBECONFIG בנתיב לקובץ kubeconfig של אשכול המשתמשים.

פתרון בעיות בקישוריות לספק הזהויות

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

  1. מפעילים Pod של busybox באותו מרחב שמות:

    kubectl run curl --image=radial/busyboxplus:curl \
  -n anthos-identity-service -- sleep 3000 \
  --kubeconfig KUBECONFIG

    מחליפים את KUBECONFIG בנתיב לקובץ kubeconfig של אשכול המשתמשים.

  2. כדי לבדוק אם אפשר לאחזר את כתובת ה-URL של Discovery, נכנסים ל-Pod של busybox ומריצים את הפקודה curl:

    kubectl exec pod/curl -n anthos-identity-service -- \
  curl ISSUER_URL \
  --kubeconfig KUBECONFIG

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

    • ‫ISSUER_URL: כתובת ה-URL של מנפיק ספק הזהויות.
    • ‫KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול המשתמשים.

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

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

הכניסה באמצעות LDAP לא פועלת באשכול הניהול של Google Distributed Cloud

בשלב הזה, LDAP נתמך רק באשכול משתמשים של Google Distributed Cloud.