סקירה כללית על בקרת גישה

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

במאמר איך נקבעת ההרשאה מוסבר איך לתת גישה לאפליקציות שפועלות במכונות של Compute Engine.

אפשרויות בקרת גישה למשתמשים

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

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

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

תפקידים מוגדרים מראש ב-Compute Engine

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

שם התפקיד	יכולות	משתמש היעד
משתמש בתמונה של Compute Engine	הרשאה להציג תמונות מפרויקט אחר ולהשתמש בהן. כדאי להקצות לחבר תפקיד כזה יחד עם תפקיד אחר, כדי שהוא יוכל להשתמש בתמונות מפרויקט אחר כדי ליצור משאב חדש. לדוגמה, אפשר להעניק את התפקיד הזה ואת התפקיד 'אדמין של מכונות וירטואליות' כדי שחבר יוכל להשתמש בתמונות מפרויקט אחר כדי ליצור מכונות וירטואליות ודיסקים קשיחים. אם אתם יוצרים קבוצות של מכונות וירטואליות מנוהלות או משתמשים ב-Deployment Manager כדי ליצור מכונות וירטואליות, יכול להיות שתצטרכו להקצות את התפקיד הזה לחשבון השירות של Google APIs בפרויקט לפני שתוכלו להשתמש בתמונות מפרויקטים אחרים.	חשבונות שירות אדמינים מפתחים
אדמין מכונות של Compute Engine (גרסה 1)	שליטה מלאה במכונות, קבוצות של מכונות, שטחי אחסון, קובצי snapshot ותמונות ב-Compute Engine. הרשאת קריאה בלבד לכל משאבי הרשת של Compute Engine. אם חבר הקבוצה מנהל מכונות וירטואליות שמסודרות להרצה כחשבון שירות, צריך גם להקצות לו את התפקיד `roles/iam.serviceAccountUser` כדי שיוכל להקצות חשבונות שירות למכונות וירטואליות.	אדמינים מפתחים
תפקיד אדמין ב-Compute Engine	גישה מלאה לכל המשאבים של Compute Engine. אם המשתמש מנהל מכונות וירטואליות שמוגדרות לפעול כחשבון שירות, צריך להעניק לו גם את התפקיד `roles/iam.serviceAccountUser`.	אדמינים מפתחים
אדמין של רשת מחשוב ב-Compute Engine	הרשאות ליצור, לשנות ולמחוק משאבי רשת, למעט כללי חומת אש ואישורי SSL. התפקיד 'אדמין רשתות' מאפשר גישה לקריאה בלבד לכללי חומת אש, לאישורי SSL ולמכונות (כדי להציג את כתובות ה-IP הזמניות שלהן). התפקיד 'אדמין ברשת' לא מאפשר לחברים ליצור, להתחיל, לעצור או למחוק מופעים.	אדמינים של רשתות
אדמין אבטחה של Compute Engine	הרשאות ליצור, לשנות ולמחוק כללי חומת אש ואישורי SSL.	אדמינים לענייני אבטחה
אדמין של מאזן עומסים ב-Compute Engine^בטא	הרשאות ליצירה, לשינוי ולמחיקה של מאזני עומסים ומשאבים משויכים.	אדמינים של מאזן עומסים
משתמש בחשבון שירות של Compute Engine	הרשאה ליצור מכונות שמשתמשות בחשבונות שירות, והרשאה לצרף דיסק ולהגדיר מטא-נתונים במכונה שכבר הוגדרה לפעול כחשבון שירות. לא מומלץ להעניק את התפקיד הזה לבדו, כי הוא לא מספק הרשאות ל-API של Compute Engine. כדאי להקצות לחבר את התפקיד הזה ועוד תפקיד, כמו התפקיד 'אדמין של מכונה וירטואלית'.	אדמינים מפתחים
תפקיד הצופה ב-Compute Engine	הרשאת קריאה בלבד כדי לקבל ולרשום משאבי Compute Engine, בלי אפשרות לקרוא את הנתונים שמאוחסנים בהם. לדוגמה, חשבון עם התפקיד הזה יכול לבצע מלאי של כל הדיסקים בפרויקט, אבל הוא לא יכול לקרוא אף אחד מהנתונים בדיסקים האלה.	אדמינים
משתמש רשת ב-Compute Engine	הרשאות לשימוש ברשת VPC משותפת. בפרט, כדאי להקצות את התפקיד הזה לבעלי שירותים שצריכים להשתמש במשאבים בפרויקט המארח. אחרי שמוענקות הרשאות, בעלי השירות יכולים להשתמש ברשתות משנה וברשתות ששייכות לפרויקט המארח. לדוגמה, משתמש ברשת יכול ליצור מכונה וירטואלית ששייכת לרשת מארחת של VPC משותף, אבל הוא לא יכול למחוק או ליצור רשתות חדשות בפרויקט המארח.	אדמינים מפתחים
כלי להצגת רשתות ב-Compute Engine	הרשאת קריאה בלבד לכל משאבי הרשת. לדוגמה, אם יש לכם תוכנה שבודקת את הגדרות הרשת, אתם יכולים לתת לחשבון השירות של התוכנה את התפקיד 'צפייה ברשת'.	אדמינים של רשתות אדמינים מפתחים חשבונות שירות
אדמין אחסון ב-Compute Engine^בטא	הרשאות ליצירה, לשינוי ולמחיקה של דיסקים, תמונות וקובצי snapshot. לדוגמה, אם בחברה שלכם יש מישהו שמנהל תמונות ואתם לא רוצים שהוא יקבל את תפקיד העריכה בפרויקט, אתם יכולים להעניק לחשבון שלו את התפקיד הזה.	אדמינים מפתחים
אדמין של VPC משותף ב-Compute Engine	הרשאות לניהול פרויקטים מארחים ב-VPC משותף, ובפרט הרשאות להפעלת הפרויקטים המארחים ולשיוך פרויקטים של שירות לרשת של הפרויקט המארח. אפשר לתת את התפקיד הזה רק ברמת הארגון.	יוצרי פרויקטים

