When you add a new member to your project, you can use an Identity and Access Management (IAM) policy to give that member one or more IAM roles. Each IAM role contains permissions that grant the member access to specific resources.
Compute Engine has a set of predefined IAM roles that are described on this page. You can also create custom roles that contain subsets of permissions that map directly to your needs.
To learn which permissions are required for each method, see the Compute Engine API reference documentation:
For information about granting access, see the following pages.
- To set IAM policies at a project level, see Granting, changing, and revoking access to resources in the IAM documentation.
- To set policies on specific Compute Engine resources, read Granting access to Compute Engine resources.
- To assign roles to a Compute Engine service account, read Creating and enabling service accounts for instances.
Before you begin
- Read the IAM documentation.
What is IAM?
Google Cloud offers IAM, which lets you give more granular access to specific Google Cloud resources and prevents unwanted access to other resources. IAM lets you adopt the security principle of least privilege, so you grant only the necessary access to your resources.
IAM lets you control who (identity) has
what (roles) permission to which resources by setting
IAM policies. IAM policies grant specific role(s)
to a project member, giving that identity certain permissions. For example, for
a given resource, such as a project, you can assign the
roles/compute.networkAdmin role to a Google Account
and that account can control network-related resources in the project, but
cannot manage other resources, like instances and disks. You can also use
IAM to manage the
Google Cloud console legacy roles
granted to project team members.
The serviceAccountUser role
When granted together with
roles/compute.instanceAdmin.v1,
roles/iam.serviceAccountUser gives members the
ability to create and manage instances that use a service account. Specifically,
granting roles/iam.serviceAccountUser and roles/compute.instanceAdmin.v1
together gives members permission to:
- Create an instance that runs as a service account.
- Attach a persistent disk to an instance that runs as a service account.
- Set instance metadata on an instance that runs as a service account.
- Use SSH to connect to an instance that runs as a service account.
- Reconfigure an instance to run as a service account.
You can grant roles/iam.serviceAccountUser one of two ways:
Recommended. Grant the role to a member on a specific service account. This gives a member access to the service account for which they are an
iam.serviceAccountUserbut prevents access to other service accounts for which the member is not aniam.serviceAccountUser.Grant the role to a member on the project level. The member has access to all service accounts in the project, including service accounts that are created in the future.
If you aren't familiar with service accounts, learn more about service accounts.
Google Cloud Console permission
To use the Google Cloud console to access Compute Engine resources, you must have a role that contains the following permission on the project:
compute.projects.get
Connecting to an instance as an instanceAdmin
After you grant a project member the roles/compute.instanceAdmin.v1 role, they
can connect to virtual machine (VM) instances by using standard Google Cloud
tools, like the gcloud CLI or
SSH-in-browser.
When a member uses the gcloud CLI or SSH-in-browser, the tools automatically generate a public/private key pair and add the public key to the project metadata. If the member does not have permissions to edit project metadata, the tool adds the member's public key to the instance metadata instead.
If the member has an existing key pair they want to use, they can manually add their public key to the instance's metadata. Learn more about adding SSH keys to an instance.
IAM with service accounts
Create new custom service accounts and grant IAM roles to service accounts to limit the access of your instances. Use IAM roles with custom service accounts to:
- Limit the access your instances have to Google Cloud APIs using granular IAM roles.
- Give each instance, or set of instances, a unique identity.
- Limit the access of your default service account.
Learn more about service accounts.
Managed instance groups and IAM
Managed instance groups (MIGs) are resources that perform actions on your behalf without direct user interaction. For example, the MIG can add and remove VMs from the group.
All of the operations performed by Compute Engine as part of the MIG are
performed by the
Google APIs Service Agent
for your project, which has an email address like the following:
PROJECT_ID@cloudservices.gserviceaccount.com
By default, the Google APIs Service Agent is granted the
Editor role (roles/editor) at the project level, which gives enough privileges
to create resources based on the MIG's configuration. If you're customizing
access for the Google APIs Service Agent, then grant the Compute Instance Admin (v1) role
(roles/compute.instanceAdmin.v1) and, optionally, the Service Account User role
(roles/iam.serviceAccountUser). The Service Account User role is required
only if the MIG creates VMs that can run as a service account.
Note that the Google APIs Service Agent is also used by other processes, including Deployment Manager.
When you create a MIG or update its instance template, Compute Engine validates that the Google APIs Service Agent has the following role and permissions:
- Service Account User role, which is important if you plan to create instances that can run as a service account
- Permissions to all the resources referenced from instance templates, such as images, disks, VPC networks, and subnets
Predefined Compute Engine IAM roles
With IAM, every API method in Compute Engine API requires that the identity making the API request has the appropriate permissions to use the resource. Permissions are granted by setting policies that grant roles to a member (user, group, or service account) of your project.
In addition to basic roles (viewer, editor, owner) and custom roles, you can assign the following Compute Engine predefined roles to the members of your project.
You can grant multiple roles to a project member on the same resource. For
example, if your networking team also manages firewall rules, you can grant both
roles/compute.networkAdmin and roles/compute.securityAdmin to the networking
team's Google group.
The following tables describe the predefined Compute Engine IAM roles, as well as the permissions contained within each role. Each role contains a set of permissions that is suitable for a specific task. For example, the Instance Admin roles grant permissions to manage instances, the network-related roles include permissions to manage network-related resources, and the security role includes permissions to manage security-related resources, like firewalls and SSL certificates.
Compute Admin role
| Details | 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.*
resourcemanager.projects.get resourcemanager.projects.list serviceusage.quotas.get serviceusage.services.get serviceusage.services.list |
Compute Future Reservation Admin role
| Details | Permissions |
|---|---|
Compute Future Reservation Admin Beta(
|
compute. compute. compute. compute.futureReservations.get compute. compute. compute.reservations.create |
Compute Future Reservation User role
| Details | Permissions |
|---|---|
Compute Future Reservation User Beta(
|
compute. compute. compute.futureReservations.get compute. compute. compute.reservations.create |
Compute Future Reservation Viewer role
| Details | Permissions |
|---|---|
Compute Future Reservation Viewer Beta(
|
compute.futureReservations. |