איחוד שירותי אימות הזהות של כוח העבודה

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

מה זה איחוד שירותי אימות הזהות של כוח עבודה?

איחוד שירותי אימות הזהות של כוח עבודה מאפשר לכם להשתמש בספק זהויות חיצוני (IdP) כדי לאמת את כוח העבודה שלכם – משתמשים וקבוצות של משתמשים, כמו עובדים, שותפים וקבלנים. אחרי כן, המשתמשים יוכלו לגשת אל Google Cloud באמצעות כניסה יחידה (SSO) דרך ספק הזהויות שלכם. אתם יכולים להשתמש במדיניות של ניהול הזהויות והרשאות הגישה (IAM) כדי לתת למשתמשים בכוח העבודה הרשאה לגשת Google Cloud לשירותים.

פדרציה לעומת סנכרון

איחוד שירותי אימות הזהות של כוח עבודה מאחד זהויות מה-IdP שלכם, ולכן הוא לא מאחסן חשבונות משתמשים ב- Google Cloud. בגלל זה, איחוד שירותי אימות הזהות של כוח עבודה לא מצריך סנכרון, כלומר אתם לא צריכים להשתמש בכלים כדי לסנכרן זהויות משתמשים מה-IdP עם זהויות שמנוהלות על ידי Google ודורשות חשבונות Google. לדוגמה, אם משתמשים באיחוד שירותי אימות הזהות של כוח העבודה, לא צריך להשתמש ב-Google Cloud Directory Sync (GCDS) של Cloud Identity.

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

איחוד זהויות של כוח עבודה מאחד זהויות של משתמשים, בעוד ש-Workload Identity Federation מאחד זהויות של עומסי עבודה.

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

גישה שמבוססת על מאפיינים

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

אחרי אימות המשתמש, המאפיינים שמתקבלים מה-IdP משמשים כדי לקבוע את היקף הגישה למשאבים של Google Cloud .

פרוטוקולים נתמכים

אפשר להשתמש באיחוד שירותי אימות הזהות של כוח עבודה עם כל IdP שתומך ב-OpenID Connect ‏ (OIDC) או ב-SAML 2.0, כמו Microsoft Entra ID,‏ Active Directory Federation Services ‏(AD FS),‏ Okta ואחרים.

מושגים מרכזיים

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

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

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

באמצעות המאגרים האלה, אפשר:

  • לקבץ זהויות משתמשים. לדוגמה, employees או partners
  • להעניק הרשאת גישה ב-IAM למאגר שלם או לקבוצת משנה שלו.
  • לאחד זהויות מ-IdP אחד או יותר.
  • להגדיר כללי מדיניות על קבוצת משתמשים שצריכים הרשאות גישה דומות.
  • לציין פרטי הגדרות שספציפיים ל-IdP, כולל מיפוי מאפיינים ותנאי מאפיינים.
  • לאפשר לזהויות של צד שלישי גישה ל-CLI ול-API של Google Cloud.
  • לרשום גישה של משתמשים שנמצאים במאגר ביומני הביקורת של Cloud, יחד עם מזהה המאגר.

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

המאגרים מוגדרים בGoogle Cloud רמת הארגון, ולכן צריך להתחשב בשיקולים הבאים:

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

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

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

איחוד שירותי אימות הזהות של כוח עבודה תואם למפרט OAuth 2.0 Token Exchange (RFC 8693). אתם צריכים לספק פרטי כניסה מספק הזהויות החיצוני שלכם ל-Security Token Service, שמאמת את הזהות בפרטי הכניסה. לאחר מכן הוא מחזיר בתמורה אסימון גישה לטווח קצר Google Cloud .

סוגים של זרימת OIDC

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

Google Cloud מסוף איחוד שירותי אימות הזהות של כוח העבודה

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

מאפיינים

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

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

אפשר למפות את המאפיינים האלה לשימוש על ידי Google Cloud באמצעות Common Expression Language (CEL).

בקטע הזה מוסבר על קבוצת המאפיינים הנדרשים והאופציונליים שזמינים ב-Google Cloud .

