הגדרה של ספקי OIDC לאימות באשכולות

המסמך הזה מיועד לאדמינים של הפלטפורמה או לכל מי שמנהל את הגדרת הזהויות בארגון שלכם. במאמר הזה מוסבר איך להגדיר את ספק הזהויות שבחרתם ב-OpenID Connect ‏ (OIDC) לאימות באשכולות Kubernetes שלא נמצאים ב- Google Cloud.

רישום אפליקציית לקוח אצל הספק

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

לגבי כתובות URL להפניה אוטומטית, מציינים את הערכים הבאים:

  • ‫https://console.cloud.google.com/kubernetes/oidc היא כתובת ה-URL להפניה אוטומטית של מסוף Google Cloud .
  • ‫http://localhost:PORT/callback הוא כתובת ה-URL להפניה אוטומטית עבור ה-CLI של gcloud. אפשר לציין כל מספר יציאה שגדול מ-1024.
  • ‫APISERVER_URL:11001/finish-login היא כתובת ה-URL להפניה אם בוחרים לאמת באמצעות גישה ל-FQDN. מחליפים את APISERVER_URL ב-FQDN של שרת ה-API של Kubernetes באשכול. לדוגמה, אם הערך של APISERVER_URL הוא https://apiserver.company.com, הערך של redirect_uri צריך להיות https://apiserver.company.com:11001/finish-login.

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

פרטי ההגדרה של ספק הזהויות

בקטע הזה מוסבר איך לרשום אפליקציית לקוח ב-Microsoft Active Directory Federation Services‏ (AD FS) או ב-Microsoft Entra ID.

Microsoft AD FS

משתמשים בסדרה של אשפי ניהול של AD FS כדי להגדיר את שרת AD FS ואת מסד הנתונים של משתמשי AD.

  1. פותחים את חלונית הניהול של AD FS.

  2. בוחרים באפשרות Application Groups (קבוצות אפליקציות) > Actions (פעולות) > Add an Application Group (הוספת קבוצת אפליקציות).

  3. בוחרים באפשרות Server Application (אפליקציית שרת). מזינים שם ותיאור לבחירתכם. לוחצים על Next.

  4. מזינים את שתי כתובות ה-URL להפניה אוטומטית, כמו שצוין למעלה. מקבלים מזהה לקוח. מזהה הלקוח הזה משמש את AD FS לזיהוי האשכול. שומרים את מזהה הלקוח למועד מאוחר יותר.

  5. בוחרים באפשרות יצירת סוד לשימוש עם טוקן צרכן. מנגנון האימות של Kubernetes משתמש בסוד הזה כדי לבצע אימות בשרת AD FS. שומרים את הסוד למועד מאוחר יותר.

הגדרת קבוצות אבטחה (אופציונלי)

  1. בניהול AD FS, בוחרים באפשרות Relying party trusts (יחסי אמון של צדדים מסתמכים) > Add a new relying party trust (הוספת יחסי אמון חדשים של צדדים מסתמכים).

  2. בוחרים באפשרות Claims aware ולוחצים על Start (התחלה).

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

  4. מזינים שם לתצוגה.

  5. מדלגים על שני השלבים הבאים.

  6. מזינים מזהה של צד נסמך. הצעה: token-groups-claim.

  7. בשדה Access control policy, בוחרים באפשרות Permit everyone. המשמעות היא שכל המשתמשים משתפים את פרטי קבוצת האבטחה שלהם עם ה-CLI של gcloud ועם מסוףGoogle Cloud .

  8. לוחצים על סיום.

