חיבור לספק זהויות

בדף הזה מוסבר איך לחבר את Google Distributed Cloud (GDC)‎ עם air gap לספק הזהויות (IdP) הקיים של הארגון. ספק זהויות הוא מערכת שמנהלת ומאבטחת באופן מרוכז את זהויות המשתמשים, ומספקת שירותי אימות. התחברות ל-IdP קיים מאפשרת למשתמשים לגשת ל-GDC באמצעות פרטי הכניסה של הארגון שלהם, בלי ליצור או לנהל חשבונות נפרדים ב-GDC. התהליך הזה מבטיח חוויית התחברות חלקה ומאובטחת. מכיוון ש-IdP הוא משאב גלובלי, המשתמשים יכולים לגשת ל-GDC דרך אותו IdP, בלי קשר לאזור שבו הם עובדים.

הדף הזה מיועד למשתמשים בקבוצת האדמינים של הפלטפורמה, כמו אדמינים ממחלקת IT או מהנדסי אבטחה, שרוצים להתחבר ל-IdP. מידע נוסף זמין במאמר קהלי היעד של GDC עם air gap.

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

לפני שמתחילים

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

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

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

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

בקשת תפקידים ב-IAM

כדי ליצור, לקרוא, לעדכן ולמחוק הגדרות של ספקי זהויות, צריך לבקש ממנהל חשבון ארגוני ב-IAM את התפקיד אדמין של איחוד IdP (idp-federation-admin).

חשוב לוודא שהאדמין הראשוני שאתם מציינים כשאתם מחברים את ספק הזהויות הוא בעל התפקיד מנהל חשבון ארגוני ב-IAM (organization-iam-admin).

הכנת הסביבה

חיבור לספק זהויות קיים

כדי לחבר את ספק הזהויות, צריך מזהה לקוח וסוד לקוח יחידים מספק הזהויות. אתם יכולים להתחבר לספק OIDC או לספק SAML קיים.

חיבור לספק OIDC קיים

כדי להתחבר לספק OIDC קיים, מבצעים את השלבים הבאים:

