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

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

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

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

תפקידים של חשבון שירות

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

התפקיד 'משתמש בחשבון שירות'

התפקיד 'משתמש בחשבון השירות' (roles/iam.serviceAccountUser) מאפשר לחשבון המשתמש לצרף חשבון שירות למשאב. כשהקוד שרץ במשאב הזה צריך לבצע אימות, הוא יכול לקבל פרטי כניסה לחשבון השירות המצורף.

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

התפקיד 'יצירת אסימונים בחשבון שירות'

התפקיד 'יצירת אסימונים בחשבון שירות' (roles/iam.serviceAccountTokenCreator) מאפשר לחשבונות משתמשים ליצור פרטי כניסה לטווח קצר לחשבון השירות.

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

  • אסימוני גישה מסוג OAuth 2.0, שבהם ניתן להשתמש כדי לבצע אימות באמצעות ממשקי ה-API של Google
  • אסימונים מזהים מסוג OpenID Connect‏ (OIDC)
  • אסימוני JWT (‏JSON Web Tokens) ו-blobs בינאריים

התפקיד 'יצירת אסימונים בחשבון שירות', גם מאפשר לחשבונות משתמשים להשתמש בדגל--impersonate-service-account ל-CLI של gcloud. כשמשתמשים בדגל הזה, ה-CLI של gcloud יוצר באופן אוטומטי פרטי כניסה לטווח קצר לחשבון השירות.

ההרשאות של התפקיד כוללות:

  • iam.serviceAccounts.getAccessToken: מאפשרת ליצור אסימוני גישה מסוג OAuth 2.0
  • iam.serviceAccounts.getOpenIdToken: מאפשרת ליצור אסימונים מזהים מסוג OpenID Connect‏ (OIDC)
  • iam.serviceAccounts.implicitDelegation: מאפשרת לחשבונות שירות לקבל אסימונים בשרשרת הענקת הגישה
  • iam.serviceAccounts.signBlob: מאפשרת לחתום על blobs בינאריים
  • iam.serviceAccounts.signJwt: מאפשרת לחתום על אסימוני JWT

יצירת אסימונים מזהים מסוג OpenID Connect בחשבון שירות

התפקיד 'יצירת אסימונים מזהים מסוג OpenID Connect בחשבון שירות' (roles/iam.serviceAccountOpenIdTokenCreator) מאפשר לחשבונות משתמשים ליצור אסימונים מזהים מסוג OIDC לטווח קצר. אם הצורך הוא רק ליצור אסימונים מזהים מסוג OIDC, צריך להשתמש בתפקיד הזה. אם הצורך הוא ליצור סוגים אחרים של אסימונים, צריך להשתמש במקום זאת בתפקיד 'יצירת אסימונים בחשבון שירות'.

התפקיד כולל את ההרשאה iam.serviceAccounts.getOpenIdToken, שמאפשרת ליצור אסימון מזהה מסוג OIDC.

התפקיד 'משתמש ב-Workload Identity'

התפקיד 'משתמש ב-Workload Identity' (roles/iam.workloadIdentityUser) מאפשר לחשבונות המשתמשים להתחזות לחשבונות שירות מעומסי עבודה של GKE.

ההרשאות של התפקיד כוללות:

  • iam.serviceAccounts.getAccessToken: מאפשרת ליצור אסימוני גישה מסוג OAuth 2.0
  • iam.serviceAccounts.getOpenIdToken: מאפשרת ליצור אסימונים מזהים מסוג OpenID Connect‏ (OIDC)

הרשאות חשבון שירות בתרחישים נפוצים

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

צירוף חשבונות שירות למשאבים

כדי להתחיל משימה ממושכת שתבצע אימות כחשבון השירות, צריך לצרף חשבון שירות למשאב שיפעיל את המשימה.

הרשאות:

  • הרשאות ליצירת המשאב
  • iam.serviceAccounts.actAs

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

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

  • מכונות וירטואליות של Compute Engine
  • אפליקציות App Engine
  • פונקציות Cloud Run

כשיוצרים את המשאבים האלו, יש אפשרות לצרף חשבון שירות. חשבון השירות ישמש בתור זהות המשאב.

כדי ליצור משאב ולצרף חשבון שירות, נדרשות הרשאות ליצירת המשאב וההרשאה לצרף את חשבון השירות למשאבים. אפשר לקבל את ההרשאה לצרף חשבונות שירות למשאבים מכל תפקיד שכולל את ההרשאה iam.serviceAccounts.actAs, לדוגמה, התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser).

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

למידע נוסף על צירוף חשבונות שירות למשאבים, אפשר לעיין במאמר צירוף חשבון שירות למשאב.

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

הרשאות:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccounts.implicitDelegation

תפקידים:

  • roles/iam.serviceAccountTokenCreator (יצירת אסימונים בחשבון שירות)

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