מיפוי מאפייני LDAP לשמות של הצהרות

  1. בניהול AD FS, בוחרים באפשרות Relying party trusts (אמון צד נסמך) > Edit claim issuance policy (עריכת מדיניות הנפקת טענות).

  2. בוחרים באפשרות שליחת מאפייני LDAP כטענות ולוחצים על הבא.

  3. בשדה Claim rule name, מזינים groups.

  4. בקטע מאגר מאפיינים, בוחרים באפשרות Active Directory.

  5. בטבלה, בעמודה מאפיין LDAP, בוחרים באחת מהאפשרויות הבאות:

    • ‫AD FS מגרסה 5.0 ואילך: Token-Groups Qualified by Domain name
    • גרסאות AD FS לפני 5.0: Token Groups - Qualified Names

  6. בקטע Outgoing Claim Type (סוג התלונה היוצאת), בוחרים באפשרות:

    • ‫AD FS מגרסה 5.0 ואילך: Group
    • גרסאות AD FS לפני 5.0: groups

  7. לוחצים על סיום ואז על אישור.

רישום אפליקציית הלקוח של Kubernetes ב-AD FS

פותחים חלון PowerShell במצב אדמין ומזינים את הפקודה הבאה:

Grant-AD FSApplicationPermission `
  -ClientRoleIdentifier "[CLIENT_ID]" `
 -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] `
  -ScopeName "allatclaims", "openid"

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

  • ‫[CLIENT_ID] הוא מזהה הלקוח שקיבלתם קודם.

  • ‫[SERVER_ROLE_IDENTIFIER] הוא מזהה התלונה שהזנתם קודם. המזהה המוצע היה token-groups-claim.

Microsoft Entra ID

כדי לרשום לקוח OAuth ב-Microsoft Entra ID, מבצעים את השלבים בקישורים הבאים:

  1. אם עדיין לא עשיתם זאת, מגדירים דייר של Microsoft Entra.

  2. רישום אפליקציה ב-Microsoft Entra ID.

  3. במרכז הניהול של Microsoft Entra, פותחים את הדף App registrations ובוחרים את האפליקציה. ייפתח דף הסקירה הכללית של האפליקציה.

  4. יוצרים סוד לקוח:

    1. בתפריט הניווט, לוחצים על Certificates & Secrets (אישורים וסודות).
    2. לוחצים על הכרטיסייה Client secrets.
    3. לוחצים על New client secret (סוד לקוח חדש). נותנים שם לסוד ולוחצים על הוספה.
    4. שומרים את הערך של הסוד במקום מאובטח. לא תוכלו לשחזר אותו אחרי שתסגרו או תרעננו את הדף.

    מידע נוסף מופיע במאמר בנושא הוספה וניהול של פרטי כניסה לאפליקציות ב-Microsoft Entra ID.

  5. הוספת כתובות URI להפניה אוטומטית:

    1. בתפריט הניווט, לוחצים על אימות.
    2. בקטע הגדרות פלטפורמה, לוחצים על הוספת פלטפורמה. ייפתח החלונית Configure platforms (הגדרת פלטפורמות).
    3. לוחצים על אתר.
    4. בשדה Redirect URIs (כתובות URI להפניה אוטומטית), מזינים http://localhost:PORT/callback לזרימת הכניסה ל-CLI של gcloud. בוחרים PORT גדול מ-1024.
    5. לוחצים על Configure (הגדרה).
    6. כדי להוסיף עוד URI, לוחצים על הוספת URI.
    7. מזינים https://console.cloud.google.com/kubernetes/oidc בתהליך הכניסה למסוףGoogle Cloud .
    8. שומרים את ההגדרה.

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

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

  • ‫Issuer URI: ‏https://login.microsoftonline.com/TENANT_ID/v2.0. מזהה הדייר מוצג כ-Directory (tenant) ID בדף הסקירה הכללית של האפליקציה במרכז הניהול של Microsoft Entra.

  • Client ID: מזהה הלקוח מוצג כ-Application (client) ID בדף סקירת האפליקציה במרכז הניהול של Microsoft Entra.

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

הגדרה מתקדמת של Microsoft Entra ID

מומלץ להשתמש בהגדרה המתקדמת הזו רק כשרוצים להגדיר אשכולות עם מדיניות הרשאות מבוססת-קבוצות של Microsoft Entra ID, שבה משתמשים באשכולות שייכים ליותר מ-200 קבוצות של Microsoft Entra ID. ההגדרה המתקדמת של Microsoft Entra ID תומכת בפלטפורמות הבאות:

  • ‫Google Distributed Cloud מקומי (גם VMware וגם שרת פיזי): מגרסה 1.14
  • ‫GKE ב-AWS: מגרסה 1.14 (גרסת Kubernetes‏ 1.25 ואילך)
  • ‫GKE ב-Azure: מגרסה 1.14 (גרסת Kubernetes‏ 1.25 ואילך)

לפני שמתחילים, חשוב לוודא שלכל משתמש יש כתובת אימייל משויכת שהוגדרה כמזהה שלו ב-Microsoft Entra ID. כתובת האימייל הזו משמשת לאימות הזהות של המשתמש ולאימות הבקשה.

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

כדי לבצע את שלב ההגדרה הזה, צריך הרשאות של אדמין גלובלי או אדמין ארגוני.

  1. נכנסים למרכז הניהול של Microsoft Entra.
  2. בוחרים את דייר Microsoft Entra שכולל את אפליקציית הלקוח.
  3. בוחרים באפשרות App registrations (רישום אפליקציות) ואז בוחרים באפליקציית הלקוח.
  4. בוחרים באפשרות API permissions - Add a permission - Microsoft Graph - Delegated permissions (הרשאות ל-API – הוספת הרשאה – Microsoft Graph – הרשאות מוקצות).
  5. בכרטיסייה קבוצה, מסמנים את התיבה Group.Read.All. בכרטיסייה משתמש, מסמנים את התיבה User.Read.All.
  6. כדי לסיים את התהליך, לוחצים על הוספת הרשאות.
  7. כדי להעניק הסכמה בשם כל המשתמשים, לוחצים על הענקת הסכמת אדמין עבור.... מידע נוסף זמין במאמר מידע נוסף על הרשאות API והסכמת אדמין.

שיתוף פרטי ספק הזהויות

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

  • ה-URI של המנפיק של הספק
  • סוד הלקוח
  • מזהה הלקוח
  • ה-URI והיציאה להפניה אוטומטית שציינתם עבור ה-CLI של gcloud
  • שדה שם המשתמש (הצהרה) שהספק משתמש בו כדי לזהות משתמשים באסימונים שלו (ברירת המחדל המשוערת כשמגדירים אשכולות היא sub)
  • השדה (הצהרה) של שם הקבוצה שספק הזהויות משתמש בו כדי להחזיר קבוצות אבטחה, אם יש כאלה.
  • היקפים או פרמטרים נוספים שספציפיים לספק שלכם, כמו שמתואר בקטע הקודם. לדוגמה, אם שרת ההרשאות מבקש הסכמה לאימות באמצעות Microsoft Entra ID ו-Okta, האדמין של האשכול צריך לציין את prompt=consent כפרמטר. אם הגדרתם את AD FS לספק מידע על קבוצות אבטחה, הפרמטר הנוסף הרלוונטי הוא resource=token-groups-claim (או כל מזהה אחר שבחרתם עבור יחסי האמון של הצד המסתמך).
  • (אופציונלי) אם הספק שלכם לא משתמש באישור שחתום על ידי רשות אישורים ציבורית (לדוגמה, אם אתם משתמשים באישורים בחתימה עצמית), תצטרכו אישור (או שרשרת אישורים) של ספק הזהויות. האישור (או שרשרת האישורים) צריך להכיל לפחות את אישור הבסיס (מקובלות שרשרות חלקיות, כל עוד השרשרת רציפה עד לאישור הבסיס). כשמספקים את הערך הזה ב-ClientConfig, צריך לעצב אותו כמחרוזת בקידוד Base64. כדי ליצור את המחרוזת, משרשרים את האישורים המלאים בקידוד PEM למחרוזת אחת ואז מקודדים אותה ב-Base64.

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

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