המסוף

  1. נכנסים למסוף GDC. בדוגמה הבאה מוצג המסוף אחרי הכניסה לארגון שנקרא org-1: דף קבלת פנים של המסוף עם קישורים לגישה מהירה למשימות נפוצות
  2. בתפריט הניווט, לוחצים על Identity and Access > Identity.
  3. לוחצים על הוספת ספק זהויות.
  4. בקטע Configure identity provider, מבצעים את הפעולות הבאות:

    1. בתפריט הנפתח Identity provider, בוחרים באפשרות Open ID Connect (OIDC).
    2. מזינים שם של ספק זהויות.
    3. בשדה Issuer URI, מזינים את כתובת ה-URL שאליה נשלחות בקשות ההרשאה לספק הזהויות. שרת ה-API של Kubernetes משתמש בכתובת ה-URL הזו כדי לגלות מפתחות ציבוריים לאימות טוקנים. כתובת ה-URL חייבת להשתמש ב-HTTPS.
    4. בשדה מזהה לקוח, מזינים את המזהה של אפליקציית הלקוח ששולחת בקשות אימות לספק הזהויות.
    5. בשדה Client Secret, מזינים את סוד הלקוח, שהוא סוד משותף בין ספק הזהויות לבין Distributed Cloud.
    6. אופציונלי: בשדה קידומת של ספק הזהויות, מזינים קידומת. התחילית מתווספת לתחילת ההצהרות של המשתמשים וההצהרות של הקבוצות. התחיליות משמשות כדי להבדיל בין הגדרות שונות של ספקי זהויות. לדוגמה, אם מגדירים את הקידומת myidp, יכול להיות שהצהרת המשתמש תהיה myidp-username@example.com והצהרת הקבוצה תהיה myidp-group@example.com. צריך לכלול את הקידומת גם כשמקצים הרשאות של בקרת גישה מבוססת-תפקידים (RBAC) לקבוצות.

    7. אופציונלי: בקטע Encryption, בוחרים באפשרות Enable encryption tokens.

      כדי להפעיל אסימוני הצפנה, צריך לבקש ממנהל חשבון ארגוני ב-IAM להקצות לכם את התפקיד "אדמין של איחוד IdP" (idp-federation-admin).

      1. בשדה Key ID (מזהה המפתח), מזינים את מזהה המפתח. מזהה המפתח מזהה את המפתח הציבורי של אסימון הצפנת אינטרנט מסוג JSON‏ (JWE). ספק ה-OIDC מגדיר ומקצה מזהה מפתח.
      2. בשדה Decryption key, מזינים את מפתח הפענוח בפורמט PEM. מפתח הפענוח הוא מפתח אסימטרי שמשמש לפענוח טוקנים. ספק ה-OIDC מגדיר ומקצה מפתח פענוח.
    8. לוחצים על הבא.

  5. בקטע Configure attributes, מבצעים את הפעולות הבאות:

    1. בשדה Certificate authority for OIDC provider, מזינים אישור בקידוד PEM ובקידוד Base64 של ספק הזהויות. מידע נוסף זמין במאמר Privacy-Enhanced Mail בוויקיפדיה.
      1. כדי ליצור את המחרוזת, מקודדים את האישור, כולל הכותרות, ל-base64.
      2. כוללים את המחרוזת שנוצרה בשורה אחת. לדוגמה: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==
    2. בשדה Group Claim, מזינים את שם ההצהרה בטוקן של ספק הזהויות שמכיל את פרטי הקבוצה של המשתמש.
    3. בשדה User Claim, מזינים את ההצהרה לזיהוי כל משתמש. התביעה שמוגדרת כברירת מחדל אצל הרבה ספקים היא sub. אפשר לבחור הצהרות אחרות, כמו email או name, בהתאם לספק הזהויות. הצהרות שאינן email כוללות קידומת של כתובת ה-URL של המנפיק כדי למנוע התנגשויות בשמות.
    4. אופציונלי: בקטע מאפיינים מותאמים אישית, לוחצים על הוספת צמד ומזינים צמדי מפתח/ערך להצהרות נוספות על משתמש, כמו המחלקה או כתובת ה-URL של תמונת הפרופיל שלו.
    5. אם ספק הזהויות דורש היקפים נוספים, בשדה Scopes מזינים את ההיקפים שרוצים לשלוח לספק הזהויות, מופרדים בפסיקים.
    6. בקטע Extra parameters, מזינים את כל צמדי המפתח/ערך הנוספים (מופרדים בפסיקים) שנדרשים על ידי ספק הזהויות. אם אתם נותנים הרשאה לקבוצה, צריך להעביר את resource=token-groups-claim.
    7. לוחצים על הבא.
  6. בקטע Specify initial admins, מבצעים את הפעולות הבאות:

    1. בוחרים אם להוסיף משתמשים בודדים או קבוצות כאדמינים ראשוניים.
    2. בשדה שם משתמש או כתובת אימייל חלופית של קבוצה, מזינים את כתובת האימייל של המשתמש או הקבוצה שרוצים לתת להם גישה לארגון. אם אתם האדמין, הזינו את כתובת האימייל שלכם, לדוגמה kiran@example.com. התחילית מתווספת לפני שם המשתמש, למשל myidp-kiran@example.com.
    3. לוחצים על הבא.
  7. בודקים את האפשרויות שנבחרו ולוחצים על הגדרה.

הפרופיל החדש של ספק הזהויות מופיע ברשימה "פרופילים של זהויות".

API

כדי לקשר את ספק הזהויות לארגון, יוצרים את המשאב הגלובלי המותאם אישית של IdentityProviderConfig.

  1. יוצרים קובץ YAML של משאב בהתאמה אישית של IdentityProviderConfig, למשל pa-idp-oidc.yaml:

    apiVersion: iam.global.gdc.goog/v1
    kind: IdentityProviderConfig
    metadata:
      name: pa-idp-oidc
      namespace: platform
    spec:
      oidc:
        certificateAuthorityData: "IDP_BASE64_ENCODED_CERTIFICATE"
        clientID: IDP_CLIENT_ID
        clientSecret: IDP_CLIENT_SECRET
        groupPrefix: IDP_GROUP_PREFIX
        groupsClaim: IDP_GROUP_CLAIM
        issuerURI: IDP_ISSUER_URI
        scopes: openid,email,profile
        userClaim: IDP_USER_CLAIM
        userPrefix: IDP_USER_PREFIX
    

    מחליפים את המשתנים הבאים:

    • ‫IDP_BASE64_ENCODED_CERTIFICATE: האישור בקידוד base64 ל-IdP.
    • ‫IDP_CLIENT_ID: מזהה הלקוח של ה-IdP.
    • ‫IDP_CLIENT_SECRET: סוד הלקוח של ה-IdP.
    • ‫IDP_GROUP_PREFIX: הקידומת של הקבוצות ב-IdP.
    • ‫IDP_GROUP_CLAIM: שם ההצהרה באסימון של ספק הזהויות שמקבץ את המידע.
    • ‫IDP_ISSUER_URI: ה-URI של מנפיק ה-IdP.
    • ‫IDP_USER_CLAIM: שם ההצהרה באסימון IdP של המשתמש.
    • ‫IDP_USER_PREFIX: הקידומת של ה-IdP של המשתמש.
  2. מחילים את המשאב המותאם אישית IdentityProviderConfig על שרת ה-API הגלובלי:

    kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f pa-idp-oidc.yaml
    

    מחליפים את המשתנה GLOBAL_API_SERVER_KUBECONFIG בנתיב לקובץ kubeconfig של שרת ה-API הגלובלי.

