פתרון בעיות באימות ב-Google Distributed Cloud

במאמר הזה מוסבר איך לפתור בעיות שקשורות לאימות ב-Google Distributed Cloud. במאמר מופיע מידע כללי על פתרון בעיות והנחיות, וגם מידע ספציפי על OpenID Connect‏ (OIDC) ועל Lightweight Directory Access Protocol‏ (LDAP).

אימות OIDC ו-LDAP משתמש ב-GKE Identity Service. כדי להשתמש בשירות הזהויות של GKE עם Google Distributed Cloud, צריך להגדיר ספק זהויות. אם לא הגדרתם ספק זהויות עבור שירות הזהויות של GKE, אתם יכולים לפעול לפי ההוראות של אחד מהספקים הנפוצים הבאים:

במדריך לפתרון בעיות של ספק הזהויות של GKE Identity Service מוסבר איך להפעיל ולבדוק יומני זהויות ולבדוק את הקישוריות.

פתרון בעיות כלליות

הטיפים הבאים לפתרון בעיות יכולים לעזור לכם לפתור בעיות כלליות שקשורות לאימות ולהרשאה ב-Google Distributed Cloud. אם הבעיות האלה לא רלוונטיות או שיש לכם בעיות עם OIDC או LDAP, אפשר להמשיך לקטע בנושא פתרון בעיות ב-GKE Identity Service.

עדכון של gcloud anthos auth

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

יש שני חלקים שצריך לאמת. הפקודה gcloud anthos auth כוללת לוגיקה ברכיב הליבה של Google Cloud CLI וברכיב anthos-auth שנארז בנפרד.

  1. כדי לעדכן את Google Cloud CLI:

    gcloud components update

  2. כדי לעדכן את הרכיב anthos-auth:

    gcloud components install anthos-auth

הגדרות לא תקינות של ספק

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

הגדרות אישיות לא תקינות

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

הרשאות לא תקפות

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

חסר אסימון רענון

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

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

כדי לפתור את הבעיה, מוסיפים את prompt=consent לשדה authentication.oidc.extraParams במשאב ClientConfig. לאחר מכן יוצרים מחדש את קובץ אימות הלקוח.

פג תוקפו של טוקן הרענון

הבעיה הבאה מתרחשת כשפג תוקף של טוקן הרענון בקובץ kubeconfig:

Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
    certificate signed by unknown authority

כדי לפתור את הבעיה, מריצים שוב את הפקודה gcloud anthos auth login.

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

Unauthorized

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

  1. בקובץ kubeconfig שנוצר על ידי gcloud anthos auth login, מעתיקים את הערך של id-token.

    kind: Config
...
users:
- name: ...
  user:
    auth-provider:
      config:
        id-token: xxxxyyyy

  2. מתקינים את jwt-cli ומריצים את הפקודה:

    jwt ID_TOKEN

  3. אימות הגדרת OIDC.

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

    מוודאים שקבוצת הטענות של group ו-user במשאב ClientConfig מופיעה בטוקן המזהה.

  4. בודקים את ה-RBAC שהוחלו.

    מוודאים שיש RBAC עם ההרשאות הנכונות למשתמש שצוין על ידי username-claim או לאחת מהקבוצות שמופיעות group-claim מהשלב הקודם. השם של המשתמש או הקבוצה ב-RBAC צריך להתחיל בקידומת usernameprefix או groupprefix שצוינה במשאב ClientConfig.

    אם usernameprefix ריק ו-username הוא ערך שונה מ-email, קידומת ברירת המחדל היא issuerurl#. כדי להשבית את הקידומות של שמות המשתמשים, צריך להגדיר את usernameprefix לערך -.

    מידע נוסף על קידומות של משתמשים וקבוצות זמין במאמר אימות באמצעות OIDC.

    .

    ClientConfig משאב:

    oidc:
  ...
  username: "unique_name"
  usernameprefix: "-"
  group: "group"
  groupprefix: "oidc:"

    אסימון מזהה:

    {
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\developers"
  ],
