This page describes service accounts, access scopes, and Identity and Access Management (IAM) roles that apply to service accounts. To learn how to create and use service accounts, read the Creating and Enabling Service Accounts for Instances documentation.
A service account is a special account that can be used by services and applications running on your Google Compute Engine instance to interact with other Google Cloud Platform APIs. Applications can use service account credentials to authorize themselves to a set of APIs and perform actions within the permissions granted to the service account and virtual machine instance. In addition, you can create firewall rules that allow or deny traffic to and from instances based on the service account that owns the instances.
What are service accounts?
A service account is the identity an instance or an application is running with. This identity is used to identify applications running on your virtual machine instances to other Google Cloud Platform services. For example, if you write an application that reads and writes files on Google Cloud Storage, it must first authenticate to the Google Cloud Storage API. You can create a service account and grant the service account access to the Cloud Storage API. Then, you would update your application code to pass the service account credentials to the Cloud Storage API. In this way, your application authenticates seamlessly to the API without embedding any secret keys or user credentials in your instance, image, or application code.
You can use service accounts to create instances and other resources. If you create a resource using a service account, that resource is then owned by the creating service account. You can also change the service account of an existing instance.
An instance can have one service account only.
There are two types of service accounts available to Compute Engine instances: user-managed service accounts and Google-managed service accounts.
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 Google Identity and Access Management. After creating an account, you grant the account IAM roles, and set up instances to run as the service account. Applications running on instances enabled with the service account can use the account's credentials to make requests to other Google APIs.
To create and set up a new service account, see Creating and Enabling Service Accounts for Instances.
Compute Engine default service account
For historical reasons, all projects come with the Compute Engine default service account, identifiable using this email:
The default service account is created by Google and added to your account automatically but you have full control over the account.
When you create instances using the
gcloud command-line tool or the Google Cloud Platform Console,
the instance is automatically enabled to run as the default service account,
with the following access scopes:
- Read-only access to Google Cloud Storage:
- Write access to write Compute Engine logs:
- Write access to publish metric data to your Google Cloud projects:
- Read-only access to Service Management features required for Google Cloud
- Read/write access to Service Control features required for Google Cloud
When you create an instance by making a request to the API directly without using
gcloud command-line tool or the Google Cloud Platform Console, the default service
account does not come enabled with the instance. However, you can still enable
the default service account by explicitly specifying it as part of the request
You can 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 default service account, you can contact the Compute Engine team to try and add the account back to your project.
In summary, the default service account has the following attributes:
- Automatically created by the Google Cloud Platform Console project and has an autogenerated name and email address.
- Automatically added as a project editor to your project.
- Enabled on all instances created by the
gcloudcommand-line tool and the GCP Console with a specific set of permissions. You can override this by specifying another service account when creating the instance or by explicitly disabling service accounts for the instance.
Google-managed service accounts
These service accounts are created and managed by Google and assigned to your project automatically. These accounts represent different Google services and each account has some level of access to your Google Cloud Platform project.
Google APIs service account
Apart from the default service account, all projects enabled with Compute Engine come with a Google APIs service account, identifiable using the email:
This service account is designed specifically to run internal Google processes on your behalf. The account is owned by Google and is not listed in the Service Accounts section of GCP Console. By default, the account is automatically granted the project editor role on the project and is listed in the IAM section of GCP Console. This service account is only deleted 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 this service account and the default editor permissions granted to the service account. For example, managed instance groups and autoscaling uses the credentials of this account to create, delete, and manage instances. If you revoke permissions to the service account, or modify the permissions in such a way that it does not 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 account's roles.
Service account permissions
When you set up an instance to run as a service account, the level of access the service account has is determined by the combination of access scopes granted to the instance and IAM roles granted to the service account. You need to configure both access scopes and IAM roles to successfully set up an instance to run as a service account. Essentially:
- Access scopes authorize the potential access an instance has.
- IAM restricts that access to the roles granted to the service account.
Both access scopes and IAM roles are described in detail in the sections below.
There are many access scopes that you can
choose from but you can also just set the
cloud-platform access scope, which
authorizes access to all Cloud Platform services, and then limit the access by
granting IAM roles:
For example, if you enabled the
cloud-platform access scope on an
instance and then grant three IAM roles:
The service account only has permissions granted by the three IAM roles. The account cannot perform actions outside of these roles, despite the Cloud Platform access scope.
In contrast, if you grant a more restrictive scope, like the Cloud Storage
read-only scope (
then set the
roles/storage.objectAdmin role on the service account, the
instance would not be able to manage Google Cloud Storage objects, even though
you granted the
roles/storage.ObjectAdmin role. This is because the Cloud
Storage read-only scope does not authorize the instance to manipulate Cloud
Generally, each API method documentation will also list the scopes required for
that method. For example, the
instances.insert method provides a list of
valid scopes in the
Access scopes are the legacy method of specifying permissions for your instance. Before the existence of IAM roles, access scopes were the only mechanism for granting permissions to service accounts. Although they are not the primary way of granting permissions now, you must still set up access scopes when configuring an instance to run as a service account.
Access scopes apply on a per-instance basis: you set access scopes when creating an instance and the access scopes persists only for the life of the instance. Access scopes work only if you have enabled the respective API on the project that the service account belongs to. For example, granting an access scope for Google Cloud Storage on a virtual machine instance allows the instance to call the Cloud Storage API only if you have enabled the Cloud Storage API on the project. If the API is not enabled on the project, the access scope has no effect.
Example access scopes include:
https://www.googleapis.com/auth/cloud-platform- Full access to all Google Cloud Platform resources.
https://www.googleapis.com/auth/compute- Full control access to Google Compute Engine methods.
https://www.googleapis.com/auth/compute.readonly- Read-only access to Google Compute Engine methods.
https://www.googleapis.com/auth/devstorage.read_only- Read-only access to Google Cloud Storage.
https://www.googleapis.com/auth/logging.write- Write access to the Google Compute Engine logs.
In addition to setting access scopes, you must grant the correct IAM roles to a service account to determine the level of access the account has. For example, you can grant a service account the IAM roles for managing Google Cloud Storage objects, or for managing Google Cloud Storage buckets, or both, limiting the account to the permissions granted by those roles.
IAM roles are account-specific. That means once you grant an IAM role to a service account, any instance running as that service account can use that role. Also, keep in mind that:
Some IAM roles are currently in Beta.
If there isn't an IAM role for the access level you want, you can grant one of the primitive roles, such as project editor.
You must set access scopes on the instance to authorize access.
You cannot set only IAM roles on the service account and omit access scopes when creating the virtual machine instance. The level of access a service account has is determined by a combination of access scopes and IAM roles so you must configure both access scopes and IAM roles for the service account to work properly.