Service Accounts

This page explains service accounts, types of service accounts, and the IAM roles that are available to service accounts.

Before you begin

  • Understand the basic concepts of Cloud IAM.

What are Service accounts?

A service account is a special Google account that belongs to your application or a virtual machine (VM), instead of to an individual end user. Your application uses the service account to call the Google API of a service, so that the users aren't directly involved.

For example, a Compute Engine VM may run as a service account, and that account can be given permissions to access the resources it needs. This way the service account is the identity of the service, and the service account's permissions control which resources the service can access.

A service account is identified by its email address, which is unique to the account.

Service account keys

Each service account is associated with a key pair, which is managed by Google Cloud Platform (GCP). It is used for service-to-service authentication within GCP. Google rotates the keys daily.

You may optionally create one or more external key pairs for use from outside GCP (for example, for use with Application Default Credentials). When you create a new key pair, you download the private key (which is not retained by Google). With external keys, you are responsible for security of the private key and other management operations such as key rotation. External keys can be managed by the IAM API, gcloud command-line tool, or the Service Accounts page in the Google Cloud Platform Console. You can create up to 10 service account keys per service account to facilitate key rotation.

Types of service accounts

User-managed service accounts

When you create a new Cloud project using GCP Console and if Compute Engine API is enabled for your project, a Compute Engine Service account is created for you by default. It is identifiable using the email:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

If your project contains a App Engine application, the default App Engine service account is created in your project by default. It is identifiable using the email:

PROJECT_ID@appspot.gserviceaccount.com

If you create a service account in your project, you'll name the service account and it will be assigned an email with the following format:

SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

You can create up to 100 service accounts per project (including the default Compute Engine service account and the App Engine service account) using the IAM API, the GCP console, or the gcloud command-line tool. These default service accounts and the service accounts you explicitly create are the user-managed service accounts.

Google-managed service accounts

In addition to the user-managed service accounts, you might see some additional service accounts in your project’s IAM policy or in GCP Console. These service accounts are created and owned by Google. These accounts represent different Google services and each account is automatically granted IAM roles to access your GCP project.

Google APIs service account

An example of a Google-managed service account is a Google API 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 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 deleted only when the project is deleted. Google services rely on the account having access to your project, so you should not remove or change the service account’s role on your project.

Service account permissions

In addition to being an identity, a service account is a resource which has IAM policies attached to it. These policies determine who can use the service account.

For instance, Alice can have the editor role on a service account and Bob can have viewer role on a service account. This is just like granting roles for any other GCP resource.

The default Compute Engine and App Engine service accounts are granted editor roles on the project when they are created so that the code executing in your App or VM instance have the necessary permissions. In this case the service accounts are identities that are granted the editor role for a resource (project).

If you want to allow your automation to access a Cloud Storage bucket, you grant the service account (that your automation uses) the permissions to read the Cloud Storage bucket. In this case the service account is the identity that you are granting permissions for another resource (the Cloud Storage bucket).

The Service Account User role

You can grant the iam.serviceAccountUser role at the project level (for all service accounts in the project) or at the service account level.

  • Granting the iam.serviceAccountUser role to a user for a project gives the user access to all service accounts in the project, including service accounts that may be created in the future.

  • Granting the iam.serviceAccountUser role to a user for a specific service account gives a user access to the service account.

When granted together with the compute.instanceAdmin role, the iam.serviceAccountUser role gives users the ability to create and manage Compute Engine instances that use a service account.

After you grant the IAM roles to the service accounts you can assign the service account to one or more new virtual machine instances. For instructions on how to do this, see Setting up a new instance to run as a service account.

Users who are serviceAccountUsers for a service account can access all the resources for which the service account has access. Therefore be cautious when granting the iam.serviceAccountUser role to a user.

Service accounts represent your service-level security. People who have IAM policies to manage and use the service accounts and people who hold private external keys for those service accounts determine the security of the service. As such, it is best-practice to use the IAM API to audit the service accounts, the keys, and the policies on those service accounts. If your service accounts do not need external keys, delete them. If users do not need permission to manage or use service accounts, then remove them from the IAM Policy.

The Service Account Token Creator role

This role enables impersonation of service accounts to create OAuth2 access tokens, sign blobs, or sign JWTs.

The Service Account Actor role

This role has been deprecated. If you need to run operations as the service account, use the Service Account User role. To effectively provide the same permissions as Service Account Actor, you should also grant Service Account Token Creator.

Access scopes

Access scopes are the legacy method of specifying permissions for your VM. 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 access scopes when configuring an instance to run as a service account. For information on access scopes see Google Compute Engine documentation

Application Default Credentials

Application default credentials are a mechanism to make it easy to use service accounts when operating inside and outside GCP, as well as across multiple GCP projects. The most common use case is testing code on a local machine, and then moving to a development project in GCP, and then moving to a production project in GCP. Using Application Default Credentials ensures that the service account works seamlessly; that is, that it uses a locally-stored service account key when testing on your local machine but uses the project's default Compute Engine service account when running on Compute Engine. For more information, see Application Default Credentials.

What's next

For best practices on using service accounts, see Understanding Service Accounts.

Read the following guides to understand how to:

Send feedback about...

Cloud Identity and Access Management Documentation