חשבונות השירות

בדף הזה מוסבר איך חשבונות שירות פועלים עם Compute Engine.

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

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

נסו בעצמכם

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

אני רוצה לנסות את Compute Engine בחינם

מה זה חשבון שירות?

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

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

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

איך Compute Engine משתמש בחשבונות שירות

ב-Compute Engine נעשה שימוש בשני סוגים של חשבונות שירות:

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

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

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

איך נקבעת ההרשאה

ההרשאה שניתנת לאפליקציות שמארחות במכונה של Compute Engine מוגבלת על ידי שתי הגדרות נפרדות: התפקידים שמוקצים לחשבון השירות המצורף והיקפי הגישה שמוגדרים במכונה. שתי ההגדרות האלה צריכות לאפשר גישה כדי שהאפליקציה שפועלת במופע תוכל לגשת למשאב.

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

חשבונות שירות בניהול המשתמשים

חשבונות שירות בניהול המשתמשים כוללים חשבונות שירות חדשים שאתם יוצרים באופן מפורש וחשבון שירות שמוגדר כברירת מחדל ב-Compute Engine.

חשבונות שירות חדשים

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

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

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

בפרויקטים חדשים שבהם הופעל Compute Engine API, יש חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine, עם כתובת האימייל הבאה:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

לחשבון השירות של Compute Engine שמוגדר כברירת מחדל יש את המאפיינים הבאים:

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

  • בהתאם להגדרות של מדיניות הארגון, יכול להיות שחשבון השירות שמוגדר כברירת מחדל יקבל אוטומטית את התפקיד 'עריכה' בפרויקט. אנחנו ממליצים מאוד להשבית את הענקת התפקיד האוטומטית על ידי החלת האילוץ iam.automaticIamGrantsForDefaultServiceAccounts של מדיניות הארגון. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.

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

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

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

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

סוכני שירות

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

אי אפשר לצרף סוכני שירות למכונה של Compute Engine.

סוכן שירות של Google APIs

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

PROJECT_NUMBER@cloudservices.gserviceaccount.com

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

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

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

סוכן שירות של Compute Engine

בכל הפרויקטים שבהם מופעל Compute Engine API יש סוכן שירות של Compute Engine, עם כתובת האימייל הבאה:

service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com

סוכן השירות הזה מיועד ספציפית ל-Compute Engine כדי לבצע את משימות השירות בפרויקט שלכם. היא מסתמכת על מדיניות IAM של סוכן השירות שניתנה בGoogle Cloud פרויקט. זה גם סוכן השירות ש-Compute Engine משתמש בו כדי לגשת לחשבון השירות בניהול המשתמשים במכונות וירטואליות. ‫Google היא הבעלים של החשבון הזה, אבל הוא ספציפי לפרויקט שלכם. סוכן השירות הזה מוסתר בדף IAM במסוף, אלא אם מסמנים את התיבה Include Google-provided role grants. כברירת מחדל, סוכן השירות הזה מקבל אוטומטית את התפקיד compute.serviceAgent בפרויקט.

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

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

צירוף חשבון שירות למופע

כדי להימנע מהענקת הרשאות עודפות לאפליקציה, מומלץ ליצור חשבון שירות שמנוהל על ידי המשתמש, להעניק לו רק את התפקידים שהאפליקציה צריכה כדי לפעול בצורה תקינה ולצרף אותו למופע Compute Engine. אחרי כן, הקוד יכול להשתמש בApplication Default Credentials כדי לבצע אימות באמצעות פרטי הכניסה שסופקו על ידי חשבון השירות.

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

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

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

הרשאה

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

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

השיטה המומלצת היא להגדיר את היקף הגישה המלא cloud-platform במופע, ואז לשלוט בגישה לחשבון השירות באמצעות תפקידי IAM.

בעיקרון:

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

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

תפקידי IAM

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

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

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

כמה דברים שכדאי לזכור:

  • חלק מתפקידי ה-IAM נמצאים בגרסת בטא.

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

  • כדי לאשר גישה, צריך להגדיר את היקפי הגישה במופע.

    רמת הגישה של חשבון שירות נקבעת לפי התפקידים שהוקצו לו, אבל היקפי הגישה של מופע קובעים את היקפי ברירת המחדל של OAuth לבקשות שמוגשות דרך ה-CLI של gcloud וספריות הלקוח במופע. כתוצאה מכך, היקפי הגישה עשויים להגביל עוד יותר את הגישה לשיטות API כשמבצעים אימות באמצעות OAuth.