אפשר גם להגדיר מאפיינים מותאמים אישית ב-IdP ואז להשתמש בהם במוצרים ספציפיים של Google Cloud . לדוגמה, בכללי מדיניות ההרשאות של IAM.

הגודל המקסימלי למיפויים של מאפיינים הוא 16KB. אם גודל המיפויים של המאפיינים חורג מהמגבלה של 16KB, ניסיון הכניסה ייכשל.

אלו המאפיינים:

  • ‫google.subject (חובה): מזהה ייחודי של המשתמש המאמת. בדרך כלל מדובר בטענת הנכוֹנוּת (assertion) לגבי הנושא של ה-JWT, כי הרישומים של יומני הביקורת של Cloud מתעדים את התוכן של השדה הזה בתור חשבון ראשי. אפשר להשתמש בשדה הזה כדי להגדיר את IAM לקבלת החלטות לגבי הרשאות. מומלץ לא להשתמש בערך שאפשר לשנות, כי אם משנים את הערך בספריית המשתמשים של ה-IdP, המשתמש מאבד את הגישה.

    האורך המקסימלי הוא 127 בייטים.

  • ‫google.groups (אופציונלי): אוסף הקבוצות שהמשתמש שמבצע את האימות חבר בהן. אתם יכולים להגדיר ביטוי לוגי באמצעות קבוצת משנה של CEL שמפיקה מערך מחרוזות. אפשר גם להשתמש בשדה הזה כדי להגדיר את IAM לקבלת החלטות לגבי הרשאות. המגבלות של google.groups הן:

    • מומלץ להגביל את שם הקבוצה ל-40 תווים לכל היותר.

    • אם משתמש אחד שייך ליותר מ-400 קבוצות, ניסיון הכניסה של המשתמש ייכשל. כדי לפתור את הבעיה, צריך להגדיר קבוצה קטנה יותר של קבוצות בטענת הנכוֹנוּת, ולמפות רק את הקבוצות שמשמשות לאיחוד המשתמש ב- Google Cloud.

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

  • ‫google.display_name (אופציונלי): המאפיין שמשמש להגדרת השם של המשתמש שנכנס לחשבון ב Google Cloud מסוף. אי אפשר להשתמש במאפיין הזה בכללי מדיניות ההרשאות ב-IAM וגם לא בתנאי המאפיין.

    האורך המקסימלי הוא 100 בייטים.

  • ‫google.profile_photo (אופציונלי): כתובת URL של התמונה הממוזערת של המשתמש. מומלץ להשתמש בתמונה בגודל 400x400 פיקסלים. כשהמאפיין הזה מוגדר, התמונה מוצגת כתמונת הפרופיל של המשתמש במסוף Google Cloud . אם הערך לא מוגדר או שאי אפשר לאחזר אותו, יוצג במקום זאת סמל משתמש גנרי. אי אפשר להשתמש במאפיין הזה בכללי מדיניות ההרשאה ב-IAM וגם לא בתנאי המאפיין.

  • ‫google.posix_username (אופציונלי): מחרוזת ייחודית של שם משתמש שתואמת ל-POSIX ומשמשת למטרות הבאות:

    אי אפשר להשתמש במאפיין הזה בכללי מדיניות ההרשאות ב-IAM וגם לא בתנאי המאפיין. האורך המקסימלי הוא 32 תווים.

  • ‫google.email (אופציונלי): מאפיין שמשמש למיפוי כתובות אימייל של משתמשים מאוחדים שמחוברים לחשבון מ-IdP למוצרים שמשולבים באמצעות שילוב של לקוח OAuth של איחוד זהויות של כוח עבודה. אי אפשר להשתמש במאפיין הזה בכללי מדיניות ההרשאות ב-IAM וגם לא בתנאי המאפיין.

    לדוגמה, כדי למפות כתובות אימייל מ-Okta באמצעות פרוטוקול OIDC, צריך לכלול את google.email=assertion.email במיפוי המאפיינים.

    אלה כמה דוגמאות למוצרים Google Cloud שתומכים בשילוב של לקוח OAuth:

  • ‫attribute.KEY (אופציונלי): מאפיין בהגדרת IdP חיצוני שנמצא באסימון IdP של המשתמש. תוכלו להשתמש במאפיין המותאם אישית כדי להגדיר את אסטרטגיית ההרשאות במדיניות הרשאה ב-IAM.

    לדוגמה, ב-IdP, אתם יכולים להגדיר מאפיין כמו מרכז העלויות של המשתמש כ-costcenter = "1234", ואז להפנות אל ה-principal באופן הבא:

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.costcenter/1234

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

    אתם יכולים להגדיר עד 50 כללי מיפוי של מאפיינים מותאמים אישית. הגודל המקסימלי של כל כלל כזה הוא 2,048 תווים.

    אין מגבלות על המאפיינים שאפשר למפות כאן, אבל מומלץ מאוד לבחור מאפיינים שהערכים שלהם יציבים. לדוגמה, מאפיין כמו attribute.job_description עשוי להשתנות מסיבות רבות (למשל, שיפור הקריאוּת). במקום זאת, כדאי להשתמש ב-attribute.role, כי שינויים בו מעידים על שינוי באחריות המוקצית, והם תואמים לשינויים בגישה שהוענקה למשתמש.

