הגדרה של ספקי 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. בוחרים באפשרות Enter data about relying party manually (הזנת נתונים על הצד המסתמך באופן ידני).

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

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

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

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

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

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

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

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

  3. בשדה שם כלל ההצהרה, מזינים 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, מסמנים את התיבה Group.Read.All. בכרטיסייה User, מסמנים את התיבה 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.

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

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