איך משתמשים באיחוד שירותי אימות הזהות של כוח עבודה כדי לאמת משתמשים ב-Looker (Google Cloud core)

תצוגה מקדימה

השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות, ולתנאים הנוספים למוצרים בגרסת טרום-GA של AI גנרטיבי. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

הערה: כדי לשלוח משוב או לדווח על בעיות בתכונה הזו בגרסת טרום-השקה (Preview), שלחו אימייל מפורט לכתובת [e-mail].

איחוד שירותי אימות הזהות של כוח עבודה מאפשר להשתמש בספק זהויות (IdP) חיצוני כדי לאמת משתמשים וקבוצות של משתמשים במכונה של Looker (Google Cloud core). באמצעות איחוד שירותי אימות הזהות של כוח העבודה, המשתמשים בארגון יכולים להשתמש בכניסה יחידה (SSO) כדי לגשת ל-Looker (Google Cloud core) בלי שתצטרכו להקצות או לסנכרן חשבונות Google (חשבונות Cloud Identity או Google Workspace) לכל משתמש.

איחוד שירותי אימות הזהות של כוח עבודה תומך בספקי זהויות חיצוניים שמשתמשים ב-OpenID Connect (OIDC) או ב-SAML 2.0, כמו Microsoft Entra ID (לשעבר Azure AD),‏ Okta,‏ PingIdentity ואחרים.

במהלך התצוגה המקדימה של התכונה, נתמכות רק מכונות Looker (Google Cloud core) שמשתמשות בחיבורים ציבוריים מאובטחים.

איך איחוד שירותי אימות הזהות של כוח העבודה פועל עם Looker (Google Cloud core)

כשמגדירים איחוד שירותי אימות הזהות של כוח העבודה במכונה של Looker (ליבה של Google Cloud), מתרחש התהליך הבא:

1. אימות: המשתמש נכנס לכתובת ה-URL של המכונה של Looker (Google Cloud core). אם ההגדרה עקיפת דף ההתחברות מופעלת, המשתמש מופנה אוטומטית ל Google Cloud פורטל הכניסהhttps://auth.cloud.google/authorize, שמפנה את המשתמש ל-IdP החיצוני שלכם לצורך אימות.
2. החלפת אסימונים: אחרי שהמשתמש מאמת את הזהות שלו באמצעות ה-IdP, ה-IdP מחזיר טענת נכוֹנוּת (assertion) של אימות ל- Google Cloud Security Token Service ‏(STS). שירות STS ממיר את ההצהרה באסימון גישה ובאסימון מזהה של איחוד שירותי האימות.
3. הרשאה: המערכת של Looker (Google Cloud core) מאמתת שלחשבון המשתמש המאומת יש את ההרשאה הנדרשת לניהול זהויות והרשאות גישה (IAM) (looker.instances.login) במכונה.
4. הקצאת הרשאות ותפקידים:‏ Looker (Google Cloud core) יוצר את חשבון המשתמש בכניסה הראשונה (הקצאת הרשאות בזמן אמת בלבד (JIT)), ומחיל מיפויים של קבוצות לתפקידים ומאפייני משתמש שמבוססים על ההצהרות שהוא מקבל מספק הזהויות.

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

לפני שמגדירים את איחוד שירותי אימות הזהות של כוח עבודה ב-Looker (Google Cloud core), צריך לוודא שיש לכם את התפקידים וההגדרות הבאים:

התפקידים שצריך ב-IAM

כדי להגדיר את איחוד שירותי אימות הזהות של כוח העבודה וליצור מכונות של Looker (Google Cloud core), אתם צריכים את התפקידים הבאים:

• אדמין של מאגר כוח עבודה ב-IAM (roles/iam.workforcePoolAdmin): נדרש בארגון Google Cloud כדי ליצור ולנהל מאגרים וספקים של כוח עבודה.
• ‫Looker Admin (roles/looker.admin): נדרש בפרויקט Google Cloudכדי ליצור ולנהל מופעים של Looker (Google Cloud core).
• ‫אדמין IAM בפרויקט (roles/resourcemanager.projectIamAdmin): נדרש בפרויקט Google Cloud כדי להקצות תפקידי IAM לחשבונות המשתמשים בכוח העבודה.

ממשקי API נדרשים

מפעילים את ממשקי ה-API הבאים בפרויקט ב- Google Cloud :

• ‫Identity and Access Management API ‏ (iam.googleapis.com)

  הפעלת ה-API של ניהול הזהויות והרשאות הגישה

• ‫Security Token Service API‏ (sts.googleapis.com)

  הפעלת Security Token Service API

