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

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

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

חשבונות Looker (Google Cloud core) נוצרים בכניסה הראשונה למכונה של Looker (Google Cloud core).

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

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

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

מאפיין (property)	תפקיד אדמין ב-Looker	אדמין דרך תפקיד ב-IAM של Looker
מקור מהימן	ההרשאה ניתנה על ידי אדמין אחר במופע 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 וגם את תפקיד האדמין במופע 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)‎

בדף Google Authentication שבקטע Authentication בתפריט Admin במופע של Looker (Google Cloud core), אפשר להגדיר חלק מהגדרות Google OAuth. צריך להיות לכם תפקיד אדמין ב-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) משתמש בתביעת 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, צריך להנחות את המפתחים לבצע commit ולדחוף את כל השינויים מהענפים האישיים הישנים שלהם ולמזג את השינויים הנדרשים לענף הייצור לפני המעבר ל-OIDC. אחרי ההעברה, מפתחים יכולים לעבור לענפים האישיים החדשים שלהם ולמשוך את קוד הייצור העדכני.

קבוצות Google מקבילות

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

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

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

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

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

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

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

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

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

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

   הפעלת ה-API

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

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

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

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

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

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

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

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

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

כשאתם מבצעים שינויים בחברי הקבוצה ב-Google Groups, השינויים האלה מועברים באופן אוטומטי לחברי הקבוצה המקבילה ב-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. האפשרויות בקטע הזה קובעות את מידת הגמישות שיש לאדמינים ב-Looker כשהם מגדירים קבוצות ומשתמשים ב-Looker ששוכפלו מ-Google.

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

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

אם אתם רוצים יותר גמישות בהתאמה אישית של הקבוצות ב-Looker (Google Cloud core), אתם צריכים להשבית את האפשרויות האלה. הקבוצות שלכם ב-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 core).

• מניעת חברות ישירה בקבוצות שאינן של 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 core) מקבל מהשרת. צריך לוודא שהשרת מחזיר את התוצאות הנכונות.
• מעקב שמראה איך המידע נמצא. אם המידע שגוי, אפשר להשתמש במעקב כדי לפתור את הבעיה. אם אתם צריכים מידע נוסף, אתם יכולים לקרוא את קובץ ה-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 של משתמש, התפקיד מועבר למופע Looker (Google Cloud core) תוך כמה דקות. אם יש חשבון משתמש קיים ב-Looker, התפקיד של המשתמש הזה ב-Looker לא משתנה.

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

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

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

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

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

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

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

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

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

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

הגדרת OAuth כגיבוי ל-SAML או ל-OIDC

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

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

הגדרת OAuth כשיטה המשנית לאיחוד שירותי אימות הזהות של כוח העבודה

אפשר להגדיר את OAuth כשיטת האימות המשנית לאיחוד שירותי אימות הזהות של כוח העבודה. כדי להגדיר את OAuth כשיטת האימות המשנית, עורכים את המופע כדי להפעיל את ההגדרה Enable secondary OAuth (הפעלת OAuth משני).

כניסה לחשבון באמצעות OAuth

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

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