שימוש ב-Google OAuth לאימות משתמשים ב-Looker (Google Cloud Core)‎

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

משתמשים ב-OAuth של Google בשילוב עם ניהול זהויות והרשאות גישה (IAM) כדי לאמת משתמשים ב-Looker (הליבה של Google Cloud).

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

אם שיטה אחרת היא שיטת האימות העיקרית, אימות OAuth של Google הוא שיטת הגיבוי לאימות כברירת מחדל.

אימות והרשאה באמצעות OAuth ו-IAM

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

תפקיד IAM	אימות	הרשאה
משתמש במופע Looker (roles/looker.instanceUser)	אפשר להיכנס למופעים של Looker (Google Cloud Core)‎	בכניסה הראשונה ל-Looker (הליבה של Google Cloud), המשתמש מקבל את ברירת המחדל של התפקידים ב-Looker שמוגדרת בתפקידים למשתמשים חדשים. אין גישה למשאבים של Looker ‏ (שירות הליבה של Google Cloud) במסוף Google Cloud .
משתמשים עם הרשאת צפייה ב-Looker (roles/looker.viewer)	אפשר להיכנס למופעים של Looker (Google Cloud Core)‎	בכניסה הראשונה ל-Looker (הליבה של Google Cloud), המשתמש מקבל את ברירת המחדל של התפקידים ב-Looker שמוגדרת בתפקידים למשתמשים חדשים. יכולים לראות את רשימת המופעים של Looker (Google Cloud core) ואת פרטי המופעים ב Google Cloud מסוף
אדמין ב-Looker‏ (roles/looker.admin)	אפשר להיכנס למופעים של Looker (Google Cloud Core)‎	בכניסה הראשונה ל-Looker (הליבה של Google Cloud), המשתמש מקבל את ברירת המחדל של התפקידים ב-Looker שמוגדרת בתפקידים למשתמשים חדשים. בכל התחברות ל-Looker (Google Cloud core) שמשתמשת ב-OAuth ראשי או ב-OAuth לגיבוי, ובכל פעם שהמשתמש מבצע קריאה ל-Looker API, התפקיד הזה (או תפקיד מותאם אישית שכולל את ההרשאה looker.instances.update) מעניק גם את התפקיד Admin via IAM בתוך המופע. התפקיד Admin via IAM מכיל את כל ההרשאות והיכולות של התפקיד Admin ב-Looker. אי אפשר להסיר את התפקיד הזה או להקצות אותו מחדש במופע Looker (Google Cloud core). כדי להסיר את התפקיד אדמין דרך IAM, צריך להקצות מחדש את הסוכן לתפקיד IAM אחר מלבד אדמין Looker ‏ (roles/looker.admin). שינויים בתפקידי IAM מסונכרנים אוטומטית עם מופע Looker ‏ (Google Cloud core), גם אם המשתמש מתחבר באמצעות ספק זהויות של צד שלישי אחרי השינוי. מידע נוסף זמין בקטע תפקיד אדמין ב-Looker לעומת תפקיד אדמין ב-Looker באמצעות IAM. כל עוד טוקן הרענון של OAuth של המשתמש תקף, התפקיד של המשתמש מופיע כאדמין דרך IAM ב-Looker (Google Cloud core), גם אם המשתמש נכנס מאוחר יותר באמצעות ספק זהויות של צד שלישי. אם טוקן הרענון של OAuth פג או בוטל, המשתמש צריך להשתמש ב-OAuth כדי להיכנס שוב למופע ולקבל שוב את התפקיד Admin via IAM. יכולים לבצע את כל משימות האדמין ב-Looker (ליבת Google Cloud) במסוף Google Cloud

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

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

חשבונות Looker (Google Cloud Core)‎ נוצרים בזמן הכניסה הראשונה למופע Looker (Google Cloud Core)‎.

תפקיד אדמין ב-Looker לעומת תפקיד אדמין ב-Looker דרך IAM

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

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

