אפשר לחלק את חשבונות השירות לקטגוריות הבאות:
- חשבונות שירות בניהול המשתמש, שאתם יוצרים ומנהלים בעצמכם
- סוכני שירות, ש Google Cloud יוצרים ומנהלים
בדף הזה מוסבר איך יוצרים כל סוג של חשבון שירות ואיך משתמשים בו.
חשבונות שירות בניהול המשתמשים
חשבונות שירות בניהול המשתמשים הם חשבונות שירות שאתם יוצרים בפרויקטים שלכם. אתם יכולים לעדכן, להשבית, להפעיל ולמחוק את חשבונות השירות האלה לפי שיקול דעתכם. תוכלו גם לנהל את הגישה של חשבונות משתמשים אחרים לחשבונות השירות האלה.
תוכלו ליצור חשבונות שירות בניהול המשתמשים בפרויקט באמצעות ה-API של IAM, מסוף Google Cloud Google Cloud או Google Cloud CLI.
כברירת מחדל, אפשר ליצור בכל פרויקט עד 100 חשבונות שירות בניהול המשתמשים. אם המכסה לא מתאימה לצרכים שלכם, אפשר להיכנס לGoogle Cloud מסוף ולשלוח בקשה לשינוי המכסות. המכסה הזאת רלוונטית רק לחשבונות שירות בניהול המשתמשים. חשבונות שירות שמוגדרים כברירת מחדל וסוכני שירות לא כלולים במכסה הזאת.
כשיוצרים בפרויקט חשבון שירות בניהול המשתמשים, צריך לבחור שם לחשבון השירות. השם הזה מופיע כחלק מכתובת האימייל שמזהה את חשבון השירות, בפורמט הבא:
service-account-name@project-id.iam.gserviceaccount.com
במאמר יצירת חשבונות שירות מוסבר איך יוצרים חשבון שירות.
חשבונות שירות שמוגדרים כברירת מחדל
חשבונות שירות שמוגדרים כברירת מחדל הם חשבונות שירות בניהול המשתמשים, שנוצרים באופן אוטומטי כשמפעילים או משתמשים בשירותים מסוימים של Google Cloud Google Cloud. חשבונות השירות האלה מאפשרים לשירותים לפרוס משימות שצריכות לגשת למשאבים אחרים ב-Google Cloud . אתם אחראים לנהל את חשבונות השירות שמוגדרים כברירת מחדל אחרי שהם נוצרים.
אם האפליקציה פועלת בסביבה שיש לה חשבון שירות שמוגדר כברירת מחדל, היא יכולה להשתמש בפרטי הכניסה של חשבון השירות שמוגדר כברירת מחדל כדי לקרוא ל-APIs. Google Cloud Google Cloud לחלופין, אתם יכולים ליצור חשבון שירות משלכם בניהול המשתמשים ולהשתמש בו לצורך אימות. מידע נוסף זמין במאמר בנושא הגדרה של Application Default Credentials.
בהתאם להגדרות של מדיניות הארגון, יכול להיות שחשבון השירות שמוגדר כברירת מחדל יקבל אוטומטית את התפקיד 'עריכה' בפרויקט. אנחנו ממליצים מאוד להשבית את הענקת התפקיד האוטומטית על ידי
החלת האילוץ iam.automaticIamGrantsForDefaultServiceAccounts של מדיניות הארגון. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.
אם משביתים את הענקת התפקיד האוטומטית, צריך לקבוע אילו תפקידים להעניק לחשבונות השירות שמוגדרים כברירת מחדל, ואז להעניק את התפקידים האלה בעצמכם.
אם לחשבון השירות שמוגדר כברירת מחדל כבר יש הרשאת עריכה, מומלץ להחליף את הרשאת העריכה בהרשאות עם פחות גישה.כדי לשנות את התפקידים בחשבון השירות בצורה בטוחה, כדאי להשתמש בסימולטור המדיניות כדי לראות את ההשפעה של השינוי, ואז לתת ולבטל את התפקידים המתאימים.
בטבלה הבאה מפורטים השירותים שבעזרתם אפשר ליצור חשבונות שירות שמוגדרים כברירת מחדל:
| השירות | שם חשבון השירות | כתובת האימייל |
|---|---|---|
| App Engine, וכל שירות Google Cloud שמשתמש ב-App Engine | חשבון השירות של App Engine שמוגדר כברירת מחדל | project-id@appspot.gserviceaccount.com |
| Compute Engine, וכל שירות שמשתמש ב-Compute Engine Google Cloud | חשבון השירות של Compute Engine שמוגדר כברירת מחדל |
project-number-compute@developer.gserviceaccount.com
|
סוכני שירות
חלק מהשירותים צריכים גישה למשאבים שלכם כדי שיוכלו לפעול בשמכם. Google Cloud לדוגמה, כשמשתמשים ב-Cloud Run כדי להריץ קונטיינר, השירות צריך גישה לכל נושא Pub/Sub שיכול להפעיל את הקונטיינר.
כדי לתת מענה לצורך הזה, Google Cloud יוצרת ומנהלת חשבונות שירות בשירותים רבים של Google Cloud . חשבונות השירות האלה נקראים סוכני שירות. סוכני שירות עשויים להופיע במדיניות ההרשאות של הפרויקט, ביומני הביקורת או בדף ה-IAM במסוף Google Cloud . כאן אפשר לראות רשימה מלאה של סוכני שירות.
סוכני שירות לא נוצרים בפרויקטים שלכם, ולכן לא תראו אותם כשאתם מציגים את חשבונות השירות של הפרויקטים. אי אפשר לגשת אליהם ישירות.
כברירת מחדל, סוכני שירות לא מופיעים בדף IAM במסוףGoogle Cloud , גם אם הוענק להם תפקיד בפרויקט. כדי לראות את התפקידים שניתנו לסוכני שירות, מסמנים את התיבה Include Google-provided role grants.