התחברות לספק SAML קיים

כדי להתחבר לספק SAML קיים:

המסוף

  1. נכנסים למסוף GDC. בדוגמה הבאה מוצג המסוף אחרי הכניסה לארגון שנקרא org-1: דף קבלת פנים של המסוף עם קישורים לגישה מהירה למשימות נפוצות
  2. בתפריט הניווט, לוחצים על Identity and Access > Identity.
  3. לוחצים על הוספת ספק זהויות.
  4. בקטע Configure identity provider, מבצעים את הפעולות הבאות:

    1. בתפריט הנפתח Identity provider, בוחרים באפשרות Security Assertion Markup Language (SAML)‎.
    2. מזינים שם של ספק זהויות.
    3. בשדה Identity ID, מזינים את המזהה של אפליקציית הלקוח ששולחת בקשות אימות לספק הזהויות.
    4. בשדה SSO URI, מזינים את כתובת ה-URL של נקודת הקצה לכניסה יחידה של הספק. לדוגמה: https://www.idp.com/saml/sso.
    5. בשדה Identity provider prefix, מזינים קידומת. התחילית מתווספת לתחילת ההצהרות של המשתמשים והקבוצות. הקידומות מבדילות בין הגדרות שונות של ספקי זהויות. לדוגמה: אם מגדירים את הקידומת myidp, יכול להיות שתביעת משתמש תוצג בתור myidp-username@example.com ותביעת קבוצה תוצג בתור myidp-group@example.com. כשמקצים הרשאות RBAC לקבוצות, צריך לכלול גם את הקידומת.

    6. כדי לשפר את האבטחה, הגדירו את ספק ה-SAML כך שינפיק טענות נכוֹנוּת עם משך חיים של 5 עד 10 דקות. אפשר לקבוע את ההגדרה הזו בהגדרות של ספק ה-SAML.

    7. אופציונלי: בקטע טענות נכוֹנוּת (assertion) של SAML, בוחרים באפשרות הפעלת הצפנה של טענות נכוֹנוּת (assertion) של SAML.

      כדי להפעיל טענות נכוֹנוּת מוצפנות של SAML, צריך לבקש ממנהל חשבון ארגוני ב-IAM להקצות לכם את התפקיד "אדמין של איחוד IdP‏" (idp-federation-admin).

      1. בשדה אישור טענת נכוֹנוּת (assertion) של הצפנה, מזינים את אישור ההצפנה בפורמט PEM. אתם מקבלים את אישור ההצפנה מספק ה-SAML שלכם.
      2. בשדה מפתח טענת נכוֹנוּת (Assertion) להצפנה, מזינים את המפתח הפרטי. מקבלים את מפתח הפענוח אחרי שיוצרים את ספק ה-SAML.
    8. אופציונלי: בקטע SAML Signed Requests, בוחרים באפשרות Enable signed SAML requests.

      1. בשדה Signing certificate, מזינים את אישור החתימה בפורמט קובץ PEM. ספק ה-SAML שלכם מנפיק אישור חתימה.
      2. בשדה Signing key, מזינים את מפתח החתימה בפורמט קובץ PEM. ספק ה-SAML מגדיר ומייצר מפתח חתימה.
    9. לוחצים על הבא.

  5. בדף Configure attributes, מבצעים את הפעולות הבאות:

    1. בשדה IDP certificate, מזינים אישור בקידוד PEM ובקידוד Base64 של ספק הזהויות. מידע נוסף זמין במאמר Privacy-Enhanced Mail בוויקיפדיה.
      1. כדי ליצור את המחרוזת, מקודדים את האישור, כולל הכותרות, ל-base64.
      2. כוללים את המחרוזת שנוצרה בשורה אחת. לדוגמה: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==.
    2. מזינים אישורים נוספים בשדה אישור IDP נוסף.
    3. בשדה User attribute, מזינים את המאפיין לזיהוי כל משתמש. מאפיין ברירת המחדל של ספקים רבים הוא sub. אתם יכולים לבחור מאפיינים אחרים, כמו email או name, בהתאם לספק הזהויות. מאפיינים אחרים מלבד email כוללים קידומת של כתובת ה-URL של המנפיק כדי למנוע התנגשויות בשמות.
    4. בשדה מאפיין ראשי, מזינים את שם המאפיין בטוקן של ספק הזהויות שמכיל את פרטי הקבוצה של המשתמש.
    5. אופציונלי: בקטע מיפוי מאפיינים, לוחצים על הוספת צמד ומזינים צמדי מפתח/ערך למאפיינים נוספים של המשתמש, כמו המחלקה או כתובת ה-URL של תמונת הפרופיל שלו.
    6. לוחצים על הבא.
  6. בקטע Specify initial admins, מבצעים את הפעולות הבאות:

    1. בוחרים אם להוסיף משתמשים בודדים או קבוצות כאדמינים ראשוניים.
    2. בשדה שם משתמש או כתובת אימייל חלופית של קבוצה, מזינים את כתובת האימייל של המשתמש או הקבוצה שרוצים לתת להם גישה לארגון. אם אתם האדמין, הזינו את כתובת האימייל שלכם, לדוגמה kiran@example.com. התחילית מתווספת לפני שם המשתמש, למשל myidp-kiran@example.com.
    3. לוחצים על הבא.
  7. בדף Review, בודקים את כל הערכים של כל הגדרת זהות לפני שממשיכים.

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

  8. לוחצים על הגדרה.