מאפיין (property)	תפקיד אדמין ב-Looker	ניהול באמצעות תפקיד Looker ב-IAM
מקור מהימן	ההרשאה ניתנה על ידי אדמין אחר במופע Looker (Google Cloud Core)‎	מקושר ישירות לתפקיד האדמין ב-IAM של Looker
האם אפשר להוסיף או להסיר אותם במופע של Looker (Google Cloud core)?	כן	לא
אפשר להוסיף או להסיר אותם באמצעות IAM?	לא	כן
הרשאות ב-Looker (Google Cloud Core)‎	כל ההרשאות	כל ההרשאות
הרשאות במסוף Google Cloud	ללא	גישה מלאה לכל המשאבים של Looker (Google Cloud Core)‎
אימות התפקיד	באופן רציף במכונה של Looker (Google Cloud Core)‎	בכל התחברות למופע Looker (Google Cloud Core)‎ ובכל קריאה ל-Looker API. יכול להיות שיחלפו כמה דקות עד שהשינויים בתפקיד יתעדכנו ב-IAM.
היקף	מופע Looker (Google Cloud Core)‎ ספציפי	כל המכונות של Looker (Google Cloud Core)‎ ב Google Cloud פרויקט

משתמש יכול לקבל גם את התפקיד אדמין וגם את התפקיד אדמין דרך IAM ב-Looker. לכן, אם רוצים לבטל הרשאות אדמין, צריך להסיר גם את תפקיד ה-IAM וגם את התפקיד Admin במופע Looker (Google Cloud core).

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

הגדרת OAuth במופע Looker (Google Cloud Core)

במופע של Looker (Google Cloud core), אפשר להגדיר חלק מהגדרות Google OAuth בדף Google Authentication שבקטע Authentication בתפריט Admin. צריכה להיות לכם הרשאת אדמין ב-Looker.

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

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

אפשר למזג משתמשים מהמערכות הבאות:

• SAML
• OIDC

אם יש לכם יותר ממערכת אחת, אתם יכולים לציין בשדה הזה יותר ממערכת אחת למיזוג. ‫Looker (Google Cloud core) יחפש משתמשים במערכות שמופיעות ברשימה לפי הסדר שבו המערכות צוינו. לדוגמה, אם יצרתם משתמשים באמצעות OIDC ואחר כך השתמשתם ב-SAML, כשמשתמש ינסה להתחבר באמצעות OAuth בפעם הראשונה, מערכת Looker (Google Cloud core) תחפש את המשתמש קודם באמצעות OIDC, ואם לא יימצא משתמש תואם באמצעות OIDC, היא תחפש את המשתמש באמצעות SAML.

אם לא רוצים ש-Looker (Google Cloud core) ימזג משתמשים, משאירים את השדה הזה ריק.

מעבר בין ספקי זהויות מסוג OIDC

כשמבצעים מיגרציה מספק זהויות אחד של OIDC לספק אחר (לדוגמה, כשעוברים מ-PingFederate ל-Okta), אי אפשר להשתמש באפשרות למיזוג חשבונות משתמשים שמתוארת במאמר מיזוג חשבונות משתמשים. המיזוג מתבצע רק כשעוברים בין סוגי אימות שונים (למשל מ-SAML ל-OIDC).

‫Looker (Google Cloud core) משתמש בטענה sub ממטען ה-OIDC כדי לאכלס את מאפיין המשתמש oidc_user_id, שמזהה באופן ייחודי חשבונות משתמשים ב-OIDC. כדי למנוע מ-Looker (Google Cloud core) ליצור חשבונות משתמשים כפולים במהלך העברה של OIDC, צריך להגדיר את ספק הזהויות החדש של OIDC כך שהתביעה sub שנשלחת במטען הייעודי (payload) של OIDC תתאים ל-oidc_user_id שנקבע על ידי הספק הקודם (לדוגמה, התביעה sub צריכה להכיל את כתובת האימייל של המשתמש במקום UUID שנוצר לאחרונה).

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