קודם, המשתמש יכול לבצע אימות כחשבון השירות. לדוגמה, הם יכולים לקבל פרטי כניסה לטווח קצר לחשבון השירות באמצעות ההרשאה iam.serviceAccounts.getAccessToken, ובאמצעות קריאה לשיטה generateAccessToken(). לחלופין, הם יכולים להשתמש בדגל --impersonate-service-account עבור ה-CLI של gcloud כדי להתחזות לחשבון השירות. כשמשתמש מבצע אימות כחשבון שירות, הוא יכול להנפיק פקודות ל-Google Cloud ולקבל גישה לכל המשאבים שאליהם יש לחשבון השירות גישה.

שנית, המשתמש יכול לקבל ארטיפקטים חתומים במפתח הפרטי שבניהול Google של חשבון השירות באמצעות ההרשאה iam.serviceAccounts.signBlob ובאמצעות קריאה לשיטה signBlob() או signJwt(). המפתח הפרטי שבניהול Google תמיד נשמר בנאמנות ולעולם לא נחשף ישירות. השיטה signBlob() מאפשרת לחתום על מטענים ייעודיים (payloads) שרירותיים (כמו כתובות URL בחתימה של Cloud Storage), בעוד שהשיטה signJwt() מאפשרת לחתום רק על קובצי JWT תקינים.

לסיום, המשתמש יכול להתחזות לחשבון השירות בלי לאחזר את פרטי הכניסה לחשבון השירות. זהו תרחיש לדוגמה מתקדם, והוא נתמך רק לגישה פרוגרמטית באמצעות השיטה generateAccessToken(). בתרחישים עם לפחות 3 חשבונות שירות, כלומר A,‏ B, ו-C: חשבון שירות A יכול לקבל אסימון גישה לחשבון השירות C, אם חשבון השירות A קיבל את ההרשאה iam.serviceAccounts.implicitDelegation ב-B, ו-B קיבל את ההרשאה iam.serviceAccounts.getAccessToken ב-C.

יצירת אסימונים מזהים מסוג OpenID Connect ‏(OIDC)

הרשאות:

  • iam.serviceAccounts.getOpenIdToken

תפקידים:

  • roles/iam.serviceAccountOpenIdTokenCreator (יצירת אסימוני מזהים מסוג OpenID Connect בחשבון שירות)

משתמש (או שירות) יכול ליצור אסימון JWT תואם OpenID Connect ‏(OIDC) בחתימה של ספק ה-OIDC של Google‏ (accounts.google.com) שמייצג את זהות חשבון השירות באמצעות ההרשאה iam.serviceAccounts.getOpenIdToken.

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

יצירת מפתחות פרטיים חיצוניים

הרשאות:

  • iam.serviceAccountKeys.create

תפקידים:

  • roles/editor ('עריכה')
  • roles/iam.serviceAccountKeyAdmin ('אדמין של מפתח בחשבון שירות')

משתמש או שירות יכולים ליצור חומר חיצוני של מפתח פרטי (RSA), שאפשר להשתמש בו כדי לבצע אימות ל-Google ישירות כחשבון השירות. לאחר מכן ניתן להשתמש בחומר המפתח הזה יחד עם ספריות Application Default Credentials (ADC), או עם הפקודה gcloud auth activate-service-account. כל אדם שיקבל גישה לחומר המפתח יקבל גישה מלאה לכל המשאבים שאליהם יש לחשבון השירות גישה. צריך להתייחס לחומר הזה של המפתח הפרטי בזהירות רבה, וככל שהוא קיים יותר זמן צריך להעריך אותו כפחות בטוח. לכן חשוב מאוד לבצע רוטציה לחומר של מפתחות פרטיים כדי לשמור על אבטחה חזקה.

הרשאות לחשבון שירות שמאפשרות יכולות אחרות

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

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

בטבלה הבאה מוצגות הפעולות שההרשאות האלה מאפשרות:

הרשאה פעולות שהופעלו
iam.serviceAccounts.getAccessToken קבלת אסימון גישה לחשבון השירות
iam.serviceAccounts.getOpenIdToken קבלת אסימון מזהה לחשבון השירות
iam.serviceAccounts.signJwt
iam.serviceAccounts.signBlob
  • חתימה על כל סוג של blob, כולל JWT
  • מקבלים אסימון גישה או אסימון מזהה לחשבון השירות באמצעות אסימון למוכ"ז מסוג JWT.

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

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

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

  • שימוש ב-API של IAM כדי לבדוק את חשבונות השירות, את המפתחות ואת כללי מדיניות ההרשאה באותם חשבונות שירות.
  • אם חשבונות השירות לא צריכים את המפתחות של חשבונות השירות, יש להשבית או למחוק אותם.
  • אם המשתמשים לא צריכים הרשאה כדי לנהל את חשבונות השירות או להשתמש בהם, צריך להסיר אותם ממדיניות ההרשאה הרלוונטית.
  • להבין איך מתן הרשאות מסוימות לחשבונות שירות יכול להפעיל למעשה יכולות אחרות.
  • חשוב לוודא שלחשבונות השירות יש את כמות ההרשאות הכי מועטה שאפשר. חשוב להפעיל שיקול דעת בעת השימוש בחשבונות שירות שמוגדרים כברירת מחדל, מכיוון שהם קיבלו באופן אוטומטי את התפקיד 'עריכה' (roles/editor) בפרויקט.

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

נסו בעצמכם

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

מתחילים לעבוד בלי לשלם