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

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

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

למה צריך את איחוד שירותי אימות הזהות של עומסי עבודה?

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

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

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

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

באופן כללי, מומלץ ליצור מאגר חדש לכל סביבה שאינה שלGoogle Cloudשצריכה לגשת למשאבי Google Cloud , כמו סביבות פיתוח, Staging או ייצור.

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

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

  • AWS
  • Microsoft Entra ID
  • GitHub
  • GitLab
  • אשכולות Kubernetes
  • Okta
  • Active Directory Federation Services ‏(AD FS) בארגון
  • Terraform

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

ספק OIDC עם מפתחות JWK מקומיים

כדי לאחד עומסי עבודה שאין להם נקודת קצה ציבורית של OIDC, אתם יכולים להעלות קבוצות של מפתחות אינטרנט מסוג JSON ‏(JWKS) של OIDC ישירות למאגר. זה קורה בדרך כלל אם Terraform או GitHub Enterprise מתארחים בסביבה שלכם, או אם יש לכם דרישות רגולטוריות לא לחשוף כתובות URL ציבוריות. מידע נוסף זמין במאמר ניהול מפתחות JWK של OIDC (אופציונלי).

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

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

אסימוני Google Security Token Service מכילים גם מאפיין אחד או יותר, כמפורט בטבלה הבאה:

מאפיין תיאור
google.subject חובה. מזהה ייחודי של המשתמש. המאפיין משמש לקישורים של תפקידי principal:// ב-IAM ומופיע ביומני Cloud Logging. הערך חייב להיות ייחודי ולא יכול לחרוג מ-127 תווים.
google.groups אופציונלי. סט של קבוצות שהזהות שייכת אליהן. המאפיין משמש לקישורים של תפקידי principalSet:// ב-IAM כדי להעניק גישה לכל החברים בקבוצה.
attribute.NAME זה שינוי אופציונלי. אפשר להגדיר עד 50 מאפיינים מותאמים אישית ולהשתמש בהם בקישורים של תפקידי principalSet:// ב-IAM כדי להעניק גישה לכל הזהויות עם מאפיין מסוים.

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

TARGET_ATTRIBUTE=SOURCE_EXPRESSION

מחליפים את מה שכתוב בשדות הבאים:

  • ‫TARGET_ATTRIBUTE הוא מאפיין של אסימון Security Token Service של Google
  • ‫SOURCE_EXPRESSION הוא ביטוי של Common Expression Language (CEL) שמבצע טרנספורמציה של מאפיין אחד או יותר מהאסימונים שהנפיק ספק הזהויות החיצוני

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

  • הקצאה של המאפיין טענת נכוֹנוּת (assertion) sub ל-google.subject:

    google.subject=assertion.sub

  • שרשור מספר מאפייני טענת נכוֹנוּת (assertion):

    google.subject='myprovider::' + assertion.aud + '::' + assertion.sub

  • ביצוע מיפוי של מאפיין טענת נכוֹנוּת (assertion) workload_id בעל ערך GUID לשם והקצאה של התוצאה למאפיין מותאם אישית בשם attribute.my_display_name:

    attribute.my_display_name={
  "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
  "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
}[assertion.workload_id]

  • שימוש באופרטורים לוגיים ופונקציות של CEL כדי להגדיר מאפיין מותאם אישית בשם attribute.environment ל-prod או ל-test, בהתאם לשם המשאב של Amazon‏ (ARN) לזהות.

    attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"

  • שימוש בפונקציה extract כדי לאכלס מאפיין מותאם אישית aws_role עם שם התפקיד שהוקצה לו, או לחלופין עם ARN של הזהות אם לא הוקצה לו תפקיד.

    attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

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

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

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

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

כשמשתמשים באישורי לקוח מסוג X.509, כברירת מחדל איחוד שירותי אימות הזהות של עומסי עבודה ממפה את google.subject לשם הנפוץ (assertion.subject.dn.cn) של נושא אישור הלקוח:

google.subject=assertion.subject.dn.cn

אפשר גם למפות מאפיינים נוספים מהאישור של הישות ומהאישור של הגורם המתווך.

ב-AWS, אם לא מציינים מיפוי מאפיינים, Google מחילה את מיפוי ברירת המחדל הבא, שמכסה את רוב התרחישים הנפוצים:

google.subject=assertion.arn
attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

המיפוי הזה מגדיר את google.subject ל-ARN של המתקשר, ואת attribute.aws_role ל-ARN של התפקיד המשוער (בלי שם הסשן) אם יש תפקיד משוער, או ל-ARN של המתקשר אם אין תפקיד משוער. ניתן גם לספק מיפויים מותאמים אישית.

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

מידע נוסף מופיע במאמרי העזרה של ה-API של השדה attributeMapping.

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

תנאי של מאפיין הוא ביטוי CEL שיכול לבדוק מאפייני טענת נכוֹנוּת (assertion) ומאפייני יעד. אם התנאי למאפיין מקבל ערך של true לגבי פרטי כניסה מסוימים, הפרטים האלה מאושרים. אחרת, פרטי הכניסה יידחו.

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

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

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

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

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

הדוגמה הבאה מאפשרת בקשות רק מזהויות שיש להן תפקיד AWS ספציפי:

attribute.aws_role == "ROLE_MAPPING"

מידע נוסף מופיע במאמרי העזרה של ה-API של השדה attributeCondition.

ניהול הרשאות גישה

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

אתם יכולים להשתמש בטוקן הגישה הזה כדי לתת גישה ל-IAM.

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

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

גישה ישירה למשאבים

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

חלופה: התחזות לחשבון שירות

במקום לתת גישה ישירה למשאבים, אתם יכולים להשתמש בהתחזות לחשבון שירות.

אתם צריכים להקצות לחשבון השירות את התפקיד "משתמש ב-Workload Identity" (roles/iam.workloadIdentityUser).

היקפי הרשאות ואבטחה של חשבונות משתמשים

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

סוגים של חשבונות משתמשים

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

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

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