אפשר לשנות ערכי מאפיינים באמצעות פונקציות CEL רגילות. אתם יכולים גם להשתמש בפונקציות המותאמות אישית הבאות:

  • הפונקציה split מפצלת מחרוזת בערך המפריד שצוין. לדוגמה, כדי לחלץ את המאפיין username ממאפיין של כתובת אימייל, על ידי פיצול הערך שלו ב-@ ושימוש במחרוזת הראשונה, משתמשים במיפוי המאפיינים הבא: 

    attribute.username=assertion.email.split("@")[0]

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

    attribute.department=assertion.department.join(".")

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

תנאים למאפיינים הם ביטויי CEL אופציונליים שמאפשרים להגדיר אילוצים על מאפייני הזהות ש- Google Cloud מקבל.

היתרונות של שימוש בתנאים של מאפיינים כוללים בין היתר:

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

תנאי מאפיינים לספקי זהויות מרובי-דיירים

איחוד שירותי אימות הזהויות של כוח העבודה לא מתחזק ספרייה של חשבונות משתמשים, אלא מיישם זהויות מבוססות-טענות. כתוצאה מכך, כשספק זהויות (IdP) מנפיק שני אסימונים וההצהרות שלהם ממופות לאותו ערך של google.subject, המערכת מניחה שהאסימונים האלה מזהים את אותו משתמש. כדי לגלות איזה IdP הנפיק אסימון, איחוד זהויות של כוח עבודה בודק ומאמת את כתובת ה-URL של המנפיק של האסימון.

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

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

רישום מפורט ביומן הביקורת

רישום מפורט ביומני הביקורת הוא תכונה של איחוד שירותי אימות הזהות של כוח עבודה, שרושמת ביומני הביקורת של Cloud מאפיינים שהתקבלו מה-IdP שלכם.

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

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

מפתחות אינטרנט בפורמט JSON

הספק של מאגר הזהויות של כוח העבודה יכול לגשת למפתחות אינטרנט מסוג JSON ‏ (JWKs) שה-IdP מספק בשדה jwks_uri במסמך /.well-known/openid-configuration. אם ספק ה-OIDC לא נותן את המידע הזה, או אם אין גישה ציבורית למונפק, אפשר להעלות באופן ידני את מפתחות ה-JWK כשיוצרים או מעדכנים את ספק ה-OIDC.

תמיכה ב-SCIM

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

מידע נוסף זמין במאמר הקצאת הרשאות SCIM לאיחוד שירותי אימות הזהות של כוח עבודה.

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

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

זהויות פורמט של מזהה
זהות יחידה במאגר זהויות של כוח עבודה principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
כל הזהויות של כוח העבודה בקבוצה principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
כל הזהויות של כוח העבודה עם ערך מאפיין ספציפי principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
כל הזהויות במאגר זהויות של כוח עבודה principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

רשימה מלאה של מזהי ישויות מורשות מופיעה במאמר מזהים של ישויות מורשות.

שיקולים נוספים

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

הגבלת הגישה בין ארגונים

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

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

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

