Service accounts

This page describes how service accounts work with Compute Engine.

For step-by-step information about attaching a service account to a virtual machine (VM) instance, review one of the following documents:

• To set up service account during VM creation, see Create a VM that uses a user-managed service account.
• To set up service account on an existing VM, see Change the attached service account.

To learn about best practices for creating and managing service accounts, read the Best practices for working with service accounts documentation.

What is a service account?

A service account is a special kind of account used by an application or compute workload, rather than a person. Service accounts are managed by Identity and Access Management (IAM).

Keep the following in mind when using service accounts with your VMs:

• You can attach the same service account to multiple VMs, but a single VM can only have one service account attached to it.
• If you attach the same service account to multiple VMs, any subsequent changes you make to the service account affects all VMs that use the service account. This includes any changes you make to the IAM roles granted to the service account. For example, if you remove a role, all VMs using the service account lose the permissions granted by that role.

How Compute Engine uses service accounts

Compute Engine uses two types of service accounts:

• User-managed service accounts
• Service agents

A user-managed service account can be attached to a Compute Engine instance to provide credentials to applications running on the instance. These credentials are used by the application for authentication to Google Cloud APIs, and authorization to access Google Cloud resources. Only user-managed service accounts can be attached to an instance, and an instance can have only one attached service account. You can change the service account that is attached to an instance at creation time or later on.

Service agents are used by the instance to access internal processes on your behalf.

In addition, you can create firewall rules that allow or deny traffic to and from instances based on the service account that you associate with each instance.

How authorization is determined

The authorization provided to applications hosted on a Compute Engine instance is limited by two separate configurations: the roles granted to the attached service account, and the access scopes that you set on the instance. Both of these configurations must allow access before the application running on the instance can access a resource.

Suppose you have an app that reads and writes files on Cloud Storage, it must first authenticate to the Cloud Storage API. You can create an instance with the cloud-platform scope and attach a service account to the instance. You can then grant Identity and Access Management (IAM) roles to the service account to give your app access to the appropriate resources. Your app uses the service account credentials to authenticate to the Cloud Storage API without embedding any secret keys or user credentials in your instance, image, or app code. Your app also uses the authorization provided by the IAM roles on the service account to access resources. For more information about authorization, see Authorization on this page.

User-managed service accounts

User-managed service accounts include new service accounts that you explicitly create and the Compute Engine default service account.

New service accounts

You can create and manage your own service accounts using IAM. After you create an account, you grant the account IAM roles and set up instances to run as the service account. Apps running on instances with the service account attached can use the account's credentials to make requests to other Google APIs.

To create and set up a new service account, see Create a VM that uses a user-managed service account.

Compute Engine default service account

New projects that have enabled the Compute Engine API have a Compute Engine default service account, which has the following email:

PROJECT_NUMBER[email protected]

The Compute Engine default service account has the following attributes:

• Automatically created, with an autogenerated name and email address, and added to your project when you enable the Compute Engine API. You have full control over the account.
• Attached by default to all VMs that you created by using the Google Cloud CLI or the Google Cloud console. You can override this behavior by specifying a different service account when you create the VM, or by explicitly specifying that no service account be attached to the VM.

• Depending on your organization policy configuration, the default service account might automatically be granted the Editor role on your project. We strongly recommend that you disable the automatic role grant by enforcing the iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint. If you created your organization after May 3, 2024, this constraint is enforced by default.

  If you disable the automatic role grant, you must decide which roles to grant to the default service accounts, and then grant these roles yourself.

  If the default service account already has the Editor role, we recommend that you replace the Editor role with less permissive roles.To safely modify the service account's roles, use Policy Simulator to see the impact of the change, and then grant and revoke the appropriate roles.

You can disable or delete this service account from your project, but doing so might cause any applications that depend on the service account's credentials to fail. If you accidentally delete the Compute Engine default service account, you can try to recover the account within 30 days. For more information, see Delete and undelete service accounts.

If the Compute Engine default service account was deleted more than 30 days ago, you can try to recover the service account by following the process in Troubleshooting default service accounts.

Service agents

Service agents are created and managed by Google Cloud and assigned to your project automatically. These accounts represent different Google Cloud services, and each account typically has some level of access to your Google Cloud resources.

You cannot attach service agents to a Compute Engine instance.

Google APIs Service Agent

Apart from the default service account, all projects enabled with Compute Engine come with a Google APIs Service Agent, identifiable using the email:

PROJECT_NUMBER@cloudservices.gserviceaccount.com

This service agent is designed specifically to run internal Google processes on your behalf. This service agent is owned by Google and is not listed in the Service Accounts section of Google Cloud console. By default, this service agent is automatically granted the project editor role on the project and is listed in the IAM section of Google Cloud console. This service agent is deleted only when the project is deleted. However, you can change the roles granted to this account, including revoking all access to your project.

Certain resources rely on the default editor permissions granted to this service agent. For example, managed instance groups and autoscaling uses the credentials of this service agent to create, delete, and manage instances. If you revoke permissions to this service agent, or modify the permissions in such a way that it doesn't grant permissions to create instances, this will cause managed instance groups and autoscaling to stop working.

For these reasons, you should not modify this service agent's roles unless a role recommendation explicitly suggests that you modify them.

Compute Engine Service Agent

All projects that have enabled the Compute Engine API have a Compute Engine Service Agent, which has the following email:

service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com

This service agent is designed specifically for Compute Engine to perform its service duties on your project. It relies on the Service Agent IAM Policy granted on your Google Cloud Project. It is also the service agent Compute Engine uses to access the user-managed service account on VM instances. Google owns this account, but it is specific to your project. This service agent is hidden from the IAM page in the console unless you select Include Google-provided role grants. By default, this service agent is automatically granted the compute.serviceAgent role on your project.

This service agent is deleted only when you delete your project. You can change the roles granted to this service agent and revoke all access to your project from this agent. Revoking or changing the permissions for this service agent prevents Compute Engine from accessing the identities of your service accounts on your VMs, and can cause outages of software running inside your VMs.

For these reasons, you should avoid modifying the roles for this service agent as much as possible.

Attaching a service account to an instance

To avoid providing an application with excess permissions, we recommend that you create a user-managed service account, grant it only the roles your application needs to function properly, and attach it to your Compute Engine instance. Your code can then use Application Default Credentials to authenticate with the credentials provided by the service account.

You can attach a service account to a Compute Engine instance when you create the instance, or later. Only one service account can be attached to an instance at a time; if you attach a service account to an instance that already has a service account attached, the previous service account is no longer used by that instance.

When you attach a service account to a Compute Engine instance, you must also ensure that the scopes set on the instance are correct. Otherwise, your app might not be able to access all of the APIs it needs. For more information, see