...
}

    ההתאמות הבאות של RBAC מעניקות לקבוצה ולמשתמש את תפקיד האשכול pod-reader. שימו לב שיש קו נטוי אחד בשדה השם במקום שני קווים נטויים:

    קיבוץ ClusterRoleBinding:

    apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: Group
  name: "oidc:EXAMPLE\developers"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

    ‫User ClusterRoleBinding:

    apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: User
  name: "EXAMPLE\cluster-developer"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

  5. בודקים את היומנים של שרת ה-API של Kubernetes.

    אם פלאגין OIDC שהוגדר בשרת ה-API של Kubernetes לא מופעל בצורה תקינה, שרת ה-API מחזיר שגיאה מסוג Unauthorized כשמוצג לו טוקן ה-ID. כדי לבדוק אם היו בעיות בתוסף OIDC בשרת ה-API, מריצים את הפקודה:

    kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

    • ‫USER_CLUSTER_NAME: השם של אשכול המשתמשים שרוצים להציג את היומנים שלו.
    • ‫ADMIN_CLUSTER_KUBECONFIG: קובץ ה-kubeconfig של אשכול האדמין.

הפקודה gkectl create-login-config נכשלת בקבלת clientconfig

הבעיה הזו מתרחשת כשקובץ ה-kubeconfig שמועבר אל gkectl create-login-config לא מיועד לאשכול משתמשים, או שהמשאב ClientConfig לא הופעל במהלך יצירת האשכול.

Error getting clientconfig using KUBECONFIG

כדי לפתור את הבעיה, צריך לוודא שיש לכם את קובץ ה-kubeconfig הנכון עבור אשכול המשתמשים. לאחר מכן בודקים אם המשאב ClientConfig נמצא באשכול:

kubectl get clientconfig default -n kube-public \
  --kubeconfig USER_CLUSTER_KUBECONFIG

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

הפקודה gkectl create-login-config נכשלת בגלל שם אשכול כפול

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

error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
  the same name as the one read from KUBECONFIG. Please write to a new
  output file

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

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

פתרון בעיות ב-OIDC

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

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

בדיקת מפרט OIDC באשכול

פרטי OIDC של האשכול מוגדרים במשאב ClientConfig במרחב השמות kube-public.

  1. משתמשים בפקודה kubectl get כדי להדפיס את משאב OIDC עבור אשכול המשתמשים:

    kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml

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

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

  3. אם זיהיתם בעיה בהגדרה במפרט, הגדירו מחדש את OIDC.

  4. אם אתם לא מצליחים לאבחן ולפתור את הבעיה בעצמכם, אתם יכולים לפנות Google Cloud לתמיכה.

    Google Cloud צוות התמיכה צריך את היומנים של שירות הזהויות של GKE ואת מפרט OIDC כדי לאבחן ולפתור בעיות שקשורות ל-OIDC.

איך מוודאים שאימות OIDC מופעל

לפני שבודקים את אימות OIDC, מוודאים שאימות OIDC מופעל באשכול.

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

    kubectl logs -l k8s-app=ais -n anthos-identity-service

    בדוגמה הבאה של פלט אפשר לראות שאימות OIDC מופעל בצורה נכונה:

    ...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...

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

    Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:

    בודקים את השגיאות הספציפיות שדווחו ומנסים לתקן אותן.

בדיקת אימות OIDC

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

  1. מורידים את Google Cloud CLI.

  2. כדי ליצור את קובץ התצורה לכניסה, מריצים את הפקודה הבאה: gcloud anthos create-login-config

    gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG

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

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

    gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG

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

    • ‫CLUSTER_NAME בשם של אשכול המשתמשים שאליו רוצים להתחבר.
    • AUTH_KUBECONFIG עם קובץ ה-kubeconfig החדש כדי ליצור קובץ שכולל את פרטי הכניסה לגישה לאשכול. מידע נוסף זמין במאמר אימות לאשכול.

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

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

  5. כדי לבדוק את קובץ ה-kubeconfig החדש שכולל את פרטי הכניסה שלכם, מציגים את רשימת ה-Pods באשכול המשתמשים:

    kubectl get pods --kubeconfig AUTH_KUBECONFIG

    מחליפים את AUTH_KUBECONFIG בנתיב לקובץ kubeconfig החדש שנוצר בשלב הקודם.

    יכול להיות שתקבלו את הודעת הדוגמה הבאה, שמראה שהאימות הצליח אבל לא הוקצו לחשבון אמצעי בקרה לגישה מבוססת-תפקידים (RBAC):

    Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope

בדיקת יומני אימות OIDC

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

  1. משתמשים ב-kubectl logs כדי להדפיס את היומנים של שירות הזהויות של GKE:

    kubectl --kubeconfig KUBECONFIG \
  -n anthos-identity-service logs \
  deployment/ais --all-containers=true

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

  2. כדאי לעיין ביומנים כדי למצוא שגיאות שיעזרו לכם לאבחן בעיות ב-OIDC.

    לדוגמה, יכול להיות שיש טעות הקלדה בשדה issuerURL של המשאב ClientConfig, כמו htps://accounts.google.com (חסר t ב-https). יומני שירות הזהויות של GKE יכללו רשומה כמו בדוגמה הבאה:

    OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.

  3. אם מזהים בעיה בהגדרה ביומנים, מגדירים מחדש את OIDC ומתקנים את בעיות ההגדרה.

  4. אם אתם לא מצליחים לאבחן ולפתור את הבעיה בעצמכם, אתם יכולים לפנות Google Cloud לתמיכה.

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