הפרופיל החדש של ספק הזהויות מופיע ברשימה "פרופילים של זהויות".

API

כדי לקשר את ספק הזהויות לארגון, יוצרים את המשאב הגלובלי המותאם אישית של IdentityProviderConfig.

  1. יוצרים קובץ YAML של משאב בהתאמה אישית של IdentityProviderConfig, למשל pa-idp-saml.yaml:

    apiVersion: iam.global.gdc.goog/v1
    kind: IdentityProviderConfig
    metadata:
      name: pa-idp-saml
      namespace: platform
    spec:
      saml:
        groupPrefix: IDP_GROUP_PREFIX
        groupsAttribute: IDP_GROUP_ATTRIBUTE
        idpCertificateDataList:
        - "IDP_BASE64_ENCODED_CERTIFICATE"
        idpEntityID: IDP_SAML_ENTITY_ID
        idpSingleSignOnURI: IDP_SAML_SSO_URI
        userAttribute: IDP_USER_ATTRIBUTE
        userPrefix: IDP_USER_PREFIX
    

    מחליפים את המשתנים הבאים:

    • ‫IDP_GROUP_PREFIX: הקידומת של הקבוצות ב-IdP.
    • ‫IDP_GROUP_ATTRIBUTE: המאפיין של הקבוצות ב-IdP.
    • ‫IDP_BASE64_ENCODED_CERTIFICATE: האישור בקידוד base64 ל-IdP.
    • ‫IDP_SAML_ENTITY_ID: כתובת ה-URL או ה-URI לזיהוי ייחודי של ה-IdP.
    • ‫IDP_SAML_SSO_URI: ה-URI של מנפיק ה-IdP.
    • ‫IDP_USER_ATTRIBUTE: המאפיין של המשתמש ב-IdP, כמו כתובת אימייל.
    • ‫IDP_USER_PREFIX: שם ההצהרה באסימון IdP של המשתמש.
  2. מחילים את המשאב המותאם אישית IdentityProviderConfig על שרת ה-API הגלובלי:

    kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f pa-idp-saml.yaml
    

    מחליפים את המשתנה GLOBAL_API_SERVER_KUBECONFIG בנתיב לקובץ kubeconfig של שרת ה-API הגלובלי.

מחיקה של ספק זהויות קיים

כדי למחוק ספק זהויות קיים באמצעות מסוף GDC:

  1. נכנסים למסוף GDC.
  2. בבורר הפרויקטים, בוחרים את הארגון שבו רוצים למחוק את ספק הזהויות.
  3. בתפריט הניווט, לוחצים על Identity and Access > Identity.
  4. מסמנים את התיבה שליד השם של ספק זהויות אחד או יותר.

    מופיעה הודעה עם מספר ספקי הזהויות שבחרתם ולחצן Delete.

  5. לוחצים על Delete.