This page describes Identity and Access Management (IAM) roles and the permissions contained in 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, 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
GCP 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.
You can grant multiple roles to a project member on the same resource. For
example, if your networking team manages firewall rules instead of leaving those
to a separate security team, you can grant both roles/compute.networkAdmin and
roles/compute.securityAdmin to the networking team’s
Google group.
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.
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. |
|
Compute Admin role
| Role Name | Description | Permissions |
|---|---|---|
roles/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
|
|
Service Account User role
| Role Name | Description | Permissions |
|---|---|---|
roles/iam.serviceAccountUser |
When granted alongside instanceAdmin.v1, grants
access to create VMs, attach disks to, and update metadata on VM
instances that can run as a service account. |
|
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.
|
|
Network Viewer role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.networkViewer |
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
|
|
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 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
|
|
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 Viewer role
| Role Name | Description | Permissions |
|---|---|---|
roles/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. |
|
Storage Admin role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.storageAdmin |
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 |
|
Shared VPC Admin role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.xpnAdmin |
Permissions to administer shared VPC: specifying the shared VPC host projects and associating the shared VPC service projects to the host project network. Google Cloud Platform recommends that the Shared VPC Admin be the
owner of the shared VPC host project. The Shared VPC Admin is
responsible for granting |
|
Network User role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.networkUser |
Permissions to use a shared VPC network. Specifically, grant this role to Service owners that need to create resources in the shared VPC host project network. |
|
OS Admin Login role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.osAdminLogin
|
Access to log in to a Compute Engine instance as an administrator user. |
|
OS Login role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.osLogin
|
Access to log in to a Compute Engine instance as a standard (non-administrator) user. |
|
OS Login External User role
| Role Name | Description | Permissions |
|---|---|---|
roles/compute.osLoginExternalUser
|
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 IAM roles in order to allow access to instances using SSH. |
|
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.
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.
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.
