This page describes Identity and Access Management (IAM) roles and the permissions granted to each Compute Engine IAM role. When you add a new project member to your project, you can assign IAM roles to the new member using IAM policies. To learn how to set policies, read Managing Policies in the IAM documentation. To learn how to assign roles to a Compute Engine service account, read the Creating and Enabling Service Accounts for Instances documentation.
You might also be interested in a full list of IAM permissions for individual API methods.
Before you begin
- Read the Google Cloud IAM documentation.
What is IAM?
Google Cloud Platform offers Identity and Access Management (IAM), which lets you give more granular access to specific Google Cloud Platform 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 the identity certain permissions. For example, you can
assign the compute.networkAdmin role to a Google account and the account can
control network-related resources in the project, but cannot manage other
resources, like instances and disks. You can also use IAM to apply the
Cloud Platform Console legacy roles
granted to project team members.
Compute Engine IAM roles
With IAM, every API method in Compute Engine 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 user, group, or service account as a member of your project. In addition to the legacy roles, owner, editor, and viewer, you can assign the following Compute Engine roles to the members of your project.
The following table lists the IAM roles available to Compute Engine users. The table is divided into different roles. For example, the first two roles in the table grant permissions to manage instances, followed by roles that grant permissions to manage network-related resources. Lastly, the security roles grant permissions to manage security-related resources, like firewalls and SSL certificates.
Compute Instance Admin role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.instanceAdmin.v1
|
Permissions to create, modify, and delete virtual machine instances.
This includes permissions to create, modify, and delete disks.
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, grant this role. |
|
Service Account Actor role
| Role Name | Description | Permissions |
|---|---|---|
roles/iam.serviceAccountActor |
Access to obtain credentials for a service account and run operations as the service account. |
|
Compute Engine Image User Role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.imageUser |
Permission to list and read images without having other permissions to
resources in the project. Granting the compute.imageUser
role gives members the ability to list all images in the project and
create resources, such as instances and persistent disks, based on
images in the project.
|
|
Compute Engine Network Viewer role (Beta)
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.networkViewer (Beta) |
Read-only access to all networking resources
For example, if you have software that inspects your network
configuration, you could grant that software's service account the
|
|
Compute Engine Network Admin role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.networkAdmin
| Permissions to create, modify, and delete networking resources, except
for firewall rules and SSL certificates. The networkAdmin
role allows read-only access to firewall rules, SSL certificates, and
instances (to view their ephemeral IP addresses). The 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 the networking teams group the
|
|
Compute Engine Security Admin role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.securityAdmin |
Permissions to create, modify, and delete firewall rules and SSL
certificates.
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 the security teams
group the |
|
Compute Engine Storage Admin role (Beta)
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.storageAdmin (Beta) |
Permissions to create, modify, and delete disks, images, and snapshots.
For example, if your company has someone who manages images and you
do not want them to have the editor role on the project, then grant
their account the |
|
Compute Engine XPN Admin role (Beta)
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.xpnAdmin (Beta) |
Permissions to administer XPN host projects, specifically specifying
the XPN host projects and associating the XPN service projects to the
XPN host project network.
Google Cloud Platform recommends that the XPN admin be the owner of
the XPN host project. The XPN admin is responsible for granting
|
|
Compute Engine Network User role (Beta)
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.networkUser (Beta) |
Permissions to use an XPN Network. Specifically, grant this role to Service owners that need to use resources in the XPN host project network. |
|
You can grant multiple roles to a project member on the same project. For
example, if your networking team manages firewall rules instead of leaving those
to a separate security team, you can grant the compute.networkAdmin and
compute.securityAdmin roles to the networking team’s
Google group.
The serviceAccountActor role
When granted together with the compute.instanceAdmin.v1 role, the
iam.serviceAccountActor role gives members the ability to create and
manage instances that use a service account. Specifically, granting
the iam.serviceAccountActor and the compute.instanceAdmin.v1 roles 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 the iam.serviceAccountActor role 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.serviceAccountActorbut prevents access to other service accounts for which the member is not aniam.serviceAccountActor. -
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.
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 instances using the standard Google Cloud
Platform tools, like the gcloud tool or
SSH from the Browser.
When a member uses the gcloud command-line tool or SSH from the browser, the
tools will automatically generate a public/private keypair and add the public
key to the project metadata. If the member does not have permissions to edit
project metadata, the tool will add the member's public key to the instance
metadata instead.
If the member has an existing keypair they want to use, they can manually add their public key to the instance's metadata. Learn more about adding and removing SSH keys from 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 Cloud Platform 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, especially when configured to be autoscaled, are resources that perform actions on your behalf without direct user interaction. Managed instance groups use a service account identity to create, delete, and manage instances in the instance group. For more information, read the managed instance groups and IAM documentation.
Unsupported operations
You cannot grant access to perform rolling updates on instance groups using IAM roles.
To grant permission to perform these operations, use the broader owner, editor, or viewer roles.
Known issues
- Some IAM roles are still in Beta so IAM might not be supported by all
available clients. We recommend using the
gcloudcommand-line tool or the Google Cloud Platform APIs directly to use IAM.
What's next
- Learn more about IAM.
- See a full list of Compute Engine IAM Permissions.
- Grant IAM roles to users.
- Grant IAM roles to service accounts.