• ‫Cloud Resource Manager API‏ (cloudresourcemanager.googleapis.com)

  הפעלת Cloud Resource Manager API

• ‫Looker (Google Cloud Core) API‏ (looker.googleapis.com)

  הפעלת Looker (Google Cloud core) API

הערה: במהלך גרסת טרום ההשקה של התכונה, השילוב בין Looker (Google Cloud core) לבין איחוד שירותי אימות הזהות של כוח העבודה נתמך רק במכונות Looker (Google Cloud core) שמשתמשות בחיבורים מאובטחים ציבוריים.

שלב 1: הגדרת ספק ומאגר זהויות של כוח עבודה

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

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

1. יוצרים מאגר זהויות של כוח עבודה לפי ההוראות בדף התיעוד הגדרת איחוד שירותי אימות הזהות של כוח עבודה.
2. יוצרים ספק של מאגר זהויות של כוח עבודה בשביל ה-IdP של OIDC או SAML 2.0:
   • לספקי OIDC, קראו את המאמר הגדרת איחוד שירותי אימות הזהות של כוח עבודה ב-OIDC.
   • לספקי SAML, אפשר לעיין במאמר הגדרת איחוד שירותי אימות הזהות של כוח עבודה ב-SAML 2.0.
   • מגדירים את מיפויי המאפיינים הבאים מיד במהלך יצירת הספק:
     • אימייל: ממפים את תביעת האימייל של ה-IdP ל-google.email. המיפוי הזה נדרש לזיהוי משתמשים. אם המיפוי הזה חסר, האימות ייכשל.
     • שם פרטי ושם משפחה: ממפים את הטענות של ספק הזהויות לגבי השם הפרטי ושם המשפחה אל attribute.given_name (שם פרטי) ו-attribute.family_name (שם משפחה). המיפויים האלה נדרשים כדי לאכלס את פרופילי המשתמשים ב-Looker. אם המיפויים האלה חסרים, האימות ייכשל.

3. אפשר גם להגדיר את מיפויי המאפיינים הבאים:

   • קבוצות: ממפים את בקשת קבוצות המשתמשים של ספק הזהויות (לדוגמה, assertion.groups) ל-google.groups. המיפוי הזה נדרש אם אתם מתכננים להפעיל שיקוף קבוצות ולמפות קבוצות של ספק זהות לתפקידים ב-Looker. בספקי OIDC, מוודאים שהגדרת הספק מבקשת גם את ההיקף groups אם ה-IdP דורש זאת (ראו הגדרה של איחוד שירותי אימות הזהויות של כוח עבודה לדרישות ספציפיות ל-IdP).
   • מאפיינים מותאמים אישית: מיפוי טענות מותאמות אישית של IdP ל-attribute.<attribute_name>. אפשר להשתמש במאפיינים הממופים האלה ב-Looker (Google Cloud core) כדי להגדיר פרמטרים לחיבורי מסד נתונים ולהחיל מסננים של גישה לנתונים ברמת השורה.
   הערה: כדי להבטיח תהליך הגדרה פשוט ולא תצטרכו לערוך מחדש את הגדרות הספק בהמשך, מומלץ להגדיר מיפויי מאפיינים מיד במהלך יצירת הספק.

הגדרת משך סשן ארוך יותר וסנכרון ברקע

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

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

1. כדי ש- Google Cloud יוכל לרענן מדי פעם את מאפייני המשתמשים ואת החברות בקבוצות ברקע, צריך להגדיר סנכרון מאפיינים ברקע אצל הספק של מאגר הזהויות של כוח העבודה:
   • לספקי OIDC: מגדירים את תהליך ההרשאה באמצעות קוד של OIDC עם ההיקף offline_access (שמשתמש בטוקני רענון כדי לרענן מדי פעם את מאפייני המשתמשים ואת החברות בקבוצות) או הקצאת הרשאות ידנית של SCIM 2.0. אם המשתמשים שייכים למספר גדול של קבוצות שחורג ממגבלות הגודל של אסימון OIDC, צריך להגדיר הקצאת הרשאות ידנית ב-SCIM 2.0 כדי לסנכרן את החברות בקבוצות עם Google Cloud.
   • לספקי SAML: מגדירים הקצאת הרשאות ידנית ב-SCIM 2.0 בספק של מאגר הזהויות של כוח העבודה. מכיוון שטענות נכוֹנוּת ב-SAML לא מספקות באופן מובנה טוקנים לרענון, נדרש SCIM 2.0 כדי להפעיל מסירות והתראות מתוזמנות במצב אופליין.

