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

כדי לאבחן ולפתור כשלים באימות ובהרשאה ב-Google Distributed Cloud, אתם יכולים לבדוק את ההתקנה של gcloud anthos auth, את הטוקנים, את הרשאות ה-RBAC, את הקישוריות לרשת ואת ההגדרות של GKE Identity Service. הבדיקות האלה עוזרות לבודד שגיאות של OpenID Connect‏ (OIDC) ושל Lightweight Directory Access Protocol‏ (LDAP), ולשחזר את הגישה של המשתמשים לאשכולות.

לפני שאתם פותרים בעיות באימות, ודאו שהגדרתם ספק זהויות חיצוני, כמו Google OIDC,‏ Microsoft AD FS,‏ Microsoft Entra ID,‏ Okta או ספק LDAP. כדי לבדוק יומני בקשות מפורטים ולבדוק את יכולת ההגעה (reachability) של הספק, אפשר לעיין במדריך לפתרון בעיות של ספק הזהויות ב-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 לא יכול לקרוא את הגדרת ה-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 נכשלת עם proxyconnect tcp

הבעיה הזו מתרחשת כשיש שגיאה בהגדרות של משתני הסביבה https_proxy או HTTPS_PROXY. אם צוין https:// במשתני הסביבה, יכול להיות שספריות הלקוח של GoLang HTTP ייכשלו אם שרת ה-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 בשרת ה-API של Kubernetes. כשהאסימון מוצג לשרת ה-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 באשכול. שימו לב לקו הנטוי היחיד בשדה השם, במקום קו נטוי כפול:

    ‫Group 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

    ‫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 כשמוצג לו הטוקן של המזהה. כדי לבדוק אם היו בעיות בפלאגין של 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 Identity Service פועל כמו שצריך או מזהים בעיה, בודקים את המידע הבא לפתרון בעיות ב-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 .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    כדי לאבחן ולפתור בעיות ב-OIDC, צוות התמיכה שלGoogle Cloud צריך את יומני השירות של GKE Identity Service ואת מפרט ה-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 Identity Service. ה-Pod של GKE Identity Service לא יכול להפעיל את ה-webhook לאימות.

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

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

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

    הפלט לדוגמה הבא מציין ש-Pod של 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 Identity Service:

  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 Identity Service יש תהליך דימון (daemon) לסנכרון תקופתי של כתובת ה-URL של מסמך Discovery של OIDC כל 5 שניות. אם החיבור לרשת לא יציב, יכול להיות שהבקשה הזו לייצוא נתונים תיכשל. כשלים מדי פעם לא משפיעים על אימות ה-OIDC. אפשר להשתמש מחדש בנתונים הקיימים במטמון.

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

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

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

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

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

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

  You must be logged in to the server (Unauthorized)

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

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

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

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

  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 Identity Service.

  1. כדי לבדוק אם אפשר להגיע לנקודת הקצה של GKE Identity Service מבחוץ, מריצים את הפקודה הבאה של 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 Identity Service. אם השגיאה נמשכת, סימן ששרת ה-HTTP של GKE Identity Service לא מצליח להתחיל לפעול. לקבלת עזרה נוספת, אפשר לפנות לתמיכה של Google Cloud .

כתובת ה-URL לכניסה לא נמצאה

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

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

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

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

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

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

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

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

    גם אם לספק הזהויות יש רשות אישורים (CA) מוכרת, צריך לספק ערך ל-oidc.caPath במשאב בהתאמה אישית של ClientConfig כדי ששרת ה-Proxy ל-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 Identity Service פועל כצפוי או מזהים בעיה, בודקים את המידע הבא לפתרון בעיות ב-LDAP.

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

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

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

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

    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, כדאי לעיין בבעיות הנפוצות הבאות. פועלים לפי ההנחיות לפתרון הבעיה.

המשתמשים לא יכולים לבצע אימות אם יש פסיקים בשם המקובל (CN) שלהם

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

  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 Identity Service מוסיף תו בריחה כפול לפסיק. הבעיה הזו קורית רק בגרסאות Google Distributed Cloud 1.13 וגרסאות קודמות.

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

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

כשל באימות ב-Google Cloud CLI בגרסה 1.4.2

בגרסה 1.4.2 של Google Cloud CLI anthos-auth, יכול להיות שתופיע הודעת השגיאה הבאה כשמריצים את הפקודה 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 Identity Service, מופיעה גם השגיאה הבאה:

  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 ואילך.

בעיות נפוצות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  8. ב-VM החילוץ, טוענים את דיסק הנתונים:

    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 בדיסק הנתונים שנטען מה-VM של תחנת העבודה של האדמין.

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

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

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

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

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

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

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

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

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

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

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

  18. מוחקים את ה-VM לחילוץ.

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

אם אתם צריכים עזרה נוספת, תוכלו לפנות אל Cloud Customer Care.

במאמר קבלת תמיכה תוכלו לקרוא מידע נוסף על מקורות המידע לתמיכה, כולל: