Access Control Overview

By default, all Google Cloud Platform projects come with a single user: the original project creator. No other users have access to the project, and therefore, access to Compute Engine resources, until a user is added as a project member. This page describes the different ways you can add new users to your project and how to set access control for your Compute Engine resources.

In addition, if you run applications on a virtual machine (VM) instance, and the application needs access to Compute Engine or other Google Cloud Platform APIs, you can use service accounts to authenticate your applications instead of using user credentials.

Access control options for users

To give users the ability to create and manage your Compute Engine resources, you can add users as team members to your project and grant them permissions using Identity and Access Management (IAM) roles. A member can be an individual user with a valid Google account, a Google Group, a service account, or a GSuite domain.

When you add a member to your project, you specify which roles to grant them. IAM provides two types of roles: predefined and primitive roles. Each role is briefly described below.

You can grant permissions only on the project level. For example, granting permissions to delete VM instances would give a member the ability the delete any VM instance in the project.

Predefined Compute Engine roles

Predefined roles grant a set of related permissions. Compute Engine offers the following predefined roles:

Role Title Capabilities Target User
Compute Engine Image User

Permission to list and use images from another project. Grant a member this role together with another role so the member can use images from another project to create a new resource. For example, grant this role and the Instance Admin role so that a member can use images from another project to create VM instances and persistent disks.

If you are creating managed instance groups or if you are using Deployment Manager to create VM instances, you might need to grant the project's Google APIs service account this role in order to be able to use images from other projects.

  • Service accounts
  • Systems administrators
  • Developers
Compute Engine Instance Admin (v1)

Full control of Compute Engine instances, instance groups, disks, snapshots, and images. Read-only access to all Compute Engine networking resources.

If the member will be managing virtual machine instances that are configured to run as a service account, you must also grant the Service Account Actor role so that they can assign service accounts to VM instances.

  • Systems administrators
  • Developers
Compute Engine 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 member to create, start, stop, or delete instances.

Network administrators
Compute Engine Security Admin

Permissions to create, modify, and delete firewall rules and SSL certificates.

Security administrators
Compute Engine Service Account Actor

Permission to create instances that use service accounts, and permission to attach a disk and set metadata on an instance already configured to run as a service account.

You should not grant this role by itself because it provides no permissions to the Compute Engine API. You should grant a member this role and another role, such as the Instance Admin role.

  • Systems administrators
  • Developers
Compute Engine Network UserBeta

Permissions to use a shared VPC network. Specifically, grant this role to service owners that need to use resources in the host project. Once granted, service owners can use subnetworks and networks that belong to the host project. For example, a network user can create a VM instance that belongs to a shared VPC host network but they cannot delete or create new networks in the host project.

  • Systems administrators
  • Developers
Compute Engine Network ViewerBeta

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 Viewer role.

  • Network administrators
  • Systems administrators
  • Developers
  • Service accounts
Compute Engine Storage AdminBeta

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 this role.

  • Systems administrators
  • Developers
Compute Engine Shared VPC Admin

Permissions to administer shared VPC host projects, specifically enabling the host projects and associating service projects to the host project's network. This role can only be granted at the organization level.

Project creators

To see a list of API methods that a specific role grants permission to, review the Compute Engine IAM Roles documentation.

Primitive IAM roles

Primitive IAM roles map directly to the legacy project owner, editor, and viewer roles. Generally, you should use predefined roles whenever possible; however, in some cases, where IAM is not yet supported, you might need to use a primitive role to grant the correct permissions.

Role Title Permissions
Owner All viewer and editor privileges, plus the ability to change billing settings, manage access control, and delete a project.
Editor All viewer privileges, plus the ability to create, modify, and delete resources.
Viewer Read-only permissions to all resources; no permission to change resources.

To learn more about primitive roles, read documentation for Primitive Roles.

Predefined Roles Matrix

The following table provides a complete comparison of the capabilities of each Compute Engine role.

Capability Instance Admin (v1) Image User Network User Network Viewer Network Admin Security Admin Storage Admin Shared VPC Admin
Create or delete VM instances Yes* No No No No No No No
SSH into VM instances Yes* No No No No No No No
List or get VM instances Yes No No Yes Yes No No No
Create or delete images, disks, snapshots Yes No No No No No Yes No
List or get images Yes Yes No No No No Yes No
Create or delete instance groups Yes* No No No No No No No
List or get instance groups Yes No No Yes Yes No No No
Create and manage load balancers No No No No Yes No No No
Create and manage VPNs No No No No Yes No No No
View network/subnetwork resources Yes No Yes Yes Yes No No No
View firewall rules Yes No Yes Yes Yes Yes No No
Create and manage firewalls and SSL certificates No No No No No Yes No No
Create and manage shared VPC host projects No No No No No No No Yes
Use networks and subnetworks in a shared VPC host project No No Yes No No No No No
Create and manage networks and subnetworks No No No No Yes No No No

*If the VM instance can run as a service account, grant the Service Account Actor role as well.

To see a list of API methods that a specific role grants permission to, review the Compute Engine IAM Roles documentation.

Organization Policies

If you are a G Suite member, your project might be part of an Organization resource. An Organization resource is the supernode in the Google Cloud Platform resource hierarchy that is closely associated with a G Suite account. Once an Organization resource is created for a G Suite domain, all Cloud Platform Projects created by members of the domain will belong to the Organization resource.

An organization can implement Organization Policies which are policies that restrict allowed configurations across your entire Cloud Resource hierarchy. For Compute Engine, you can implement the following policies:

To set Organization Policies, you must have been granted the orgpolicy.policyAdmin role on the organization. You can also set project-specific overrides in case you have exceptions to the policy.

To learn more about Organizations, read the Organizations documentation.

To learn more about Organization Policies, read the Organization Policy documentation.

Granting users SSH access to VM instances

If you just want to give a user the ability to connect to a virtual machine instance using SSH, but don't want to grant them the ability to manage Compute Engine resources, add the user's public key to the project, or add a user's public key to a specific instance. Using this method, you can avoid adding a user as a project member, while still granting them access to specific instances.

To learn more about SSH and managing SSH keys, read the SSH keys Overview.

Note that if you grant the roles/compute.instanceAdmin.v1 role to a project member, they can automatically connect to instances using SSH, as long as the instance is not set up to run as a service account. If the instance is set up to run as a service account, you must also grant the roles/iam.serviceAccountActor role in order for the member to connect to the instance.

If you add a member as a project owner or editor, they also automatically have SSH access to virtual machine instances in the project.

Access control for applications running on VM instances

If you run application code on instances and the application needs to authenticate to other Google Cloud Platform APIs, you can create service accounts and give these service accounts specific IAM roles to authenticate to other Cloud Platform APIs on your behalf. A service account is a special account that has no user credentials and is ideal for server-to-server interactions.

To learn more about service accounts, read the Service Accounts documentation.

What's next?

Send feedback about...

Compute Engine Documentation