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.
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 user account (a Google Account or an account from an external identity provider)
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. When working on Compute Engine, you might also need roles for other services such as Cloud DNS and IAM service accounts. For a full list of IAM roles, see the IAM role reference documentation.
| 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 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:
|
|
What's next
- Learn more about IAM.
- Learn how to create and manage custom IAM roles.
- Grant IAM roles to project users.
- Grant IAM roles for specific Compute Engine resources.
- Grant IAM roles to service accounts.