2. מגדירים מדיניות של אורך סשן מורחב למאגר כוח העבודה באמצעות קשירות של Access Context Manager ל-Cloud, ומגדירים את המדיניות ל-90 ימים (7,776,000 שניות).

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

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

כדי לאפשר למשתמשים בכוח העבודה להיכנס למכונה של Looker (Google Cloud core), צריך לתת לחשבונות הראשיים או לקבוצות של כוח העבודה את התפקיד "משתמש במכונה של Looker"‏ (roles/looker.instanceUser) או "אדמין ב-Looker"‏ (roles/looker.admin) ב-IAM.

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

• משתמש יחיד בכוח העבודה:

  principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_ID
  

• קבוצת כוח עבודה:

  principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID
  

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

  principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/*
  

מידע נוסף על הקצאת תפקידים ב-IAM זמין בדף התיעוד בקרת גישה באמצעות IAM ב-Looker (Google Cloud core).

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

אתם יכולים לבחור ב-Workforce Identity Federation כשיטת האימות העיקרית כשאתם יוצרים מופע חדש של Looker (Google Cloud core) או כשאתם עורכים מופע קיים.

במהלך יצירת המכונה

כשיוצרים מכונה חדשה של Looker (Google Cloud core), אפשר לבחור באיחוד שירותי אימות הזהות של כוח עבודה כשיטת האימות הראשית:

console

1. במסוף Google Cloud, עוברים לדף Looker (Google Cloud core).

   אל Looker (Google Cloud core)

2. לוחצים על CREATE INSTANCE.
3. מגדירים את שם המכונה, האזור והמהדורה, כמו שמתואר במסמכי העזרה ליצירת מכונות שמשתמשות בחיבורים מאובטחים ציבוריים, בחיבורים של Private Service Connect או בחיבורים של גישה לשירותים פרטיים.
4. בקטע Authentication, בוחרים באפשרות Workforce Identity Federation (SAML/OIDC) כשיטת האימות הראשית.
5. לוחצים על יצירה.

כדי להגדיר את OAuth כשיטת אימות משנית, צריך לערוך את הגדרות המכונה אחרי שהיא נוצרת.

כשעורכים מופע קיים

אם יש לכם מכונה קיימת של Looker (Google Cloud core), אתם יכולים לערוך את ההגדרות שלה כדי לבחור באיחוד שירותי אימות הזהות של כוח העבודה כשיטת האימות הראשית, או להגדיר את OAuth כשיטת האימות המשנית:

console

1. נכנסים לדף Looker (Google Cloud core) במסוף Google Cloud.

   אל Looker (Google Cloud core)

2. לוחצים על שם המופע שרוצים לערוך.
3. בכרטיסייה Details של המכונה, לוחצים על Edit.
4. בקטע Authentication, בוחרים באפשרות Workforce Identity Federation (SAML/OIDC)‎ בתור שיטת האימות הראשית.
5. (אופציונלי) כדי לאפשר OAuth כשיטת אימות משנית, מפעילים את המתג Enable Secondary OAuth.
6. לוחצים על Save.

שלב 4: הגדרת שירותי אימות הזהות של כוח העבודה ב-Looker

אחרי שיוצרים את המכונה של Looker (Google Cloud core), אדמין יכול להגדיר מיפויים של מאפייני משתמשים, שיקוף קבוצות ואפשרויות התחברות בדף Workforce authentication בחלונית הניהול של Looker.

1. נכנסים למכונה של Looker (Google Cloud core) באמצעות חשבון עם תפקיד אדמין ב-Looker.
2. בתפריט הניווט הימני, בוחרים באפשרות אדמין > אימות > זהויות של עובדים.
3. קובעים את ההגדרות שמתוארות בקטעים הבאים.

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

מיזוג חשבונות משתמשים

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

המערכות הנתמכות למיזוג כוללות את:

• Google
• SAML
• OIDC

מעקף של דף ההתחברות

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

• מופעל (ברירת מחדל): כשמשתמשים עוברים לכתובת ה-URL של המופע, הם מופנים אוטומטית למסך הכניסה של ספק הזהויות (IdP) בלי לראות את דף הכניסה של Looker.
• מושבת: המשתמשים רואים את דף הכניסה ל-Looker ויכולים לבחור בין אפשרויות האימות הזמינות.

לוחצים על שמירת ההגדרה כדי להחיל את ההגדרות.

מיפוי מאפיינים של משתמשים

ממפים הצהרות מטענת הנכוֹנוּת (assertion) של ספק ה-IdP למאפייני משתמש ב-Looker. אפשר להשתמש במאפייני משתמשים למטרות רבות, כמו הגדרת פרמטרים של חיבורים למסדי נתונים והחלת מסנני אבטחה ברמת השורה.

• בקטע Attribute Mapping (מיפוי מאפיינים), ממפים את המאפיינים של משתמשי Google לעבודה למאפייני משתמשים תואמים ב-Looker (לדוגמה, מיפוי של attribute.department למאפיין משתמש department ב-Looker).

קבוצות ותפקידים

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

• קבוצות שיקוף מ-IdP: כשההגדרה הזו מופעלת, Looker (Google Cloud core) יוצר קבוצות Looker שמשקפות קבוצות שמועברות בטענת הנכוֹנוּת (assertion) של אסימון ה-IdP.
  • בטבלה Group Mapping (מיפוי קבוצות), ממפים את שמות הקבוצות של ספק הזהויות החיצוני לקבוצות ב-Looker ומקצים תפקידים מתאימים ב-Looker (כמו Viewer,‏ User או Developer).
• תפקיד ברירת המחדל למשתמשים חדשים: אם לא משתמשים בשיקוף קבוצות או אם אין התאמה למשתמש, צריך לציין את תפקיד ברירת המחדל שיוקצה למשתמשים חדשים בכניסה הראשונה.
• קבוצת משתמשים חדשים שמוגדרת כברירת מחדל: אם לא משתמשים בשיקוף קבוצות או אם אין התאמה בין המשתמש לקבוצה, צריך לציין את קבוצת ברירת המחדל שתוקצה למשתמשים חדשים.

ניהול סשנים ותוקף הטוקן

הסשנים והאסימונים של המשתמשים ב-Looker (Google Cloud core) כפופים למשך הסשן ולתוקף של אסימון הרענון שמוגדרים במדיניות של מאגר הזהויות של כוח העבודה (למשל, מדיניות של משך סשן מורחב):

• סשנים בדפדפן: הגדרות משך הסשן ב-Looker תומכות בסשנים של עד 30 ימים כשמשתמשים בסשנים מתמשכים. עם זאת, אם תוקף אסימון הרענון של מאגר הזהויות של כוח העבודה קצר יותר ממשך הסשן שהוגדר ב-Looker, הוא מקבל קדימות. כשתוקף אסימון הרענון פג, המשתמש צריך להיכנס שוב לחשבון. מומלץ להגדיר מדיניות של 90 יום לתוקף של טוקן רענון, במסגרת המדיניות שלכם לגבי משך הזמן של הפעלת סשן מורחב.
• התראות ומסירות מתוזמנות (משימות אופליין): משימות ברקע פועלות כל עוד לבעלים של התזמון יש אסימון פעיל של ספק הזהויות. אם מי שיצר את לוח הזמנים או ההתראה לא נכנס למכונה במשך יותר מ-90 יום (או למשך הזמן שהוגדר במדיניות הסשן של מאגר כוח העבודה), הסשן שלו אופליין מסתיים, וההתראות או המסירות המתוזמנות שבבעלות המשתמש הזה מושהות. כדי להמשיך להפעיל פרומפטים מתוזמנים או התראות שהושהו, הבעלים צריך להיכנס למופע, או שאדמין צריך להקצות בעלות על הפרומפט המתוזמן.
• שרת Looker OAuth ומחברים: שילובים שמשתמשים בשרת Looker OAuth (כמו Data Studio, גיליונות מקושרים ומחברים של צד שלישי) משתמשים באסימון רענון של 30 יום (או באסימון רענון שלא פג תוקפו ב-Data Studio). אם משך הסשן של מאגר כוח העבודה מוגדר לפחות מ-90 יום, יכול להיות שהמשתמשים יצטרכו לאמת מחדש את הזהות שלהם ב-Looker כשתוקף הסשן יפוג.
• מפתחות API של משתמשים: טוקני גישה ל-API שנוצרים על ידי מפתחות API של משתמשים תקפים למשך שעה אחת, ודורשים סשן IdP פעיל של המשתמש. אם הסשן של המשתמש ב-IdP פג (כל 90 יום או בהתאם למשך הסשן במאגר של כוח העבודה), המשתמש צריך להיכנס שוב למכונה כדי להמשיך להשתמש במפתחות ה-API שלו.
• מפתחות API של חשבונות שירות: כללי מדיניות הסשנים של מאגר כוח העבודה לא משפיעים על אסימוני הגישה ל-API של חשבונות שירות.

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

• ניהול משתמשים ב-Looker (Google Cloud core)
• בקרת גישה ל-Looker (Google Cloud core) באמצעות IAM
• ניהול מדיניות תחזוקה למופע של Looker (Google Cloud Core)