ב-Google Cloud יש את סוגי סוכני השירות הבאים:
סוכני שירות שספציפיים לשירות
רוב סוכני השירות הם ספציפיים לשירות – הם פועלים בשם של שירותים ספציפיים. במקרים רבים סוכני השירות האלה נדרשים כדי שהשירותים יפעלו כמו שצריך. לדוגמה, סוכני שירות הם שמאפשרים ל-sinks ב-Cloud Logging לכתוב יומנים בקטגוריות של Cloud Storage.
כל סוכן שירות משויך למשאב. המשאב הזה הוא בדרך כלל פרויקט, תיקייה או ארגון, אבל הוא יכול להיות גם משאב ספציפי לשירות, כמו מכונה של Cloud SQL. המשאב הזה מגדיר את היקף הפעולות של סוכן השירות. לדוגמה, אם סוכן השירות משויך לפרויקט, הוא יוכל לפעול בשם השירות בפרויקט ובמשאבים שהם הצאצאים שלו.
אפשר לברר את סוג המשאב שאליו משויך סוכן השירות לפי כתובת האימייל שלו, באופן הבא:
- אם סוכן השירות משויך לפרויקט, לתיקייה או לארגון, כתובת האימייל שלו תכיל את המזהה המספרי של הפרויקט, התיקייה או הארגון.
- אם סוכן השירות משויך למשאב ספציפי לשירות, כתובת האימייל שלו תכיל גם את המזהה המספרי של הפרויקט וגם את המזהה הייחודי של סוכן השירות. המזהה המספרי של הפרויקט מציין לאיזה פרויקט שייך המשאב שאליו משויך סוכן השירות. המזהה הייחודי של סוכן השירות עוזר להבחין בינו לבין סוכני שירות דומים אחרים באותו פרויקט.
סוכן שירות של Google APIs
מדיניות ההרשאות של הפרויקט עשויה להפנות לחשבון שירות בשם סוכן שירות של Google APIs, עם כתובת אימייל בפורמט הבא: project-number@cloudservices.gserviceaccount.com.
חשבון השירות הזה מפעיל תהליכים פנימיים Google Cloud בשמכם.
הוא מקבל אוטומטית את התפקיד 'עריכה' (roles/editor) בפרויקט.
מנהל התפקידים לסוכני שירות
יכול להיות שיומני הביקורת שלכם ב-IAM יפנו לחשבון השירות service-agent-manager@system.gserviceaccount.com.
באמצעות חשבון השירות הזה מעניקים תפקידים לסוכני שירות אחרים. אפשר לראות אותו רק ביומני הביקורת.
לדוגמה, אם אתם משתמשים בממשק API חדש, Google Cloud עשוי ליצור באופן אוטומטי סוכן שירות חדש ולהעניק לו תפקידים בפרויקט שלכם. כשמעניקים את התפקידים האלה נוצרת רשומה ביומן הביקורת, שמתעדת שחשבון המשתמש service-agent-manager@system.gserviceaccount.com הגדיר את מדיניות ההרשאות לפרויקט.
יצירה של סוכן שירות
הזמן המדויק שבו נוצר סוכן השירות נקבע בהתאם לסוג המשאב שאליו הוא משויך.
סוכני השירות שמשויכים למשאב שספציפי לשירות נוצרים בזמן יצירת המשאב. לקבלת מידע נוסף על זיהוי של סוכני שירות כאלה והגדרה שלהם, כדאי לעיין במסמכי התיעוד של המשאב המשויך.
סוכני השירות שמשויכים לפרויקטים, לתיקיות או לארגונים נוצרים לפי הצורך, בדרך כלל בפעם הראשונה שמשתמשים בשירות. במידת הצורך, אפשר גם לבקש מ- Google Cloud ליצור סוכני שירות לשירות לפני שמשתמשים בשירות. מידע נוסף זמין במאמר איך יוצרים סוכני שירות ומעניקים להם תפקידים.
תפקידי IAM לסוכני שירות
כדי לבצע פעולות מסוימות ב- Google Cloud , סוכני השירות צריכים ליצור משאבים ולגשת אליהם בשמכם. לדוגמה, כשיוצרים אשכול של Dataproc, סוכן השירות של Dataproc צריך הרשאה ליצירת מכונות של Compute Engine בפרויקט כדי שיוכל ליצור את האשכול.
כדי לקבל את הרשאת הגישה הזו, סוכני השירות צריכים לקבל תפקידי IAM ספציפיים. במקרים רבים, סוכני השירות ברמת הפרויקט מקבלים אוטומטית את התפקידים הנדרשים.
שמות התפקידים האלה שמוענקים באופן אוטומטי בדרך כלל מסתיימים ב-serviceAgent או ב-ServiceAgent. במקרה של סוכני שירות אחרים, עליכם להקצות להם את התפקידים כדי שהשירות יפעל כמו שצריך. בחומר העזר בנושא סוכני שירות מפורטים סוכני השירות שמקבלים תפקידים באופן אוטומטי.
אם אתם צריכים לדחות הרשאות מסוימות לקבוצות של חשבונות ראשיים שכוללות סוכני שירות – למשל, הקבוצה של החשבונות הראשיים principalSet://goog/public:all – מומלץ להוסיף את סוכני השירות שלכם כחריגים בכלל הדחייה. כך נוכל לוודא שהשירותים שלכם ימשיכו לפעול בצורה תקינה.
כשמוסיפים סוכני שירות כחריגים, משתמשים בקבוצת החשבונות הראשיים של סוכני השירות של הפרויקט, התיקייה או הארגון.
אם מבקשים מ- Google Cloud ליצור סוכני שירות לפני שמשתמשים בשירות, צריך להקצות להם ידנית את התפקידים שהם בדרך כלל מקבלים באופן אוטומטי. הסיבה לכך היא שסוכני שירות שנוצרים מבקשה של משתמש לא מקבלים תפקידים באופן אוטומטי. אם לא תקצו את התפקידים האלה לסוכני השירות, יכול להיות שחלק מהשירותים לא יפעלו כמו שצריך. במאמר איך יוצרים סוכני שירות ומעניקים להם תפקידים מוסבר איך מקצים את התפקידים האלה לסוכני שירות.
סוכני שירות ראשיים
סוכני שירות מסוימים מזוהים כסוכני שירות ראשיים בחומרי העזר של סוכני השירות. סוכני שירות ראשיים הם סוכני שירות שכתובת האימייל שלהם מוחזרת כשאתם מפעילים יצירת סוכן שירות.
יומני ביקורת של סוכני שירות
לפעמים, כשגורם מרכזי מתחיל פעולה, סוכן שירות מבצע פעולה בשם הגורם המרכזי. אבל כשבודקים יומני ביקורת של סוכן שירות, יכול להיות שיהיה קשה לדעת בשם מי סוכן השירות פעל ומדוע.
כדי לעזור לכם להבין את ההקשר של הפעולות של סוכני שירות, חלק מסוכני השירות כוללים פרטים נוספים ביומני הביקורת שלהם, כמו המשימה שהפעולה משויכת אליה והגורם הראשי שיצר את המשימה.סוכני השירות הבאים כוללים את הפרטים הנוספים האלה ביומני הביקורת שלהם:
הפרטים הנוספים האלה מופיעים בשדה serviceDelegationHistory של יומן הביקורת, שהוא שדה מקונן בשדה authenticationInfo. השדה הזה מכיל את המידע הבא:
- המנהל המקורי שיצר את ההזמנה
- סוכן השירות שביצע את הפעולה
- השירות שאליו שייך סוכן השירות
- מזהה המשרה
לדוגמה, נניח שמשתמש example-user@example.com יוצר עבודה באמצעות BigQuery Connection API. כדי שהעבודה הזו תפעל, צריך שאחד מסוכני השירות של BigQuery Connection API יבצע פעולה. במקרה כזה, יומן הביקורת של פעולת סוכן השירות יכיל שדה serviceDelegationHistory שדומה לזה:
{ "protoPayload": { "@type": "type.googleapis.com/google.cloud.audit.AuditLog", "authenticationInfo": { "principalEmail": "bqcx-442188550395-jujw@gcp-sa-bigquery-condel.iam.gserviceaccount.com", "serviceDelegationHistory": { "originalPrincipal": "user:my-user@example.com", "serviceMetadata": [ { "principalSubject": "serviceAccount:bqcx-442188550395-jujw@gcp-sa-bigquery-condel.iam.gserviceaccount.com", "serviceDomain": "bigquery.googleapis.com", } ] } } } }
המאמרים הבאים
- יצירה וניהול של חשבונות שירות
- יצירה וניהול של מפתחות לחשבונות שירות
- שיטות מומלצות לעבודה עם חשבונות שירות
- שיטות מומלצות לניהול מפתחות של חשבונות שירות
נסו בעצמכם
אתם משתמשים חדשים ב- Google Cloud? אנחנו ממליצים לכם ליצור חשבון, להתנסות בעצמכם במוצרים שלנו ולבחון אותם באמצעות תרחישים ממשיים. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.
מתחילים לעבוד בלי לשלם