כדי לראות רשימה של רכיבי API שמוענקת להם הרשאה על ידי תפקיד ספציפי, אפשר לעיין במסמכי התיעוד בנושא תפקידים ב-IAM של Compute Engine.

מטריצה של תפקידים מוגדרים מראש

בטבלה הבאה מוצגת השוואה מלאה בין היכולות של כל תפקיד ב-Compute Engine.

יכולת	אדמין מכונות (גרסה 1)	אדמין של Compute	אדמין של מאזן עומסים
יצירה או מחיקה של מכונות וירטואליות	^*
התחברות למכונות וירטואליות באמצעות SSH	^*	^*
רשימה או קבלת מכונות וירטואליות
יצירה או מחיקה של תמונות, דיסקים ותמונות מצב
הצגת רשימה או קבלת תמונות
יצירה או מחיקה של קבוצות מכונות	^*
הצגת רשימה של קבוצות מופעים או קבלת קבוצות מופעים
יצירה וניהול של מאזני עומסים
יצירה וניהול של רשתות VPN
הצגת משאבים ברשת או ברשת משנה
צפייה בכללים של חומת האש
יצירה וניהול של חומות אש ואישורי SSL			‫ לחומות אש, ‫ לאישורי SSL
יצירה וניהול של פרויקטים מארחים ב-VPC משותף
שימוש ברשתות ובתת-רשתות בפרויקט מארח של VPC משותף
יצירה וניהול של רשתות ורשתות משנה

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

תפקידים בסיסיים ב-IAM

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

שם התפקיד	הרשאות
`Owner`	כל ההרשאות של הצופים והעורכים, בנוסף לאפשרות לשנות את הגדרות החיוב, לנהל את בקרת הגישה ולמחוק פרויקט.
`Editor`	כל ההרשאות של Viewer, וגם היכולת ליצור, לשנות ולמחוק משאבים.
`Viewer`	הרשאות קריאה בלבד לכל המשאבים; אין הרשאה לשנות משאבים.

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

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

מדיניות IAM למשאבי Compute Engine

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

בעזרת מדיניות IAM למשאבי Compute Engine, ארגונים יכולים:

הענקת גישה למשתמשים לקבוצת משנה ספציפית של משאבים. נניח שמשתמשת בשם אליס צריכה לנהל קבוצת משנה של מופעים בפרויקט. בעזרת כללי מדיניות IAM ברמת המופע, תוכלו להעניק לה את התפקיד compute.instanceAdmin.v1 רק במופעים האלה. אם הייתם מקצים לאליס את אותו תפקיד בפרויקט, היא הייתה מקבלת הרשאה לשנות את כל המופעים בפרויקט.
אישור לאדמינים להעניק גישה. אדמינים יכולים להעניק לאנשים אחרים גישה למופעים, לדיסקים ולתמונות בלי שהם יהיו בעלי פרויקטים עם הרשאות נרחבות. נניח שדני הוא מפתח שקיבל את התפקיד compute.storageAdmin בתמונה ספציפית. הוא יכול לשתף את התמונה עם חברי הצוות שלו על ידי הקצאת התפקיד compute.imageUser בתמונה. בלי מדיניות IAM למשאבי Compute Engine, בוב לא יכול לשתף את התמונה עם חברי הצוות שלו אלא אם הוא הופך לבעלים של הפרויקט, כי הוא יצטרך לשנות את מדיניות ה-IAM של הפרויקט.

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

מדיניות הארגון

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

ארגון יכול להטמיע מדיניות ארגונית, שהיא מדיניות שמגבילה את התצורות המותרות בכלGoogle Cloud היררכיית המשאבים. ב-Compute Engine, אפשר להטמיע את כללי המדיניות הבאים:

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

מידע נוסף על ארגונים זמין במאמרי העזרה בנושא ארגונים.

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

הענקת גישת SSH למשתמשים למופעי VM

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

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

שימו לב: אם תעניקו את התפקיד roles/compute.instanceAdmin.v1 לחבר בפרויקט, הוא יוכל להתחבר באופן אוטומטי למופעים באמצעות SSH, כל עוד המופע לא מוגדר לפעול כחשבון שירות. אם המופע מוגדר לפעול כחשבון שירות, צריך גם להקצות את התפקיד roles/iam.serviceAccountUser לפני שהחבר יוכל להתחבר למופע.

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

בקרת גישה לאפליקציות שפועלות במכונות VM

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

מידע נוסף על חשבונות שירות זמין במאמרי עזרה חשבונות שירות.

זהויות מנוהלות של עומסי עבודה לעומסי עבודה ב-Compute Engine

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

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

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

מידע על הגדרת זהויות מנוהלות לעומסי עבודה זמין במאמר אימות עומסי עבודה לעומסי עבודה אחרים באמצעות mTLS.