אזהרה: כשהטענה sub משתנה במהלך העברה של OIDC, ‏ Looker (Google Cloud core) יוצר זהות משתמש חדשה וגוזר שם חדש של ענף פיתוח אישי ב-Git מהמזהה הפנימי החדש של המשתמש. השינוי הזה עלול לגרום למפתחים לאבד שינויי LookML שלא בוצעו לגביהם פעולות Commit, שמאוחסנים בהסתעפויות האישיות המקוריות שלהם. אם אי אפשר לשמור על טענות זהות של sub, צריך להנחות את המפתחים לבצע קומיט ולדחוף את כל השינויים מהענפים האישיים הישנים שלהם ולמזג את השינויים הנדרשים לענף הייצור לפני המעבר ל-OIDC. אחרי ההעברה, מפתחים יכולים לעבור לענפים האישיים החדשים שלהם ולמשוך את קוד הייצור העדכני.

שיקוף של קבוצות Google

הערה: אין תמיכה בשיקוף קבוצות ב-OAuth של Google במופעים של Looker ‏ (Google Cloud Core) שמופעל בהם מצב תאימות ל-FIPS.

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

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

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

התפקיד אדמין דרך IAM ב-Looker, שמוענק באופן אוטומטי למשתמשים שיש להם את התפקיד אדמין ב-Looker במערכת IAM, מבטל את שיקוף הקבוצות. למשתמשים עם התפקיד Looker Admin במערכת IAM מוקצה באופן אוטומטי התפקיד Admin via IAM ב-Looker (Google Cloud core), ללא קשר לחברות שלהם בקבוצות. בנוסף, המשתמשים האלה יוקצו לקבוצות משוכפלות ויקבלו תפקידים וגישה באמצעות תהליך השכפול הרגיל.

מומלץ להפעיל שיקוף קבוצות רק עבור שיטת האימות הראשית של Looker (ליבת Google Cloud). אם אתם משתמשים ב-OAuth כשיטת אימות הגיבוי, אל תפעילו שיקוף קבוצות ל-OAuth. אם מפעילים שיקוף קבוצות גם לשיטת האימות הראשית וגם לשיטת האימות המשנית, יתרחשו הפעולות הבאות:

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

שלבים להפעלת קבוצות משוכפלות

כדי להפעיל את שיקוף הקבוצה:

1. במסוף Google Cloud , מפעילים את Cloud Identity API ב Google Cloud פרויקט שמכיל את לקוח OAuth. כדי להפעיל ממשקי API, צריך להיות לכם תפקיד ה-IAM‏ Service Usage Admin (roles/serviceusage.serviceUsageAdmin).

   הפעלת ה-API

2. במסוף Google Cloud , מעדכנים את מסך ההסכמה של לקוח OAuth כדי להוסיף את היקף ההרשאות https://www.googleapis.com/auth/cloud-identity.groups.readonly. כדי להוסיף היקפי הרשאות, צריך לקבל את הרשאת ה-IAM‏ clientauthconfig.clients.update. כדי לעדכן את מסך בקשת ההסכמה:

   • עוברים אל לקוח OAuth.
   • בוחרים בדף גישה לנתונים.
   • לוחצים על הלחצן הוספה או הסרה של היקפים. תיפתח החלונית Update selected scopes (עדכון ההיקפים שנבחרו).
   • מחפשים את ההיקף https://www.googleapis.com/auth/cloud-identity.groups.readonly ומסמנים את תיבת הסימון שלצידו.
   • לוחצים על הלחצן עדכון כדי להוסיף את ההיקף.

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

     זהירות: אם השדה סוג המשתמש בלקוח OAuth מוגדר כחיצוני, צריך להשלים אימות של היקף הרשאות מוגבל לאפליקציית OAuth. עד שאפליקציית OAuth תאומת על ידי Google, המשתמשים יוכלו להיכנס, אבל תוצג להם הודעת אזהרה במהלך תהליך הכניסה. הסיבה לכך היא ש-Cloud Identity API הוא היקף רגיש.