בעיות נפוצות ב-OIDC

אם נתקלתם בבעיות באימות OIDC, כדאי לעיין בבעיות הנפוצות הבאות. פועלים לפי ההנחיות לפתרון הבעיה.

אין נקודות קצה זמינות לשירות ais

כששומרים את משאב ClientConfig, מוחזרת הודעת השגיאה הבאה:

  Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
  failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
  no endpoints available for service "ais"

השגיאה הזו נגרמת בגלל נקודת קצה לא תקינה של שירות הזהויות של GKE. פוד GKE Identity Service לא יכול להפעיל את ה-webhook של האימות.

  1. כדי לוודא שה-Pod של שירות הזהויות של GKE לא תקין, מריצים את הפקודה הבאה:

    kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG

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

    הפלט הבא לדוגמה מצביע על כך שתרמיל GKE Identity Service קורס:

    NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s

  2. כדי להבין למה יש בעיה ב-Pod, צריך לבדוק את האירועים של ה-Pod:

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

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

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

    Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5
  Normal   Pulling    8m23s (x4 over 10m)     kubelet            Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Error: ErrImagePull
  Warning  Failed     8m10s (x6 over 9m59s)   kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m49s (x21 over 9m59s)  kubelet            Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"

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

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

יכול להיות שהשגיאות הבאות יופיעו ביומנים של שירות הזהויות של GKE:

  E0516 07:24:38.314681      65 oidc_client.cc:207] Failed fetching the Discovery URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
  Failed reading response bytes from server.

  E0516 08:24:38.446504      65 oidc_client.cc:223] Failed to fetch the JWKs URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
  Failed reading response bytes from server.

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

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

    לתוסף OIDC של שירות הזהויות של GKE יש תהליך דמון שמסנכרן באופן תקופתי את כתובת ה-URL של מסמך ה-Discovery של OIDC כל 5 שניות. אם החיבור לרשת לא יציב, יכול להיות שהבקשה הזו ליציאה תיכשל. כשלים מדי פעם לא משפיעים על אימות OIDC. אפשר לעשות שימוש חוזר בנתונים הקיימים במטמון.

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

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

    השלבים הבאים לפתרון בעיות יכולים לעזור באבחון בעיות הקישוריות האלה:

    1. מוודאים שחומת אש לא חוסמת את הבקשות היוצאות מ-GKE Identity Service.
    2. בודקים שהשרת של ספק הזהויות פועל בצורה תקינה.
    3. מוודאים שכתובת ה-URL של מנפיק OIDC במשאב ClientConfig מוגדרת בצורה נכונה.
    4. אם הפעלתם את שדה ה-proxy במשאב ClientConfig, כדאי לבדוק את הסטטוס או את היומן של שרת ה-proxy ליציאה.
    5. בודקים את הקישוריות בין הפוד של GKE Identity Service לבין השרת של ספק הזהויות מסוג OIDC.

צריך להתחבר לשרת (לא מורשה)

כשמנסים להיכנס באמצעות אימות OIDC, יכול להיות שתוצג הודעת השגיאה הבאה:

  You must be logged in to the server (Unauthorized)

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

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

הבקשה לאימות ה-webhook נכשלה

ביומנים של שירות הזהויות של GKE, יכול להיות שתופיע השגיאה הבאה:

  E0810 09:58:02.820573       1 webhook.go:127] Failed to make webhook authenticator request:
  error trying to reach service: net/http: TLS handshake timeout

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

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

    curl -k  -s -o /dev/null -w "%{http_code}" -X POST \
  https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

    מחליפים את APISERVER_HOST בכתובת של שרת ה-API.

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

לא נמצאה כתובת URL של דף הכניסה

