Service accounts

This page describes service accounts and service account permissions, which can be limited by both access scopes that apply to VM instances, 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 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 you associate with each instance.

What is a service account?

A service account is an identity that an instance or an application can use to run API requests on your behalf.

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. Your application authenticates seamlessly to the API without embedding any secret keys or user credentials in your instance, image, or application code.

If your service accounts have the necessary IAM permissions, those service accounts can create and manage instances and other resources. Service accounts can modify or delete resources only if you grant the necessary IAM permissions to the service account at the project or resource level. You can also change what service account is associated with an instance.

An instance can have only one service account, and the service account must have been created in the same project as the instance.

Two types of service accounts are available to Compute Engine instances:

  • User-managed service accounts
  • 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 you create an account, 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

Newly-created projects come with the Compute Engine default service account, identifiable using this email:

[PROJECT_NUMBER]-compute@developer.gserviceaccount.com

Google creates the Compute Engine default service account and adds it to your project automatically but you have full control over the account.

The Compute Engine default service account is created with the IAM project editor role, but you can modify the service account's roles to securely limit which Google APIs the service account can access.

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 Compute Engine default service account, you can try to recover the account within 30 days. See Creating and managing service accounts for more information.

In summary, the Compute Engine 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 to your project with the IAM project editor role.
  • Enabled by default on all instances created by the gcloud command-line tool and the GCP Console. You can override this by specifying another service account when creating the instance or by explicitly disabling service accounts for the instance.

Associating a service account to an instance

When you create an instance using the gcloud command-line tool or the Google Cloud Platform Console, you can specify which service account the instance will use when calling GCP APIs. The instance will be automatically configured with the following access scopes:

  • Read-only access to Google Cloud Storage:
    https://www.googleapis.com/auth/devstorage.read_only
  • Write access to write Compute Engine logs:
    https://www.googleapis.com/auth/logging.write
  • Write access to publish metric data to your Google Cloud projects:
    https://www.googleapis.com/auth/monitoring.write
  • Read-only access to Service Management features required for Google Cloud Endpoints(Alpha):
    https://www.googleapis.com/auth/service.management.readonly
  • Read/write access to Service Control features required for Google Cloud Endpoints(Alpha):
    https://www.googleapis.com/auth/servicecontrol

Access scopes define the default OAuth scopes for requests made through the client libraries and gcloud. As a result, they potentially limit access to API methods when authenticating through OAuth. However, they do not extend to other authentication protocols like gRPC. As a result, a best practice is for you to set the full cloud-platform access scope on the instance, then securely limit your service account's access by granting IAM roles to the service account. See Service account permissions for details.

When you create an instance by making a request to the API directly without using the 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 payload.

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:

[PROJECT_NUMBER]@cloudservices.gserviceaccount.com

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.

Compute Engine System service account

All projects that have enabled the Compute Engine API have a Compute Engine System service account, which is identifiable using the following address:

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

This service account is designed specifically for Google 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 account Compute Engine uses to access the customer-owned service account on VM instances. Google owns this account, but it is specific to your project and is listed in the Service Accounts and IAM sections of the GCP Console. By default, the account is automatically granted the compute.serviceAgent role on your project.

This service account is deleted only when you delete your project. You can change the roles granted to this account and revoke all access to your project from the account. Revoking or changing the permissions for this service account 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 not modify the roles for this service account.

Service account permissions

When you set up an instance to run as a service account, you determine the level of access the service account has by the IAM roles you grant to the service account. If the service account has no IAM roles, then no API methods can be run by the service account on that instance.

Furthermore, an instance's access scopes determine the default OAuth scopes for requests made through the gcloud tool and client libraries on the instance. As a result, access scopes potentially further limit access to API methods when authenticating through OAuth. However, they do not extend to other authentication protocols like gRPC.

The best practice is to set the full cloud-platform access scope on the instance, then securely limit the service account's access using IAM roles.

Essentially:

  • IAM restricts access to APIs based on the IAM roles that are granted to the service account.
  • Access scopes potentially further limit access to API methods when authenticating through OAuth.

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 is an OAuth scope for all Cloud Platform services, and then securely limit the service account's access by granting it IAM roles.

https://www.googleapis.com/auth/cloud-platform

For example, if you enabled the cloud-platform access scope on an instance and then granted the following predefined IAM roles:

  • roles/compute.instanceAdmin.v1
  • roles/storage.objectViewer
  • roles/compute.networkAdmin

Then the service account has only the permissions included in those three IAM roles. That account cannot perform actions outside of these roles despite the Cloud Platform access scope.

On the other hand, if you grant a more restrictive scope on the instance, like the Cloud Storage read-only scope(https://www.googleapis.com/auth/devstorage.read_only), and set the roles/storage.objectAdmin administrator role on the service account, then by default, requests from the gcloud tool and the client libraries would not be able to manage Google Cloud Storage objects from that instance, even though you granted the service account the roles/storage.ObjectAdmin role. This is because the Cloud Storage read-only scope does not authorize the instance to manipulate Cloud Storage data.

Generally, the documentation for each API method lists the scopes required for that method. For example, the instances.insert method provides a list of valid scopes in its authorization section.

IAM roles

You must grant the appropriate IAM roles to a service account to allow that service account access to relevant API methods.

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, which limits 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 a predefined IAM role for the access level you want, you can grant one of the primitive roles, such as project editor, or you can create and grant custom roles.

  • You must set access scopes on the instance to authorize access.

    While a service account's access level is determined by the IAM roles granted to the service account, an instance's access scopes determine the default OAuth scopes for requests made through the gcloud tool and client libraries on the instance. As a result, access scopes potentially further limit access to API methods when authenticating through OAuth.

Access scopes

Access scopes are the legacy method of specifying permissions for your instance. Access scopes are not a security mechanism. Instead, they define the default OAuth scopes used in requests from the gcloud tool or the client libraries. Note that they have no effect when making requests not authenticated through OAuth, such as gRPC or the SignBlob APIs.

You must set up access scopes when you configure an instance to run as a service account.

A best practice is to set the full cloud-platform access scope on the instance, then securely limit the service account's API access with IAM roles.

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 have no effect if you have not enabled the related 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.

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.

What's next

Bu sayfayı yararlı buldunuz mu? Lütfen görüşünüzü bildirin:

Şunun hakkında geri bildirim gönderin...

Compute Engine Documentation