כשמוסיפים חבר חדש לפרויקט, אפשר להשתמש במדיניות ניהול הזהויות והרשאות הגישה (IAM) כדי להקצות לחבר הזה תפקיד IAM אחד או יותר. כל תפקיד IAM מכיל הרשאות שמעניקות לחברים גישה למשאבים ספציפיים.
ל-Compute Engine יש קבוצה של תפקידי IAM מוגדרים מראש שמתוארים בדף הזה. אפשר גם ליצור תפקידים בהתאמה אישית שכוללים קבוצות משנה של הרשאות שמתאימות בדיוק לצרכים שלכם.
כדי לדעת אילו הרשאות נדרשות לכל method, אפשר לעיין במסמכי העזר של Compute Engine API:
מידע על מתן גישה מופיע בדפים הבאים.
- כדי להגדיר מדיניות IAM ברמת הפרויקט, אפשר לעיין במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים במסמכי העזרה של IAM.
- כדי להגדיר מדיניות במשאבים ספציפיים של Compute Engine, אפשר לקרוא את המאמר בנושא הענקת גישה למשאבי Compute Engine.
- כדי להקצות תפקידים לחשבון שירות של Compute Engine, קראו את המאמר בנושא יצירת VM שמשתמשת בחשבון שירות שמנוהל על ידי משתמש.
מה זה IAM?
Google Cloud כולל את הממשק לניהול הזהויות והרשאות הגישה (IAM), שבאמצעותו אתם יכולים לתת גישה פרטנית יותר למשאבים ספציפיים ב-Google Cloud ולמנוע גישה לא רצויה למשאבים אחרים. בעזרת IAM אתם יכולים לשמור על עקרון האבטחה של הרשאות מינימליות, וכך לתת למי שצריך רק את רמת הגישה הדרושה למשאבים השונים.
בעזרת IAM תוכלו לקבוע למי (זהות) יש אילו (תפקידים) הרשאות גישה לאילו משאבים, על ידי הגדרה של כללי מדיניות ב-IAM. כללי המדיניות ב-IAM מקצים תפקידים ספציפיים לחברי פרויקט, וכך נותנים לזהות הזו הרשאות מסוימות. לדוגמה, עבור משאב נתון, כמו פרויקט, תוכלו להקצות את התפקיד 'אדמין של רשת Compute' (roles/compute.networkAdmin) לחשבון משתמש (חשבון Google או חשבון מספק זהויות חיצוני) וחשבון זה יוכל לשלוט במשאבים שקשורים לרשת בפרויקט, אבל לא יוכל לנהל משאבים אחרים, כמו מופעים ודיסקים. אפשר גם להשתמש ב-IAM כדי לנהל את התפקידים מהדור הקודם במסוףGoogle Cloud שניתנו לחברי צוות הפרויקט.
התפקיד serviceAccountUser
בשילוב עם התפקיד 'אדמין מכונות של Compute (v1)' (roles/compute.instanceAdmin.v1), התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) מאפשר לחברים ליצור ולנהל מכונות שמשתמשות בחשבון שירות. בפרט, הענקת ההרשאות roles/iam.serviceAccountUser ו-roles/compute.instanceAdmin.v1 יחד מאפשרת לחברים בקבוצה לבצע את הפעולות הבאות:
- יוצרים מכונה שפועלת בתור חשבון שירות.
- צירוף אחסון מתמיד (persistent disk) למכונה שפועלת כחשבון שירות.
- הגדרת מטא-נתונים של מכונה במכונה שפועלת כחשבון שירות.
- משתמשים ב-SSH כדי להתחבר למכונה שפועלת כחשבון שירות.
- מגדירים מחדש מכונה כך שתפעל כחשבון שירות.
אפשר להעניק את התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) באחת משתי דרכים:
מומלץ. מקצים את התפקיד לחבר בחשבון שירות ספציפי. כך חבר מקבל גישה לחשבון השירות שבו הוא מוגדר כ
iam.serviceAccountUser, אבל לא מקבל גישה לחשבונות שירות אחרים שבהם הוא לא מוגדר כiam.serviceAccountUser.נותנים את התפקיד לחבר ברמת הפרויקט. לחבר יש גישה לכל חשבונות השירות בפרויקט, כולל חשבונות שירות שייווצרו בעתיד.
אם אתם לא מכירים חשבונות שירות, כאן אפשר לקרוא מידע נוסף על חשבונות שירות.
הרשאה במסוףGoogle Cloud
כדי להשתמש ב Google Cloud console כדי לגשת למשאבי Compute Engine, צריך להיות לכם תפקיד שכולל את ההרשאה הבאה בפרויקט:
compute.projects.get
התחברות למופע בתור instanceAdmin
אחרי שמקצים לחבר בפרויקט את התפקיד roles/compute.instanceAdmin.v1, הוא יכול להתחבר למכונות וירטואליות (VM) באמצעות כלים סטנדרטיים כמו ה-CLI של gcloud או SSH בדפדפן. Google Cloud
כשחבר משתמש ב-CLI של gcloud או ב-SSH בדפדפן, הכלים יוצרים באופן אוטומטי זוג מפתחות ציבורי/פרטי ומוסיפים את המפתח הציבורי למטא-נתונים של הפרויקט. אם לחבר אין הרשאות לערוך את המטא-נתונים של הפרויקט, הכלי מוסיף את המפתח הציבורי של החבר למטא-נתונים של המופע במקום.
אם לחבר יש זוג מפתחות קיים שהוא רוצה להשתמש בו, הוא יכול להוסיף ידנית את המפתח הציבורי שלו למטא-נתונים של המופע. מידע נוסף על הוספת מפתחות SSH למכונה
IAM עם חשבונות שירות
יצירת חשבונות שירות חדשים בהתאמה אישית והענקת תפקידי IAM לחשבונות שירות כדי להגביל את הגישה למופעים. משתמשים בתפקידי IAM עם חשבונות שירות בהתאמה אישית כדי:
- כדאי להגביל את הגישה של המכונות לממשקי API באמצעות תפקידי IAM עם הרשאות גרנולריות. Google Cloud
- נותנים לכל מופע או קבוצת מופעים זהות ייחודית.
- הגבל את הגישה של חשבון השירות שמוגדר כברירת מחדל.
קבוצות של מופעי מכונה מנוהלים ו-IAM
קבוצות מנוהלות של מופעים (MIG) הן משאבים שמבצעים פעולות בשמכם בלי אינטראקציה ישירה עם המשתמש. לדוגמה, קבוצת ה-MIG יכולה להוסיף מכונות וירטואליות לקבוצה ולהסיר אותן ממנה.
כל הפעולות שמבוצעות על ידי Compute Engine כחלק מ-MIG מבוצעות על ידי סוכן שירות של Google APIs עבור הפרויקט שלכם, שיש לו כתובת אימייל כמו זו שבהמשך:
PROJECT_ID@cloudservices.gserviceaccount.com
כברירת מחדל, סוכן השירות של Google APIs מקבל את התפקיד 'סוכן שירות של Instance Group Manager' (roles/compute.instanceGroupManagerServiceAgent) ברמת הפרויקט, שמעניק לו מספיק הרשאות כדי ליצור משאבים על סמך ההגדרה של MIG. אם אתם מתאימים אישית את הגישה לסוכן השירות של Google APIs, העניקו את התפקיד 'אדמין מכונות של Compute' (v1) (roles/compute.instanceAdmin.v1) ואת התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) (אופציונלי). התפקיד 'משתמש בחשבון שירות' נדרש רק אם ה-MIG יוצר מכונות וירטואליות שיכולות לפעול כחשבון שירות.
שימו לב: סוכן השירות של Google APIs משמש גם תהליכים אחרים, כולל Deployment Manager.
כשיוצרים קבוצת מופעים מנוהלת או מעדכנים את תבנית של הגדרות מכונה שלה, Compute Engine מוודא שלסוכן שירות של Google APIs יש את התפקיד וההרשאות הבאים:
- התפקיד 'משתמש בחשבון שירות', שחשוב אם אתם מתכננים ליצור מכונות שיכולות לפעול כחשבון שירות
- הרשאות לכל המשאבים שמפנים אליהם מתבניות של מכונות, כמו תמונות, דיסקים, רשתות VPC ורשתות משנה
תפקידי IAM מוגדרים מראש ב-Compute Engine
באמצעות IAM, כל method ב-Compute Engine API דורשת שלזהות שממנה הגיעה בקשת ה-API יהיו ההרשאות המתאימות לשימוש במשאב. ההרשאות ניתנות על ידי הגדרת כללי מדיניות שמעניקים תפקידים לחברים (משתמשים, קבוצות או חשבונות שירות) בפרויקט.
בנוסף לתפקידים הבסיסיים (צפייה, עריכה, בעלים) ולתפקידים בהתאמה אישית, אפשר להקצות לחברי הפרויקט את התפקידים המוגדרים מראש הבאים ב-Compute Engine.
אתם יכולים להקצות לחברי פרויקט כמה תפקידים באותו משאב. לדוגמה, אם צוות הרשתות שלכם מנהל גם את כללי חומת האש, אתם יכולים להעניק את התפקידים roles/compute.networkAdmin ו-roles/compute.securityAdmin לקבוצת Google של צוות הרשתות.
בטבלאות הבאות מתוארים תפקידי IAM מוגדרים מראש ב-Compute Engine, ופירוט של ההרשאות שכלולות בכל תפקיד. כל תפקיד מכיל קבוצה של הרשאות שמתאימות למשימה ספציפית. לדוגמה, התפקידים 'אדמין של מופע' מעניקים הרשאות לניהול מופעים, התפקידים שקשורים לרשת כוללים הרשאות לניהול משאבים שקשורים לרשת, והתפקיד 'אבטחה' כולל הרשאות לניהול משאבים שקשורים לאבטחה, כמו חומות אש ואישורי SSL. כשעובדים ב-Compute Engine, יכול להיות שצריך גם תפקידים בשירותים אחרים כמו Cloud DNS וחשבונות שירות של IAM. רשימה מלאה של תפקידי IAM זמינה במאמר מאמרי העזרה בנושא תפקידי IAM.
| Role | Permissions |
|---|---|
Compute Admin( Full control of all Compute Engine resources.
If the user will be managing virtual machine instances that are configured
to run as a service account, you must also grant the
Lowest-level resources where you can grant this role:
|
|
Compute Future Reservation Admin Beta(
|
|
Compute Future Reservation User Beta(
|
|
Compute Future Reservation Viewer Beta(
|
|
Compute Image User( Permission to list and read images without having other permissions on the image. Granting this role at the project level gives users the ability to list all images in the project and create resources, such as instances and persistent disks, based on images in the project. Lowest-level resources where you can grant this role:
|
|
Compute Instance Admin (beta)( Permissions to create, modify, and delete virtual machine instances. This includes permissions to create, modify, and delete disks, and also to configure Shielded VM settings.
If the user will be managing virtual machine instances that are configured
to run as a service account, you must also grant the
For example, if your company has someone who manages groups of virtual machine instances but does not manage network or security settings and does not manage instances that run as service accounts, you can grant this role on the organization, folder, or project that contains the instances, or you can grant it on individual instances. Lowest-level resources where you can grant this role:
|
|
Compute Instance Admin (v1)( Full control of Compute Engine instances, instance groups, disks, snapshots, and images. Read access to all Compute Engine networking resources. If you grant a user this role only at an instance level, then that user cannot create new instances. |
|
Instance Group Manager Service Agent( Role containing all permissions required by Managed Instance Groups to create and manage instances. |
|
Interconnect Attachment Group Analyzer( Analyze Interconnect Attachment Groups via their GetOperationalStatus method. |
|
Interconnect Group Analyzer( Analyze Interconnect Groups via their GetOperationalStatus method. |
|
Compute Load Balancer Admin( Permissions to create, modify, and delete load balancers and associate resources. For example, if your company has a load balancing team that manages load balancers, SSL certificates for load balancers, SSL policies, and other load balancing resources, and a separate networking team that manages the rest of the networking resources, then grant this role to the load balancing team's group. Lowest-level resources where you can grant this role:
|
|
Compute Load Balancer Services User( Permissions to use services from a load balancer in other projects. |
|
Compute Network Admin( Permissions to create, modify, and delete networking resources, except for firewall rules and SSL certificates. The network admin role allows read-only access to firewall rules, SSL certificates, and instances (to view their ephemeral IP addresses). The network admin role does not allow a user to create, start, stop, or delete instances.
For example, if your company has a security team that manages firewalls
and SSL certificates and a networking team that manages the rest of the
networking resources, then grant this role to the networking team's group.
Or, if you have a combined team that manages both security and networking,
then grant this role as well as the
Lowest-level resources where you can grant this role:
|
|
Compute Network User( Provides access to a shared VPC network Once granted, service owners can use VPC networks and subnets that belong to the host project. For example, a network user can create a VM instance that belongs to a host project network but they cannot delete or create new networks in the host project. Lowest-level resources where you can grant this role:
|
|
Compute Network Viewer( Read-only access to all networking resources For example, if you have software that inspects your network configuration, you could grant this role to that software's service account. Lowest-level resources where you can grant this role:
|
|
Compute Organization Firewall Policy Admin( Full control of Compute Engine Organization Firewall Policies. |
|
Compute Organization Firewall Policy User( View or use Compute Engine Firewall Policies to associate with the organization or folders. |
|
Compute Organization Security Policy Admin( Full control of Compute Engine Organization Security Policies. |
|
Compute Organization Security Policy User( View or use Compute Engine Security Policies to associate with the organization or folders. |
|
Compute Organization Resource Admin( Full control of Compute Engine Firewall Policy associations to the organization or folders. |
|
Compute OS Admin Login( Access to log in to a Compute Engine instance as an administrator user. Lowest-level resources where you can grant this role:
|
|
Compute OS Login( Access to log in to a Compute Engine instance as a standard user. Lowest-level resources where you can grant this role:
|
|
Compute OS Login External User( Available only at the organization level. Access for an external user to set OS Login information associated with this organization. This role does not grant access to instances. External users must be granted one of the required OS Login roles in order to allow access to instances using SSH. Lowest-level resources where you can grant this role:
|
|
Compute packet mirroring admin( Specify resources to be mirrored. |
|
Compute packet mirroring user( Use Compute Engine packet mirrorings. |
|
Compute Peer Subnet Migration Admin( Use subnetwork whose PURPOSE is "PEER_MIGRATION" |
|
Compute Public IP Admin( Full control of public IP address management for Compute Engine. |
|
Compute Security Admin( Permissions to create, modify, and delete firewall rules and SSL certificates, and also to configure Shielded VM settings. For example, if your company has a security team that manages firewalls and SSL certificates and a networking team that manages the rest of the networking resources, then grant this role to the security team's group. Lowest-level resources where you can grant this role:
|
|
Compute Engine Service Agent( Gives Compute Engine Service Account access to assert service account authority. Includes access to service accounts. |
|
Compute Sole Tenant Viewer( Permissions to view sole tenancy node groups |
|
Compute Storage Admin( Permissions to create, modify, and delete disks, images, and snapshots. For example, if your company has someone who manages project images and you don't want them to have the editor role on the project, then grant this role to their account on the project. Lowest-level resources where you can grant this role:
|
|
Compute Viewer( Read-only access to get and list Compute Engine resources, without being able to read the data stored on them. For example, an account with this role could inventory all of the disks in a project, but it could not read any of the data on those disks. Lowest-level resources where you can grant this role:
|
|
Compute VM extension policy admin Beta( Administer zone/global VM extension policies. |
|
Compute VM extension policy viewer Beta( View zone/global VM extension policies. |
|
Compute Shared VPC Admin( Permissions to administer shared VPC host projects, specifically enabling the host projects and associating shared VPC service projects to the host project's network. At the organization level, this role can only be granted by an organization admin.
Google Cloud recommends that the Shared VPC Admin be the owner of the shared VPC host project. The
Shared VPC Admin is responsible for granting the Compute Network User role
( Lowest-level resources where you can grant this role:
|
|
המאמרים הבאים
- מידע נוסף על IAM
- יצירה וניהול של תפקידי IAM בהתאמה אישית
- הענקת תפקידי IAM למשתמשי הפרויקט
- הענקת תפקידי IAM למשאבים ספציפיים ב-Compute Engine
- הקצאת תפקידים ב-IAM לחשבונות שירות