הבעיה הבאה מתרחשת כשאי אפשר להתחבר לספק הזהויות דרך Google Cloud console. ניסיון להתחבר מופנה לדף עם URL not found שגיאה.

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

  1. אם אי אפשר להגיע לספק הזהויות דרך האינטרנט הציבורי, צריך להפעיל את ה-proxy של OIDC HTTP כדי להיכנס באמצעות Google Cloud המסוף. עורכים את ClientConfig המשאב המותאם אישית ומגדירים את useHTTPProxy ל-true:

    kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG

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

  2. אם פרוקסי ה-HTTP מופעל ואתם עדיין נתקלים בשגיאה הזו, יכול להיות שיש בעיה בהפעלת הפרוקסי. צפייה ביומנים של ה-proxy:

    kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

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

    גם אם לספק הזהויות שלכם יש רשות אישורים מוכרת, אתם צריכים לספק ערך ל-oidc.caPath במשאב המותאם אישית ClientConfig כדי שהפרוקסי של HTTP יופעל בהצלחה.

  3. אם שרת ההרשאות מבקש הסכמה ולא הוספתם את הפרמטרים extraparam prompt=consent, עורכים את המשאב המותאם אישית ClientConfig ומוסיפים את prompt=consent לפרמטרים extraparams:

    kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG

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

  4. אם משנים את הגדרות התצורה בשירות האחסון, יכול להיות שתצטרכו לצאת במפורש מהסשנים הקיימים. במסוף Google Cloud , עוברים לדף פרטי האשכול ולוחצים על Log out (יציאה).

פתרון בעיות ב-LDAP

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

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

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

אימות שאימות LDAP מופעל

לפני שבודקים את אימות LDAP, מוודאים שאימות LDAP מופעל באשכול.

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

    kubectl logs -l k8s-app=ais -n anthos-identity-service

    בדוגמה הבאה של פלט אפשר לראות שאימות LDAP מופעל בצורה תקינה:

    ...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...

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

    Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:

    בודקים את השגיאות הספציפיות שדווחו ומנסים לתקן אותן.

בדיקת אימות LDAP

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

  1. מורידים את Google Cloud CLI.

  2. כדי ליצור את קובץ התצורה לכניסה, מריצים את הפקודה הבאה: gcloud anthos create-login-config

    gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG

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

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

    gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG

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

    • ‫CLUSTER_NAME בשם של אשכול המשתמשים שאליו רוצים להתחבר.
    • ‫AUTH_KUBECONFIG עם קובץ ה-kubeconfig החדש כדי ליצור אותו, כולל פרטי הכניסה לגישה לאשכול. מידע נוסף זמין במאמר אימות לאשכול.

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

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

  5. כדי לבדוק את קובץ ה-kubeconfig החדש שכולל את פרטי הכניסה שלכם, מציגים את רשימת ה-Pods באשכול המשתמשים:

    kubectl get pods --kubeconfig AUTH_KUBECONFIG

    מחליפים את AUTH_KUBECONFIG בנתיב לקובץ ה-kubeconfig של אשכול המשתמשים שנוצר בשלב הקודם.

    Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope

בעיות נפוצות ב-LDAP

אם נתקלתם בבעיות באימות LDAP, כדאי לעיין בבעיות הנפוצות הבאות. פועלים לפי ההנחיות לפתרון הבעיה.

המשתמשים לא יכולים לבצע אימות אם יש פסיקים בשם הנפוץ שלהם

כשמשתמשים ב-LDAP, יכולות להיות בעיות שבהן המשתמשים לא יכולים לעבור אימות אם ה-CN שלהם מכיל פסיק, כמו CN="a,b". אם מפעילים את יומן ניפוי הבאגים של שירות הזהויות של GKE, מדווחת הודעת השגיאה הבאה:

  I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
  'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
  Encountered the following error: Empty entries.

הבעיה הזו מתרחשת כי פלאגין ה-LDAP של שירות הזהויות של GKE מבצע בריחה כפולה של הפסיק. הבעיה הזו מתרחשת רק בגרסאות Google Distributed Cloud 1.13 וגרסאות קודמות.

כדי לפתור את הבעיה, מבצעים אחת מהפעולות הבאות:

  1. משדרגים את האשכול ל-Google Distributed Cloud 1.13 ואילך.
  2. במקום להשתמש ב-CN, צריך לבחור identifierAttribute אחר, כמו sAMAccountName.
  3. מסירים את הפסיקים מתוך ה-CN בספריית ה-LDAP.

כשל באימות באמצעות Google Cloud CLI 1.4.2

ב-Google Cloud CLI anthos-auth 1.4.2, יכול להיות שתופיע הודעת השגיאה הבאה כשמריצים את הפקודה gcloud anthos auth login:

  Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
  failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
  ERROR: Configuring Anthos authentication failed