כשיוצרים קובץ תצורה של איחוד זהויות של כוח עבודה, מציינים פרויקט של משתמש במאגרי כוח עבודה. הפרויקט הזה מזהה את האפליקציה שלכם ב-Google APIs ומשמש כפרויקט ברירת המחדל של המכסה עבור ממשקי API מבוססי-לקוח, אלא אם אתם משתמשים ב-CLI של gcloud כדי לשלוח את הבקשה. צריכה להיות לכם ההרשאה serviceusage.services.use (שכלולה בתפקיד 'צרכן השימוש בשירות' (roles/serviceusage.serviceUsageConsumer)) בפרויקט שצוין.

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

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

בקטע הזה מופיעה דוגמה שממחישה את השימוש האופייני במאגרים מרובים.

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

לדוגמה, נניח שחברה בשם Enterprise Example Organization לוקחת חברה אחרת בשם Partner Example Organization Inc כקבלנית, כדי שתספק לה שירותי DevOps של Google Kubernetes Engine‏ (GKE). כדי שכוח העבודה של Partner Example Organization יוכל לספק את השירותים, הוא צריך לקבל גישה ל-Google Kubernetes Engine‏ (GKE) ול Google Cloud משאבים אחרים בארגון של Enterprise Example Organization. לארגון Enterprise Example Organization כבר יש מאגר זהויות של כוח עבודה בשם enterprise-example-organization-employees.

כדי לאפשר ל-Partner Example Organization לנהל גישה למשאבים של Enterprise Example Organization, הארגון Enterprise Example Organization יוצר מאגר כוח עבודה נפרד למשתמשי כוח העבודה של Partner Example Organization, כדי ש-Partner Example Organization יוכל לנהל אותו. ‫Enterprise Example Organization מספק את מאגר כוח העבודה לאדמין של Partner Example Organization. האדמין של Partner Example Organization משתמש ב-IdP משלו כדי להעניק גישה לכוח העבודה שלו.

כדי לעשות זאת, האדמין של Enterprise Example Organization צריך:

  1. ליצור זהות, כמו partner-organization-admin@example.com, לאדמין של Partner Example Organization ב-IdP של Enterprise Example Organization, שכבר מוגדרת במאגר שנקרא enterprise-example-organization-employees.

  2. ליצור מאגר כוח עבודה חדש בשם example-organization-partner.

  3. ליצור את מדיניות ההרשאה הבאה למאגר example-organization-partner:

    {
  "bindings": [
    {
      "role": "roles/iam.workforcePoolEditor",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com"
      ]
    }
  ]
}

  4. להקצות תפקידים למאגר example-organization-partner במשאבים שאליהם כוח העבודה של החברה הקבלנית צריך לגשת בארגון של Enterprise Example Organization.

האדמין של Partner Example Organization יכול עכשיו להגדיר את המאגר example-organization-partner כדי להתחבר ל-IdP שלהם. לאחר מכן הוא יכול לאפשר לכוח עבודה של Partner Example Organization להיכנס עם פרטי הכניסה ל-IdP של Partner Example Organization. אחרי שמשתמשי כוח העבודה של Partner Example Organization נכנסו, הם יכולים לגשת למשאבים, בכפוף לכללי המדיניות שהוגדרו על ידי Enterprise Example Organization. Google Cloud

שיטות מומלצות לשימוש בקבוצות אבטחה

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

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

מגבלות של VPC Service Controls

תכונות ניהול של איחוד שירותי אימות הזהויות של כוח העבודה, כולל ממשקי API להגדרת מאגרי כוח עבודה וממשקי API של Security Token Service לא תומכים ב-VPC Service Controls. עם זאת, Google Cloud מוצרים שתומכים גם באיחוד שירותי אימות הזהות של כוח עבודה וגם ב-VPC Service Controls פועלים כמו שמתואר במסמכים, והם כפופים לבדיקות מדיניות של VPC Service Controls. בנוסף, אפשר להשתמש בזהויות של צד שלישי, כמו משתמשים במאגר הזהויות של כוח העבודה וזהויות של עומסי עבודה, בכללי תעבורת נתונים נכנסת (ingress) או יוצאת (egress) של VPC Service Controls.

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

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

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

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