היקפי גישה

היקפי גישה הם השיטה הקודמת להגדרת הרשאה למופע של מכונה וירטואלית. הם מגדירים את היקפי ההרשאות של OAuth שמוגדרים כברירת מחדל ומשמשים בבקשות מה-CLI של gcloud או מספריות הלקוח. היקפי הגישה לא חלים על שיחות שמבוצעות באמצעות gRPC.

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

בדרך כלל, במסמכי העזרה של כל method ב-API מפורטים היקפי ההרשאות שנדרשים לשיטה הזו. לדוגמה, השיטה instances.insert מספקת רשימה של היקפי הרשאות תקפים בקטע authorization שלה.

להיקפי הגישה אין השפעה אם לא הפעלתם את ה-API שקשור לפרויקט שאליו משויך חשבון השירות. לדוגמה, אם מעניקים היקף גישה ל-Cloud Storage במכונה וירטואלית, המכונה יכולה לקרוא ל-Cloud Storage API רק אם הפעלתם את Cloud Storage API בפרויקט.

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

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

  • גישת קריאה בלבד ל-Cloud Storage:
    https://www.googleapis.com/auth/devstorage.read_only
  • הרשאת כתיבה ליומנים של Compute Engine:
    https://www.googleapis.com/auth/logging.write
  • הרשאת כתיבה לפרסום נתוני מדדים בפרויקטים שלכם ב- Google Cloud :
    https://www.googleapis.com/auth/monitoring.write
  • גישת קריאה בלבד לתכונות של Service Management שנדרשות ל Google Cloud Endpoints(אלפא):
    https://www.googleapis.com/auth/service.management.readonly
  • נדרשת גישת קריאה או כתיבה לתכונות של Service Control API עבור Google Cloud Endpoints(אלפא):
    https://www.googleapis.com/auth/servicecontrol
  • הרשאת כתיבה ל-Cloud Trace מאפשרת לאפליקציה שפועלת במכונה וירטואלית לכתוב נתוני מעקב בפרויקט.
    https://www.googleapis.com/auth/trace.append

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

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

https://www.googleapis.com/auth/cloud-platform

דוגמאות להיקפים

אם הפעלתם את היקף הגישה cloud-platform במופע ואז הקציתם את תפקידי ה-IAM המוגדרים מראש הבאים, מומלץ לפעול לפי השיטה המומלצת בנושא היקפי גישה:

  • roles/compute.instanceAdmin.v1
  • roles/storage.objectViewer
  • roles/compute.networkAdmin

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

לעומת זאת, אם תגדירו היקף מוגבל יותר במכונה, כמו היקף הקריאה בלבד של Cloud Storage‏ (https://www.googleapis.com/auth/devstorage.read_only), ותקצו לחשבון השירות את תפקיד האדמין roles/storage.objectAdmin, כברירת מחדל, בקשות מ-ה-CLI של gcloud ומספריות הלקוח לא יוכלו לנהל אובייקטים של Cloud Storage מהמכונה הזו, גם אם הקציתם לחשבון השירות את התפקיד roles/storage.ObjectAdmin. הסיבה לכך היא שהיקף הקריאה בלבד של Cloud Storage לא מאשר למופע לבצע מניפולציה של נתונים ב-Cloud Storage.

דוגמאות להיקפי גישה:

  • https://www.googleapis.com/auth/cloud-platform. הצגה וניהול של הנתונים Google Cloud בשירותים בפרויקטGoogle Cloud שצוין.
  • ‫https://www.googleapis.com/auth/compute. גישת שליטה מלאה לשיטות של Compute Engine.
  • https://www.googleapis.com/auth/compute.readonly. הרשאת קריאה בלבד לשיטות של Compute Engine.
  • ‫https://www.googleapis.com/auth/devstorage.read_only. גישת קריאה בלבד ל-Cloud Storage.
  • ‫https://www.googleapis.com/auth/logging.write. הרשאת כתיבה ליומנים של Compute Engine.

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