ביומן של שירות הזהויות של GKE, מופיעה גם השגיאה הבאה:

  I0728 12:43:01.980012      26 authentication_plugin.cc:79] Stopping STS   authentication, unable to decrypt the STS token:
  Decryption failed, no keys in the current key set could decrypt the payload.

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

  1. בודקים אם אתם משתמשים בגרסה 1.4.2 של Google Cloud CLI‏ anthos-auth:

    gcloud anthos auth version

    בדוגמה הבאה של פלט אפשר לראות שהגרסה היא 1.4.2:

    Current Version: v1.4.2

  2. אם אתם מריצים את Google Cloud CLI anthos-auth בגרסה 1.4.2, אתם צריכים לשדרג לגרסה 1.4.3 ואילך.

בעיות נפוצות

בקטע הזה מפורטות בעיות נפוצות שקשורות לאימות ומוסבר איך לפתור אותן.

איבדתם את הגישה לתחנת העבודה של האדמין בגלל שגיאה במפתח ה-SSH‏ permission denied

השגיאה הבאה מתרחשת כשמנסים להתחבר לתחנת העבודה של האדמין ומופיעה הודעה "Permission denied" שדומה לדוגמה הבאה:

Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).

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

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

  1. יוצרים מכונת VM זמנית לחילוץ. המכונה הווירטואלית לשחזור צריכה להתחבר לאותה רשת ולאותו מאגר נתונים שאליהם מחוברת המכונה הווירטואלית הנוכחית של תחנת העבודה של האדמין.

  2. מכבים את ה-VM של תחנת העבודה של האדמין ואת ה-VM של החילוץ.

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

  4. מפעילים את מכונת ה-VM של החילוץ.

  5. מתחברים למכונת ההצלה באמצעות SSH.

  6. במחשב המקומי, יוצרים זוג חדש של מפתחות SSH.

  7. במחשב המקומי, מעתיקים את המפתח הציבורי החדש של SSH למכונת החילוץ באמצעות הפקודה ssh-copy-id:

    ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM

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

    • ‫NEW_SSH_KEY בשם של מפתח ה-SSH החדש שיצרתם בשלב הקודם.
    • ‫RESCUE_VM מחליפים בכתובת ה-IP או ב-FQDN של המכונה הווירטואלית לשחזור.

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

    sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk

    מחליפים את DEVICE במזהה הייחודי של הדיסק, לדוגמה, /dev/sdb1.

  9. ב-VM של החילוץ, מעתיקים את מפתח ה-SSH הציבורי החדש לקובץ authorized_keys בדיסק הנתונים המצורף מ-VM של תחנת העבודה של האדמין.

    מציגים את התוכן של הקובץ authorized_keys במכונה הווירטואלית של החילוץ, שכולל את המפתח הציבורי החדש של SSH שהועתק באמצעות הפקודה ssh-copy-id בשלב הקודם:

    ls ~/.ssh/authorized_keys

    מעתיקים את הרשומה האחרונה של המפתח הציבורי של SSH מהקובץ authorized_keys וסוגרים את הקובץ.

  10. עורכים את קובץ authorized_keys בדיסק הנתונים המצורף מה-VM של תחנת העבודה של האדמין:

    vi /mnt/ext-disk/.ssh/authorized_keys

    מדביקים את התוכן של המפתח הציבורי SSH מקובץ authorized_keys של מכונת ה-VM לשחזור.

  11. שומרים וסוגרים את קובץ authorized_keys בדיסק הנתונים המצורף מהמכונה הווירטואלית של תחנת העבודה של האדמין.

  12. מוודאים שההרשאות הנכונות חלות על הקבצים בתיקייה /mnt/ext-disk/.ssh/:

    chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*

  13. יוצאים מחיבור ה-SSH למכונת השחזור.

  14. מכבים את מכונת ה-VM של החילוץ.

  15. מנתקים את דיסק הנתונים מהמכונה הווירטואלית של התיקון ומחברים מחדש את הדיסק למכונה הווירטואלית של תחנת העבודה של האדמין.

  16. מפעילים את תחנת העבודה של האדמין.

  17. אחרי שהמכונה הווירטואלית פועלת, מתחברים לתחנת העבודה של האדמין באמצעות SSH וזוג מפתחות SSH החדש.

    ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM

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

    • ‫NEW_SSH_KEY בשם של מפתח ה-SSH החדש שיצרתם בשלב הקודם והעתקתם למכונה הווירטואלית של תחנת העבודה של האדמין.
    • ‫RESCUE_VM מחליפים בכתובת ה-IP או ב-FQDN של המכונה הווירטואלית של תחנת העבודה של האדמין.

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

  18. מוחקים את מכונת ה-VM לשחזור.

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

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

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