3. במופע Looker (Google Cloud core), מעבירים את המתג Mirror Google Groups למצב מופעל בדף Google Authentication. המתג הזה מושבת כברירת מחדל. ממלאים את השדות הבאים:

   • בשדה Looker Group Name (שם קבוצת Looker), מוסיפים שם לקבוצת Looker. זה השם שיופיע בדף Groups ב-Looker (Google Cloud core).
   • בשדה Google Group ID (מזהה קבוצת Google), מזינים את השם או כתובת האימייל של קבוצת Google שרוצים לשקף.
   • בשדה תפקיד, מזינים את התפקיד או התפקידים ב-Looker שרוצים להקצות לחברים בקבוצה.

‫Looker (Google Cloud core) ייצור קבוצת Looker אחת לכל קבוצת Google שנוספה לדף Google Authentication. אפשר לראות את קבוצות Looker האלה בדף Groups של Looker (Google Cloud Core).

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

עריכה של קבוצות משוכפלות

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

אם עורכים את השדות Custom name או Role שמוקצים לקבוצה בדף Google Authentication, משתנה האופן שבו השם של קבוצת Looker המשוכפלת מופיע בדף Groups ב-Looker (Google Cloud core) או התפקידים שמוקצים לקבוצה, אבל חברי הקבוצה לא משתנים.

אם משנים את השם או האימייל בשדה Google Group ID בדף Google Authentication למזהה של קבוצת Google חדשה, חברי קבוצת Looker המשוכפלת ישתנו לחברים בקבוצת Google החדשה, אבל השם והתפקידים של הקבוצה יישארו כפי שהוגדרו בדף Google Authentication.

כל שינוי שמתבצע בקבוצה משוכפלת יחול על המשתמשים בקבוצה הזו בפעם הבאה שהם ייכנסו ל-Looker (Google Cloud core).

השבתה של קבוצות משוכפלות

כדי להפסיק את השכפול של קבוצות Google ב-Looker (Google Cloud Core), משביתים את המתג Mirror Google Groups בדף Google Authentication במופע Looker (Google Cloud Core). השבתת המתג גורמת להתנהגות הבאה:

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

ניהול מתקדם של תפקידים

אם המתג Mirror Google Groups (שיקוף קבוצות Google) מופעל, ההגדרות של Advanced Role Management (ניהול תפקידים מתקדם) מוצגות בדף Google Authentication (אימות Google). האפשרויות בקטע הזה קובעות את מידת הגמישות של מנהלי Looker בהגדרת קבוצות ומשתמשים ב-Looker שמשוכפלים מ-Google.

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

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

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

במופע Looker ‏ (שירות הליבה של Google Cloud), האפשרויות האלה מושבתות כברירת מחדל.

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

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

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

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

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

  אם האפשרות הזו נבחרה, כל משתמשי Google שהוקצו בעבר לקבוצות מובנות של Looker יוסרו מהקבוצות האלה בפעם הבאה שהם יתחברו.

  אם האפשרות הזו לא מסומנת, אדמינים ב-Looker יכולים להוסיף משתמשי Google ישירות לקבוצות מובנות ב-Looker.

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

  אם האפשרות הזו מושבתת, קבוצות משתמשים משוכפלות או משתמשי Google שנוספים כחברים בקבוצה מובנית ב-Looker יקבלו בירושה את התפקידים שהוקצו לקבוצה המובנית ב-Looker.

• ‫Auth Requires Role: אם האפשרות הזו מופעלת, משתמשי Google נדרשים לקבל הקצאה של תפקיד ב-Looker. משתמשי Google שלא הוקצה להם תפקיד לא יוכלו להיכנס ל-Looker (Google Cloud core).

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

הגדרת תפקיד ברירת מחדל ב-Looker

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

אם המתג Mirror Google Groups (שיקוף קבוצות Google) מושבת, ההגדרה Roles for new users (תפקידים למשתמשים חדשים) מופיעה בדף Google Authentication (אימות Google). ההגדרה הזו מאפשרת לכם להגדיר את תפקיד ברירת המחדל ב-Looker שיוקצה לחשבונות משתמשים עם תפקיד IAM של משתמש במופע Looker ‏ (roles/looker.instanceUser) או עם תפקיד IAM של צופה ב-Looker ‏ (roles/looker.viewer) בכניסה הראשונה שלהם למופע Looker (ליבת Google Cloud). כדי להגדיר תפקיד ברירת מחדל, פועלים לפי השלבים הבאים:

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

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

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

