פתרון בעיות בספקי OIDC באשכולות של חברי צי

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

פורמט שגוי של האישור

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

הודעות שגיאה

הדוגמאות הבאות הן של הודעות שגיאה שמוצגות בתרחישים שבהם הפורמט של האישור שגוי:

  • אישור שלא מקודד ב-Base64: Failed creating HTTP client to fetch the Discovery URI "<Discovery-document URI>" with error: Unable to decode data field, the value should be Base64 encoded

  • אישור שלא בפורמט הנכון או בקידוד base64 לא תקין: Unable to connect to 'https://example.com', encountered the following error: Problem with the SSL CA cert (path? access rights?). Details: error setting certificate verify locations: CAfile: /tmp/example.pem CApath: none (The certificate could not be read, this is most likely because it's empty or contains a formatting error. Please check your configuration.)

  • אישור שלא בפורמט הנכון או בקידוד base64 לא תקין: Failed fetching the Discovery URI "<Discovery-document URI>" with error: Unable to load TLS certificates.

פתרון

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

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

ערך האישור שגוי

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

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

  • ערך אישור שגוי משותף ב-ClientConfig. ערך האישור שגוי אם issuer של אישור השרת לא תואם לsubject של האישור שהוגדר.
  • האישור ב-ClientConfig הוא לא מחרוזת בקידוד Base64.
  • שרשרת האישורים לא מסופקת כשמשתמשים באישורים ברמת הביניים כדי להנפיק את אישור השרת.

הודעת השגיאה

הדוגמאות הבאות הן של הודעות שגיאה שמוצגות בתרחישים שבהם יש חוסר התאמה בערך האישור:

  • שרשרת האישורים לא מלאה או לא תואמת לשרת: SSL peer certificate was not OK. Details: SSL certificate problem: unable to get local issuer certificate

  • שרשרת האישורים לא מלאה (היא תואמת לשרשרת חלקית לא חוקית שלא מתחילה בשורש או שלא רציפה): Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.

  • שרשרת האישורים תקפה אבל לא תואמת לשרת OIDC: AIS was expecting the server to have a different certificate

  • שרשרת האישורים תקפה אבל לא תואמת לשרת OIDC: Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.

פתרון

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

פקודות kubectl נכשלות כשמשתמשים בקובץ kubeconfig שנוצר על ידי הפקודה gcloud anthos auth login

כשמשתמשים בפקודה gcloud anthos auth login עם OIDC במחשבי Windows כדי ליצור קובץ kubeconfig לגישה לאשכול, יכול להיות שהפקודות kubectl ייכשלו עם הודעת השגיאה הבאה: The command line is too long. הבעיה הזו מתרחשת במערכות Windows בלבד, ולא משפיעה על מחשבי Linux שמשתמשים באותו קובץ kubeconfig. הסיבה הבסיסית קשורה לגודל של אסימון האימות שנוצר על ידי Azure Active Directory ‏ (Azure AD) כשמשתמש שייך למספר גדול של קבוצות (בערך 70 עד 200 קבוצות, בהתאם לאורך של שמות הקבוצות).

הטוקן הגדול הזה גורם לכשל בהרצת הפקודות kubectl כי הוא חורג מהאורך המקסימלי של שורת הפקודה שמותרת על ידי Windows, שהוא 8,191 תווים.

הודעת השגיאה

$ kubectl --kubeconfig test-kubeconfig.yml get nodes

The command line is too long.
The command line is too long.
E0102 11:02:29.115256 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
The command line is too long.
E0102 11:02:29.350238 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
The command line is too long.
E0102 11:02:30.062811 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
Unable to connect to the server: getting credentials: exec: executable gcloud failed with exit code 1

פתרון

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

  • שדרוג לגרסה 1.28 ואילך

    אם אתם מפעילים גרסה מוקדמת יותר מ-1.28, מומלץ לשדרג לגרסה הנתמכת.

  • הפחתת מספר הקבוצות שהמשתמש המושפע חבר בהן

    כדי לפתור את הבעיה, אפשר לצמצם את מספר הקבוצות שהמשתמש שמאומת שייך אליהן כך שיהיה מתחת לסף הבעייתי (כ-70 קבוצות).

  • הגדלת מספר הקבוצות שהמשתמש מושפע מהן

    לתכונה Microsoft Entra ID יש מגבלה על מספר הקבוצות שמופיעות באסימון. אם יש לכם בין 70 ל-200 חברויות בקבוצות, יכול להיות שתיתקלו בבעיות באימות. עם זאת, אפשר לפתור את הבעיות בספק הזהות על ידי הגדלת מספר החברויות בקבוצות מעבר למגבלה הזו. בגלל ההתנהגות של המגבלה הזו, Azure AD משמיט קבוצות מהפקודה id_token כשהמספר של החברויות הופך לגדול מדי, וכך מונע את הארכת שורת הפקודה ומטפל בבעיות של ספק הזהויות. כדאי לעיין במסמכי התיעוד של Microsoft Entra ID כדי לוודא מה המגבלה ולקבל פרטים נוספים.