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

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

אפשר להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה עם עומסי עבודה שעוברים אימות באמצעות אישורי לקוח X.509, שפועלים ב-Amazon Web Services ‏ (AWS) או ב-Azure, ב-Active Directory מקומי, בשירותי פריסה כמו GitHub ו-GitLab, ועם כל ספק זהויות (IdP) שתומך ב-OpenID Connect ‏ (OIDC) או ב-Security Assertion Markup Language ‏ (SAML) גרסה 2.0).

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

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

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

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

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

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

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

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

מיפוי מאפיינים מגדיר איך להפיק את הערך של מאפיין האסימון של Security Token Service של Google מאסימון חיצוני. לכל מאפיין אסימון STS של 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 מספקת מיפויי ברירת מחדל ממאפייני האישור.

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

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

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

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

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

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

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

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

  • אם אתם משתמשים ב-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 עם מגבלות. אפשר גם להשתמש בהתחזות לחשבון שירות.

אסימון הגישה לטווח קצר מאפשר לבצע קריאה לכל ממשקי ה-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

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