בדיקת אימות משתמש

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

• האם Looker (הליבה של Google Cloud) הצליח לתקשר עם השרת ולאמת אותו.
• פרטי המשתמש ש-Looker (ליבת Google Cloud) מקבל מהשרת. צריך לוודא שהשרת מחזיר את התוצאות הנכונות.
• עקבות שמראים איך המידע נמצא. אם המידע שגוי, אפשר להשתמש בנתוני המעקב כדי לפתור את הבעיה. אם אתם צריכים מידע נוסף, אתם יכולים לקרוא את קובץ השרת בפורמט XML.
• גרסאות מפוענחות וגולמיות של טוקן של מזהה שהתקבל. אפשר להשתמש בהם כדי לאשר את פרטי המשתמש וגם את ההגדרה של Google.

שמירת ההגדרות והחלתן

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

הוספת משתמשים למופע של Looker (Google Cloud Core)‎

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

אחרי יצירת מופע של Looker (Google Cloud core), אפשר להוסיף משתמשים דרך IAM. כדי להוסיף משתמשים:

1. צריך לוודא שיש לכם את התפקיד אדמין IAM בפרויקט או תפקיד אחר שמאפשר לכם לנהל את הגישה ב-IAM.

2. עוברים אל Google Cloud פרויקט המסוף שבו נמצאת מכונת Looker (Google Cloud core).

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

3. עוברים לקטע IAM & Admin > IAM במסוף Google Cloud .

4. לוחצים על הענקת גישה.

5. בקטע Add principals, מוסיפים אחד או יותר מהפריטים הבאים:

   • כתובת האימייל בחשבון Google
   • קבוצה ב-Google
   • דומיין ב-Google Workspace

6. בקטע Assign roles (הקצאת תפקידים), בוחרים אחד מתפקידי ה-IAM המוגדרים מראש של Looker (Google Cloud core) או תפקיד בהתאמה אישית שהוספתם.

7. לוחצים על Save.

8. להודיע למשתמשים חדשים ב-Looker (Google Cloud core) שניתנה להם גישה, ולשלוח אותם לכתובת ה-URL של המופע. משם הם יכולים להיכנס למופע, ובשלב הזה החשבונות שלהם ייווצרו. לא יישלחו הודעות אוטומטיות.

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

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

כניסה ל-Looker (Google Cloud Core)‎ באמצעות OAuth

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

אחרי כן, המשתמשים יתחברו אוטומטית ל-Looker (ליבת Google Cloud), אלא אם ההרשאה שלהם תפוג או תבוטל על ידי המשתמש. בתרחישים האלה, המשתמשים יראו שוב את מסך ההסכמה ל-OAuth ויתבקשו להביע הסכמה להרשאה.

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

הסרת גישת OAuth ל-Looker (Google Cloud Core)‎

חשוב: מומלץ להסיר את הגישה למופע של Looker (Google Cloud core) באמצעות IAM ולא מתוך המופע.

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

שימוש ב-OAuth כשיטת אימות גיבוי

‫OAuth היא שיטת האימות לגיבוי כש-SAML או OIDC הן שיטות האימות העיקריות.

כדי להגדיר OAuth כשיטת הגיבוי, צריך להעניק לכל משתמש ב-Looker (ליבת Google Cloud) את תפקיד ה-IAM המתאים כדי להיכנס למופע.

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

1. בדף הכניסה, לוחצים על אימות באמצעות Google.
2. מופיעה תיבת דו-שיח לאישור האימות של Google. לוחצים על אישור בתיבת הדו-שיח.

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

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

• קישור Looker (Google Cloud Core)‎ למסד הנתונים
• הגדרת מופע של Looker (Google Cloud Core)‎
• הגדרות אדמין ב-Looker (Google Cloud Core)‎
• ניהול מופע של Looker (Google Cloud Core)‎ ממסוף Google Cloud