כל שירותי Google, כולל Google Cloud, Google Marketing Platform ו-Google Ads, מסתמכים על כניסה באמצעות חשבון Google כדי לאמת משתמשים. במאמר הזה מוסבר מודל הדומיין שעליו מתבססת כניסה באמצעות חשבון Google לצורך אימות וניהול זהויות. מודל הדומיין עוזר להבין איך הכניסה באמצעות חשבון Google פועלת בהקשר ארגוני, איך הזהויות מנוהלות ואיך אפשר לשלב ספק זהויות (IdP) חיצוני. בתרשים הבא מוצגת האינטראקציה בין הישויות האלה.
כפי שמוצג בתרשים, במרכז המודל נמצאת זהות Google, שמשמשת לכניסה באמצעות חשבון Google. Google Identity קשורה לכמה ישויות אחרות שכולן רלוונטיות בהקשר של ניהול זהויות:
- Google לצרכנים מכילה את הישויות שרלוונטיות לשימוש בשירותי Google שמתמקדים בצרכנים, כמו Gmail.
- Google לארגונים מכיל ישויות שמנוהלות על ידי Cloud Identity או Google Workspace. הישויות האלה הן הרלוונטיות ביותר לניהול זהויות ארגוניות.
- Google Cloud מכיל את הישויות הספציפיות ל-Google Cloud.
- חיצוני מכיל ישויות שרלוונטיות אם משלבים את Google עם IdP חיצוני.
החצים המלאים בתרשים מציינים שישויות מפנות זו לזו או מכילות זו את זו. לעומת זאת, חצים מקווקווים מציינים קשר של איחוד.
זהויות ב-Google
זהויות, משתמשים וחשבונות משתמשים ממלאים תפקיד חיוני בניהול הזהויות. שלושת המונחים קשורים זה לזה באופן הדוק, ולפעמים אפילו משתמשים בהם לסירוגין. עם זאת, בהקשר של ניהול זהויות, כדאי להבחין בין המושגים:
זהות היא שם שמזהה באופן ייחודי את האדם שמקיים אינטראקציה עם שירות של Google. Google משתמשת בכתובות אימייל למטרה הזו. כתובת האימייל של המשתמש נחשבת לזהות שלו ב-Google.
תהליך האימות של השיוך בין אדם לזהות נקרא אימות או כניסה, והוא מאפשר לאדם להוכיח שזו אכן הזהות שלו.
יכול להיות שלאדם מסוים יש כמה כתובות אימייל. מכיוון שבשירותי Google כתובת האימייל משמשת כמזהה, לאדם כזה יהיו כמה מזהים.
חשבון משתמש הוא מבנה נתונים שמתעד מאפיינים, פעילויות והגדרות שצריך להחיל בכל פעם שזהות מסוימת מקיימת אינטראקציה עם שירות של Google. חשבונות משתמשים לא נוצרים באופן דינמי, אלא צריך להקצות אותם לפני הכניסה הראשונה.
חשבונות המשתמשים מזוהים באמצעות מזהה שלא נחשף באופן חיצוני. לכן, בממשקי משתמש או בממשקי API צריך להפנות לחשבון המשתמש באופן עקיף באמצעות הזהות שמשויכת אליו, כמו
alice@gmail.com. למרות העקיפה הזו, כל הנתונים ופרטי ההגדרות משויכים לחשבון המשתמש, ולא לזהות.
ברוב המקרים, יש קשר של אחד לאחד בין חשבונות משתמשים לבין זהויות, ולכן קל לבלבל ביניהם. עם זאת, זה לא תמיד המצב, כפי שממחישים מקרי הקצה הבאים:
הקשר בין חשבונות משתמשים לבין זהויות הוא לא קבוע. אתם יכולים לשנות את כתובת האימייל הראשית של חשבון משתמש, וכך לשייך למשתמש זהות אחרת.
אדמינים ב-Cloud Identity או ב-Google Workspace יכולים אפילו להחליף בין כתובות האימייל הראשיות של שני משתמשים. לדוגמה, אם החלפתם את כתובות האימייל הראשיות של אליס (
alice@example.com) ובוב (bob@example.com), אליס תשתמש בחשבון המשתמש הקודם של בוב ובוב ישתמש בחשבון המשתמש הקודם של אליס. מכיוון שהנתונים וההגדרות משויכים לחשבון המשתמש ולא לזהות, אליס תשתמש עכשיו גם בהגדרות ובנתונים הקיימים של בוב (ובוב ישתמש עכשיו בהגדרות ובנתונים של אליס). באיור הבא מוצג הקשר הזה.
בהגדרה לא מאוחדת, צריך גם לאפס את הסיסמאות כדי שדנה ודני יוכלו להחליף בין חשבונות המשתמשים. בהגדרה מאוחדת שבה אליס ובוב משתמשים ב-IdP חיצוני לאימות, אין צורך לאפס את הסיסמאות.
היחס בין הזהות למשתמשים לא תמיד יהיה 1:1. חשבון פרטי יכול להיות משויך לכמה זהויות, כמו בתרשים הבא.
יכול להיות גם שזהות אחת מתייחסת לשני חשבונות משתמשים שונים. מומלץ להימנע מהמצב הזה, אבל הוא יכול לקרות במקרה של חשבון משתמש עם פרטים זהים. במקרה כזה, למשתמש מוצג מסך בחירה במהלך האימות, שבו הוא בוחר את חשבון המשתמש שבו הוא רוצה להשתמש.
Google מבדילה בין שני סוגים של חשבונות משתמשים: חשבונות משתמשים פרטיים וחשבונות משתמשים מנוהלים. בקטעים הבאים נתאר בפירוט את שני סוגי החשבונות ואת הישויות שקשורות אליהם.
Google לצרכנים
אם יש לכם כתובת אימייל ב-Gmail כמו alice@gmail.com, אז חשבון Gmail שלכם הוא חשבון פרטי. באופן דומה, אם משתמשים בקישור Create account בדף הכניסה באמצעות חשבון Google, ובמהלך ההרשמה מספקים כתובת אימייל מותאמת אישית שבבעלותכם, כמו alice@example.com, החשבון שנוצר הוא גם חשבון פרטי.
חשבון פרטי
חשבונות צרכן נוצרים בשירות עצמי ומיועדים בעיקר לשימוש למטרות פרטיות. למי שיצר את החשבון הפרטי יש שליטה מלאה בחשבון ובכל הנתונים שנוצרו באמצעות החשבון. כתובת האימייל שהמשתמש הזין במהלך ההרשמה הופכת לכתובת האימייל הראשית של החשבון הפרטי ומשמשת כזהות שלו. המשתמש הזה יכול להוסיף כתובות אימייל לחשבון הפרטי. כתובות האימייל האלה משמשות כזהויות נוספות ואפשר להשתמש בהן גם כדי להיכנס לחשבון.
כשבחשבון פרטי משתמשים בכתובת אימייל ראשית שתואמת לדומיין הראשי או המשני של חשבון Cloud Identity או Google Workspace, החשבון הפרטי נקרא גם חשבון אישי לא מנוהל.
חשבון צרכן יכול להיות חבר בכל מספר של קבוצות.
Google לארגונים
אם הארגון שלכם משתמש בשירותי Google, מומלץ להשתמש בחשבונות משתמשים מנוהלים. החשבונות האלה נקראים מנוהלים כי הארגון יכול לשלוט באופן מלא במחזור החיים ובהגדרות שלהם.
חשבונות משתמשים מנוהלים הם תכונה של Cloud Identity ו-Google Workspace.
חשבון Cloud Identity או Google Workspace
חשבון Cloud Identity או Google Workspace הוא מאגר ברמה העליונה של משתמשים, קבוצות, הגדרות ונתונים. חשבון Cloud Identity או Google Workspace נוצר כשחברה נרשמת ל-Cloud Identity או ל-Google Workspace, והוא תואם למושג דייר (tenant).
Cloud Identity ו-Google Workspace חולקים פלטפורמה טכנית משותפת. שני המוצרים משתמשים באותה קבוצה של ממשקי API וכלי ניהול, ומשתפים את הרעיון של חשבון כמאגר למשתמשים ולקבוצות. המאגר הזה מזוהה באמצעות שם דומיין. למטרות ניהול משתמשים, קבוצות ואימות, שני המוצרים נחשבים שווי ערך במידה רבה.
חשבון מכיל קבוצות ויחידה ארגונית אחת או יותר.
יחידה ארגונית
יחידה ארגונית (OU) היא מאגר משני של חשבונות משתמשים, שמאפשר לפלח את חשבונות המשתמשים שמוגדרים בחשבון Cloud Identity או Google Workspace לקבוצות נפרדות כדי שיהיה קל יותר לנהל אותם.
היחידות הארגוניות מסודרות בהיררכיה. לכל חשבון Cloud Identity או Google Workspace יש יחידה ארגונית ברמה הבסיסית, שמתחתיה אפשר ליצור עוד יחידות ארגוניות לפי הצורך. אתם יכולים גם להגדיר יחידות ארגוניות בתצוגת עץ.
ב-Cloud Identity וב-Google Workspace אפשר להחיל הגדרות מסוימות לפי יחידה ארגונית, כמו הקצאת רישיונות או אימות דו-שלבי. ההגדרות האלה חלות באופן אוטומטי על כל המשתמשים ביחידה הארגונית, וגם עוברות בירושה ליחידות הארגוניות ברמת הצאצא. לכן, ליחידות ארגוניות יש תפקיד חשוב בניהול ההגדרות האישיות של Cloud Identity ו-Google Workspace.
חשבון משתמש יכול להשתייך רק ליחידה ארגונית אחת, וזה ההבדל בין יחידות ארגוניות לבין קבוצות. למרות שהיחידות הארגוניות שימושיות להחלת הגדרות אישיות על חשבונות משתמשים, הן לא מיועדות לניהול הגישה. כדי לנהל את הגישה, מומלץ להשתמש בקבוצות.
למרות שהיחידות הארגוניות דומות לGoogle Cloud תיקיות, לשתי הישויות יש מטרות שונות והן לא קשורות זו לזו.
חשבון משתמש מנוהל
חשבונות משתמשים מנוהלים פועלים באופן דומה לחשבונות משתמשים פרטיים, אבל האדמינים של חשבון Cloud Identity או Google Workspace יכולים לשלוט בהם באופן מלא.
הזהות של חשבון משתמש מנוהל מוגדרת לפי כתובת האימייל הראשית שלו.
כתובת האימייל הראשית צריכה להשתמש בדומיין שתואם לאחד מהדומיינים הראשיים, המשניים או החלופיים שנוספו לחשבון Cloud Identity או Google Workspace. לחשבונות משתמשים מנוהלים יכולות להיות כתובות אימייל חלופיות נוספות וכתובת אימייל לשחזור חשבון, אבל הכתובות האלה לא נחשבות לזהויות ואי אפשר להשתמש בהן כדי להיכנס לחשבון. לדוגמה, אם אליס משתמשת ב-alice@example.com ככתובת האימייל הראשית שלה, והגדירה את ally@example.com ככתובת אימייל חלופית ואת alice@gmail.com ככתובת אימייל לשחזור החשבון, כתובת האימייל היחידה שאליס יכולה להשתמש בה כדי להיכנס לחשבון היא alice@example.com.
חשבונות משתמשים מנוהלים כלולים ביחידה ארגונית ויכולים להיות חברים בכל מספר של קבוצות.
חשבונות משתמשים מנוהלים מיועדים לשימוש של משתמשים אנושיים ולא של משתמשים שהם מכונות. חשבון משתמש של מכונה הוא סוג מיוחד של חשבון, שמשמש אפליקציה או מכונה וירטואלית (VM) ולא אדם. למשתמשים שהם מכונות,Google Cloud מספק חשבונות שירות. (בהמשך המאמר נפרט יותר על חשבונות שירות).
חשבון משתמש לא מנוהל
כשמישהו משתמש בכתובת האימייל הארגונית שלו כדי ליצור חשבון Google, החשבון הזה הוא חשבון לא מנוהל.
בניגוד לחשבונות משתמשים מנוהלים, החשבונות האלה לא נמצאים בשליטה הניהולית של הארגון.
פתרון בעיות והעברת חשבונות לא מנוהלים
בהקשר של Cloud Identity ו-Google Workspace, חשבונות לא מנוהלים מתחלקים לשתי קטגוריות:
- חשבונות אישיים לא מנוהלים: חשבונות שנוצרו על ידי אנשים פרטיים באמצעות כתובת האימייל של החברה שלהם כדי לגשת לשירותי Google לצרכנים.
- חשבונות לא מנוהלים של מקום עבודה (או צוותים לא מנוהלים): חשבונות שנוצרו על ידי משתמשים לשירותים עסקיים כמו Google Workspace Essentials או Google Cloud.
כשאדמין יוצר חשבון מנוהל עם אותה כתובת אימייל כמו חשבון לא מנוהל, נוצרת התנגשות בין החשבונות. כדי לפתור התנגשויות בין חשבונות ולהשתלט על חשבונות לא מנוהלים, אדמין צריך לבצע את הפעולות הבאות:
- אימות הבעלות על הדומיין. אחרי שהדומיין מאומת, המשתמשים לא יכולים יותר להשתמש בכתובת האימייל הארגונית שלהם כדי ליצור חשבונות לא מנוהלים.
- פתרון שגיאות שקשורות לחשבונות כפולים
- העברת חשבונות לשימוש אישי שלא מנוהלים
- העברת חשבונות לא מנוהלים של מקום עבודה
קבוצה
קבוצות מאפשרות לכם לאגד כמה משתמשים. אתם יכולים להשתמש בקבוצות כדי לנהל רשימת תפוצה או כדי להחיל בקרת גישה או הגדרות משותפות על כמה משתמשים.
Cloud Identity ו-Google Workspace מזהים קבוצות לפי כתובת אימייל, לדוגמה billing-admins@example.com. בדומה לכתובת האימייל הראשית של המשתמש, כתובת האימייל של הקבוצה צריכה להשתמש באחד מהדומיינים הראשיים, המשניים או החלופיים של החשבון ב-Cloud Identity או ב-Google Workspace. כתובת האימייל לא צריכה להתאים לתיבת דואר, אלא אם הקבוצה משמשת כרשימת תפוצה. האימות עדיין מתבצע באמצעות כתובת האימייל של המשתמש ולא באמצעות כתובת האימייל של הקבוצה, כך שמשתמש לא יכול להיכנס באמצעות כתובת אימייל של קבוצה.
קבוצה יכולה לכלול את הישויות הבאות כחברים:
- משתמשים (משתמשים מנוהלים או חשבונות פרטיים)
- קבוצות אחרות
- חשבונות שירות
בניגוד ליחידה ארגונית, קבוצות לא פועלות כמאגר:
- משתמש או קבוצה יכולים להיות חברים בכל מספר של קבוצות, לא רק באחת.
- מחיקת קבוצה לא מוחקת את המשתמשים או הקבוצות שחברים בה.
קבוצות יכולות להכיל חברים מכל חשבון Cloud Identity או Google Workspace, וגם חשבונות של לקוחות פרטיים. אתם יכולים להשתמש בהגדרה לא לאפשר חברים מחוץ לארגון כדי להגביל את החברים לחשבונות משתמשים באותו חשבון Cloud Identity או Google Workspace.
זהויות חיצוניות
כשמאחדים חשבון Cloud Identity או Google Workspace עם ספק זהויות חיצוני, העובדים יכולים להשתמש בזהות ובפרטי הכניסה הקיימים שלהם כדי להיכנס לשירותי Google.
ברמה הבסיסית ביותר, איחוד כרוך בהגדרת כניסה יחידה (SSO) באמצעות SAML, שמקשרת בין זהויות ב-Cloud Identity או ב-Google Workspace לבין זהויות שמנוהלות על ידי ה-IdP החיצוני. כדי לקשר זהות כמו alice@example.com ולהפעיל אותה לכניסה יחידה ל-Google, צריך לעמוד בשני תנאים מוקדמים:
- ספק הזהויות החיצוני צריך לזהות את הזהות
alice@example.comולאפשר להשתמש בה לכניסה יחידה (SSO). - בחשבון Cloud Identity או Google Workspace צריך להיות חשבון משתמש עם הזהות
alice@example.com. חשבון המשתמש הזה חייב להיות קיים לפני הניסיון הראשון לכניסה באמצעות כניסה יחידה.
במקום ליצור ולתחזק באופן ידני חשבונות משתמשים ב-Cloud Identity או ב-Google Workspace, אתם יכולים להפוך את התהליך לאוטומטי על ידי שילוב של כניסה יחידה (SSO) מבוססת-SAML עם הקצאת הרשאות אוטומטית למשתמשים. הרעיון של הקצאת הרשאות אוטומטית למשתמשים הוא לסנכרן את כל המשתמשים והקבוצות, או קבוצת משנה שלהם, ממקור סמכותי חיצוני ל-Cloud Identity או ל-Google Workspace.
בהתאם לספק הזהויות שבחרתם, יכול להיות שרכיב התוכנה שמטפל בכניסה יחידה מבוססת-SAML מטפל גם בהקצאת הרשאות אוטומטית למשתמשים, או שצריך רכיבים נפרדים. לכן, מודל הדומיין מבדיל בין ספק זהויות SAML לבין מקור סמכות חיצוני.
ספק זהויות חיצוני ב-SAML
ספק הזהויות החיצוני הוא המערכת היחידה לאימות, והוא מספק לעובדים חוויית כניסה יחידה (SSO) שכוללת את כל האפליקציות. הוא חיצוני ל-Google, ולכן נקרא ספק זהויות חיצוני.
כשמגדירים כניסה יחידה, Cloud Identity או Google Workspace מעבירים את החלטות האימות ל-SAML IdP. במונחי SAML, Cloud Identity או Google Workspace פועלים כספק שירות שסומך על ה-IdP של SAML שיאמת את זהות המשתמש בשמו.
ספקי זהויות חיצוניים נפוצים כוללים את Active Directory Federation Services (AD FS), Entra ID, Okta או Ping Identity.
מקור מידע מהימן חיצוני
מקור הזהויות המהימן הוא המערכת היחידה שבה אתם משתמשים כדי ליצור, לנהל ולמחוק את הזהויות של העובדים שלכם. הוא חיצוני ל-Google, ולכן הוא נקרא מקור סמכותי חיצוני.
ממקור הסמכות החיצוני, אפשר להקצות באופן אוטומטי חשבונות משתמשים וקבוצות ל-Cloud Identity או ל-Google Workspace. ההקצאה יכולה להתבצע על ידי המקור המוסמך עצמו, או באמצעות תוכנת ביניים להקצאה.
כדי שההקצאה האוטומטית של המשתמשים תהיה יעילה, צריך להקצות למשתמשים זהות שספק הזהויות ב-SAML מזהה. אם אתם ממפים בין זהויות (לדוגמה, אם אתם ממפים את הזהות alice@example.com ב-Cloud Identity או ב-Google Workspace ל-u12345@corp.example.com ב-SAML IdP), גם ה-SAML IdP וגם התוכנה לניהול הקצאת הרשאות צריכים לבצע את אותו מיפוי.
חשבון משתמש חיצוני
ספקי זהויות חיצוניים אמורים לכלול את הקונספט של חשבון משתמש, שבו מתבצע מעקב אחרי השם, המאפיינים וההגדרות.
המקור המוסמך (או תוכנת הביניים להקצאת הרשאות) אמור להקצות את כל חשבונות המשתמשים החיצוניים (או קבוצת משנה שלהם) ל-Cloud Identity או ל-Google Workspace, כדי לאפשר חוויית כניסה. במקרים רבים, מספיק להפיץ רק קבוצת משנה של מאפייני המשתמש (כמו כתובת אימייל, שם פרטי ושם משפחה) ל-Cloud Identity או ל-Google Workspace, כדי להגביל את יתירות הנתונים.
קבוצה חיצונית
אם ה-IdP החיצוני תומך בקבוצות, אתם יכולים למפות את הקבוצות האלה לקבוצות ב-Cloud Identity או ב-Google Workspace.
מיפוי והקצאת משאבים אוטומטית לקבוצות הם אופציונליים ולא נדרשים לכניסה יחידה, אבל שני השלבים יכולים להיות שימושיים אם רוצים להשתמש שוב בקבוצות קיימות כדי לשלוט בגישה ב-Google Workspace או ב- Google Cloud.
Google Cloud
כמו שירותים אחרים של Google, Google Cloud מסתמך על כניסה באמצעות חשבון Google כדי לאמת משתמשים. בנוסף, Google Cloud משולב באופן הדוק עם Google Workspace ו-Cloud Identity כדי לאפשר לכם לנהל משאבים ביעילות.
ב-Google Cloud מוצג הרעיון של צומתי ארגון, תיקיות ופרויקטים. הישויות האלה משמשות בעיקר לניהול הגישה וההגדרות, ולכן הן רלוונטיות רק באופן חלקי בהקשר של ניהול זהויות. עם זאת, Google Cloud כולל גם סוג נוסף של חשבון משתמש: חשבונות שירות. חשבונות השירות שייכים לפרויקטים, ויש להם תפקיד חשוב בניהול הזהויות.
צומת של ארגון
ארגון הוא הצומת של הרמה הבסיסית (root) בהיררכיית המשאבים שלGoogle Cloud , והוא מכיל פרויקטים ותיקיות. הארגונים מאפשרים לכם לארגן את המשאבים בהיררכיה, והם חיוניים לניהול המשאבים באופן מרוכז ויעיל.
כל ארגון שייך לחשבון Cloud Identity או לחשבון Google Workspace אחד. שם הארגון נגזר משם הדומיין הראשי של החשבון התואם ב-Cloud Identity או ב-Google Workspace.
תיקייה
תיקיות הן צמתים ב Google Cloud היררכיית המשאבים, והן יכולות להכיל פרויקטים, תיקיות אחרות או גם וגם. אפשר להשתמש בתיקיות כדי לקבץ משאבים שיש להם מדיניות משותפת של ניהול זהויות והרשאות גישה (IAM) או מדיניות ארגונית משותפת. כללי המדיניות האלה חלים באופן אוטומטי על כל הפרויקטים בתיקייה, וגם עוברים בירושה לתיקיות הצאצא.
תיקיות דומות ליחידות ארגוניות, אבל לא קשורות אליהן. יחידות ארגוניות עוזרות לכם לנהל משתמשים ולהחיל הגדרות או כללי מדיניות משותפים על משתמשים, ואילו תיקיות עוזרות לכם לנהל פרויקטים ב- Google Cloud ולהחיל הגדרות או כללי מדיניות משותפים על פרויקטים.
פרויקט
פרויקט הוא מאגר של משאבים. לפרויקטים יש תפקיד חיוני בניהול ממשקי API, בחיוב ובניהול הגישה למשאבים.
בהקשר של ניהול זהויות, פרויקטים רלוונטיים כי הם מכילים את חשבונות השירות.
חשבון שירות
חשבון שירות (או Google Cloud service account) הוא סוג מיוחד של חשבון משתמש שמיועד לשימוש על ידי אפליקציות וסוגים אחרים של משתמשי מכונה.
כל חשבון שירות שייך ל Google Cloud פרויקט. כמו בחשבונות משתמשים מנוהלים, לאדמינים יש שליטה מלאה על מחזור החיים ועל ההגדרות של חשבון השירות.
גם בחשבונות שירות משתמשים בכתובת אימייל בתור הזהות, אבל בניגוד לחשבונות משתמשים מנוהלים, כתובת האימייל תמיד משתמשת בדומיין שבבעלות Google, כמו .
חשבונות שירות לא משתתפים באיחוד ואין להם סיסמה. ב- Google Cloud, אתם יכולים להשתמש ב-IAM כדי לנהל את ההרשאות של חשבון השירות למשאב מחשוב, כמו מכונה וירטואלית (VM) או פונקציית Cloud Run, בלי לנהל את פרטי הכניסה. מחוץ ל- Google Cloud, אתם יכולים להשתמש במפתחות של חשבונות שירות כדי לאפשר לאפליקציה לבצע אימות באמצעות חשבון שירות.
חשבון שירות ב-Kubernetes
חשבונות שירות ב-Kubernetes הם קונספט של Kubernetes, והם רלוונטיים כשמשתמשים ב-Google Kubernetes Engine (GKE). בדומה לחשבונות שירות ב- Google Cloud , חשבונות שירות ב-Kubernetes מיועדים לשימוש באפליקציות, ולא על ידי בני אדם.
אפשר להשתמש בחשבונות שירות של Kubernetes כדי לבצע אימות כשאפליקציה קוראת ל-Kubernetes API של אשכול Kubernetes, אבל אי אפשר להשתמש בהם מחוץ לאשכול. הם לא מזוהים על ידי ממשקי Google API, ולכן הם לא מחליפים Google Cloud חשבון שירות.
כשפורסים אפליקציה כ-Pod של Kubernetes, אפשר לשייך את ה-Pod לחשבון שירות. השיוך הזה מאפשר לאפליקציה להשתמש ב-Kubernetes API בלי שתצטרכו להגדיר או לתחזק אישורים או פרטי כניסה אחרים.
באמצעות Workload Identity, אתם יכולים לקשר חשבון שירות של Kubernetes לחשבון שירות של Google Cloud . הקישור הזה מאפשר לאפליקציה לבצע אימות גם מול Google APIs, שוב בלי צורך לתחזק אישורים או פרטי כניסה אחרים.