By default, all Google Cloud projects come with a single user: theoriginal project creator. No other users have access to the project, andtherefore, access to Compute Engine resources, until a user is addedas a project member or is bound to a specific resource. This page describes theways you can add new users to your project and how to set accesscontrol for your Compute Engine resources usingIdentity and Access Management (IAM).

For information about providing access to applications running on yourCompute Engine instances, seeHow authorization is determined.

Access control options for users

To give users the ability to create and manage your Compute Engineresources, you can add users asteam members to your project or tospecificresources and grant them permissions using IAMroles.

A team member can be an individual user with a valid Google Account or user account from anexternal identity provider, a GoogleGroup, a group of identities from a workforce identity pool, a service account, or a Google Workspace domain. When you add ateam member to a project or to a resource, you specify which roles to grantthem. IAM provides three types of roles:predefined roles,basic roles, andcustom roles.

Resources inherit the policies of their parent resources in theGoogle Cloudresource hierarchy. The effectivepolicy for a resource is the union of the policy set at that resource and thepolicy inherited from its parent.

Note: To give a user SSH access to VM instances and prevent access to all APIs,add the user's SSH keys tothe project or instance instead of adding the user to the project and grantingthem wide ranging permissions.

Predefined Compute Engine roles

Predefined roles grant a set of related permissions. Compute Engineoffers 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 thisrole together with another role so the member can use images from anotherproject to create a new resource. For example, grant this role and the InstanceAdmin role so that a member can use images from another project to create VMinstances and persistent disks. If you are creatingmanaged instance groupsor if you are usingDeployment Manager tocreate VM instances, you might need to grant the project's Google APIs serviceaccount this role before you can 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 is managing VM instances that are configured torun as a service account, you must also grant theroles/iam.serviceAccountUser role sothat they can assign service accounts to VM instances.	Systems administrators Developers
Compute Engine admin role	Full control of all Compute Engine resources. If the user ismanaging VM instances that are configured to run as a serviceaccount, you must also grant theroles/iam.serviceAccountUserrole.	Systems administrators Developers
Compute Engine network admin	Permissions to create, modify, and delete networking resources, except forfirewall rules and SSL certificates. The network admin role allows read-onlyaccess to firewall rules, SSL certificates, and instances (to view theirephemeral 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 load balancer admin	Permissions to create, modify, and delete load balancers and associated resources.	Load balancer administrators
Compute Engine service account user	Permission to create instances that use service accounts, and permission toattach a disk and set metadata on an instance already configured to run as aservice account. You should not grant this role by itself because it providesno permissions to the Compute Engine API. You should grant a memberthis role and another role, such as the instance admin role.	Systems administrators Developers
Compute Engine viewer role	Read-only access to get and list Compute Engine resources,without being able to read the data stored on them. For example, an account withthis role could inventory all of the disks in a project, but it could not readany of the data on those disks.	System administrators
Compute Engine network user	Permissions to use ashared VPCnetwork. Specifically, grant this role to service owners who need to useresources in the host project. Once granted, service owners can use subnetworksand networks that belong to the host project. For example, a network usercan create a VM instance that belongs to a shared VPC host network, but theycannot delete or create new networks in the host project.	Systems administrators Developers
Compute Engine network viewer	Read-only access to all networking resources. For example, if you havesoftware that inspects your network configuration, you could grant thatsoftware's service account the network viewer role.	Network administrators Systems administrators Developers Service accounts
Compute Engine storage admin	Permissions to create, modify, and delete disks, images, and snapshots. For example, if your company has someone who manages images and you do notwant them to have the editor role on the project, then grant their account thisrole.	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, reviewtheCompute Engine IAM rolesdocumentation.

Predefined roles matrix

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

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

^{*If the VM instance can run as a service account, grant the service account user role as well.}

To see a list of API methods that a specific role grants permission to, reviewtheCompute Engine IAM rolesdocumentation.

Basic IAM roles

Basic 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 mightneed to use a basic 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 deleteresources.
Viewer	Read-only permissions to all resources; no permission to change resources.

To learn more about basic roles, read documentation forbasic roles.

If predefined or basic roles do not meet you needs, you cancreate customroles.

IAM policies for Compute Engine resources

You cangrant access toCompute Engine resourcessuch as VM instances, images, and disks, by attaching IAMpolicies directly to those resources. An IAM policy lets youmanageIAM roles on those resourcesinstead of, or in addition to, managing roles at the project level. This givesyou flexibility to apply the principle of least privilege, which is to grantaccess only to the specific resources that collaborators need to do their work.

With IAM policies for Compute Engine resources,organizations can:

• Grant users access to a specific subset of resources. Suppose Alice shouldmanage a subset of instances in a project. With instance-levelIAM policies, you grant her thecompute.instanceAdmin.v1role on only those instances. If you granted Alice the same role on theproject, then she would have permission to modify all instances in theproject.
• Allow administrators to grant access. Administrators can grant otherpeople access to instances, disks, and images without needing to be powerfulproject owners. Suppose Bob is a developer who has been granted thecompute.storageAdmin role ona specific image. He can share that image with his teammates by granting themthecompute.imageUser role onthe image. Without IAM policies for Compute Engineresources, Bob can't share that image with his teammates unless he becomes aproject owner because he'd need to modify the project's IAMpolicy.

Resources also inherit the policies of their parent resources. If you set apolicy at the project level, it's inherited by all its child resources. Theeffective policy for a resource is the union of the policy set at that resourceand the policy inherited from higher up in the hierarchy. For more information,read about theIAM policy hierarchy.

Organization policies

If you are a Google Workspace member, your project might be part of anOrganization resource.An Organization resource is the supernode in the Google Cloudresource hierarchythat is closely associated with a Google Workspace account. After anOrganization resource is created for a Google Workspace domain, allGoogle Cloud projects created by members of the domain belong to theOrganization resource.

An organization can implementorganization policies,which are policies that restrict allowed configurations across your entireGoogle Cloud resource hierarchy. For Compute Engine, you canimplement the following policies:

• Disable interactive access to the serial console.
• Disable external IP addresses for VM instances.
• Restrict which image projects are available to your project members

To setOrganization policies,you must have been granted theorgpolicy.policyAdmin role on the organization.You can also set project-specific overrides in case you have exceptions to thepolicy.

To learn more about Organizations, read theOrganizationsdocumentation.

To learn more about Organization policies, read theOrganization policydocumentation.

Granting users SSH access to VM instances

To give a user the ability to connect to a VM instance using SSH withoutgranting them the ability to manage Compute Engine resources,add the user's public keyto the project, or add a user's public key to a specific instance. Using thismethod, you can avoid adding a user as a project member, while still grantingthem access to specific instances.

To learn more about SSH and managing SSH keys, read theSSH keys overview.

Note that if you grant theroles/compute.instanceAdmin.v1 role to a projectmember, they can automatically connect to instances using SSH, as long as theinstance is not set up to run as a service account. If the instance is set upto run as a service account, you must also grant theroles/iam.serviceAccountUser role before the member can connect to theinstance.

If you add a member as a project owner or editor, they also automatically haveSSH access to VM instances in the project.

Access control for apps running on VM instances

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

To learn more about service accounts, read theService accounts documentation.

Managed workload identities for Compute Engine workloads

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

For information about access to this release, see the access request page.

You can set up automatic provisioning and lifecycle management ofX.509 certificates from Certificate Authority Service(CA Service) using managed workload identities. Managed workloadidentity certificates are issued from CA Service, which is ahighly-available, scalable Google Cloud service that helps you to simplify andautomate the deployment, management, andsecurity of CA services while staying in control of your private keys.

With managed workload identities, you can benefit from per-VMmTLS,managed by Compute Engine. Per-VM mTLS uses X.509 certificates that areissued when you create a VM. These mTLS certificates are automatically rotated,so you don't need to worry about managing the certificates anymore.

Managed workload identities provide a foundation to enable mutuallyauthenticated and encrypted communications between any two Compute Engine VMs.For example, when you use managed workload identities, service A running in oneVM communicates with service B running in a different over an encrypted channelthat is established using mTLS.

For information about configuring managed workload identities, seeAuthenticate workloads to other workloads over mTLS.

What's next?

• Add users as team members.
• Learn more aboutIAM roles.
• Learn more aboutAdding and removing SSH keys.
• Learn more aboutService accounts.