Understanding Service Accounts

Background

A service account is a special type of Google account that belongs to your application or a virtual machine (VM), instead of to an individual end user. Your application assumes the identity of the service account to call Google APIs, so that the users aren't directly involved. A service account can have zero or more pairs of service account keys, which are used to authenticate to Google.

Once you decide that you need a service account, you can ask yourself the following questions to understand how you’re going to use the service account:

What resources can the service account access?
What permissions does the service account need?
Where will the code that assumes the identity of the service account be running: on Google Cloud Platform or on-premises?

Use the following flowchart to figure out the responses to the above questions:

Service account flowchart

One of the features of IAM service accounts is that you can treat it both as a resource and as an identity.

When treating the service account as an identity, you can grant a role to a service account, enabling it to access a resource (such as a project).

When treating a service account as a resource, you can grant permission to a user to access that service account. You can grant the Owner, Editor, Viewer, or Service Account User role to a user to access the service account.

Granting access to service accounts

Granting access to a service account to access a resource is similar to granting access to any other identity. For example, if you have an application running on Google Compute Engine and you want the application to only have access to create objects in Google Cloud Storage. You can create a service account for the application and grant it the Storage Object Creator role. The following diagram illustrates this example:

Service account flowchart

Learn about Granting roles to service accounts.

Acting as a service account

Let’s say that you have a long running job that your employees have permissions to start. You don’t want that job to be terminated when the employee who last started that job leaves the company.

The way you would solve this problem is by creating a service account to start and stop the job. You can do this using the following steps:

Create a service account.
Grant the Service Account User (iam.serviceAccountUser) role for the service account to your employees who need permission to start the job. In this scenario, the service is the resource.
Grant the Compute Instance Admin (roles/compute.instanceAdmin.v1) role to the same employees.

Now, employees can create Compute Engine instances that run that service account, connect to them, and use the service account to start the job. For example:

gcloud compute instances create my-instance --scopes=cloud-platform \
--service-account=my-service-account@test9q.iam.gserviceaccount.com \
--zone=us-central1-a

For more information, see The serviceAccountUser role.

Migrating data to Google Cloud Platform

Let’s say that you have some data processing that happens on another cloud provider and you want to transfer the processed data to Google Cloud Platform. You can use a service account from the virtual machines on the external cloud to push the data to Google Cloud Platform. To do this, you must create and download a service account key when you create the service account and then use that key from the external process to call the Cloud Platform APIs.

Keeping track of service accounts

Over time, as you create more and more service accounts, you might lose track of which service account is used for what purpose.

The display name of a service account is a good way to capture additional information about the service account, such as the purpose of the service account or a contact person for the account. For new service accounts, you can populate the display name when creating the service account. For existing service accounts use the serviceAccounts.update() method to modify the display name.

Deleting and recreating service accounts

It is possible to delete a service account and then create a new service account with the same name. If you reuse the name of a deleted service account, it may result in unexpected behavior.

When you delete a service account, its role bindings are not immediately deleted. If you create a new service account with the same name as a recently deleted service account, the old bindings may still exist; however, they will not apply to the new service account even though both accounts have the same email address. This behavior occurs because service accounts are given a unique ID within Cloud IAM at creation. Internally, all role bindings are granted using these IDs, not the service account's email address. Therefore, any role bindings that existed for a deleted service account do not apply to a new service account that uses the same email address.

To avoid confusion, we suggest using unique service account names. If this is not possible, you can grant a role to the new service account by:

Explicitly removing any bindings granting that role to the old service account.
Re-granting those roles to the new service account.

You must remove the role bindings first before re-adding them. Simply granting the role again will silently fail by granting the role to the old, deleted service account.

Granting minimum permissions to service accounts

You should only grant the service account the minimum set of permissions required to achieve their goal. Learn about Granting roles to a service account for specific resources.

When granting permissions to users to access a service account, keep in mind that the user can access all the resources for which the service account has permissions. Therefore it’s important to configure permissions of your service accounts carefully; that is, be strict about who on your team can act as a service account.

Users with IAM roles to update the App Engine and Compute Engine instances (such as App Engine Deployer or Compute Instance Admin) can effectively run code as the service accounts used to run these instances, and indirectly gain access to all the resources for which the service accounts has access. Similarly, SSH access to a Compute Engine instance may also provide the ability to execute code as that instance.

Managing service account keys

There are two types of service account keys:

GCP-managed keys. These keys are used by Cloud Platform services such as App Engine and Compute Engine. They cannot be downloaded, and are automatically rotated and used for signing for a maximum of two weeks. The rotation process is probabilistic; usage of the new key will gradually ramp up and down over the key's lifetime. We recommend caching the public key set for a service account for at most 24 hours to ensure that you always have access to the current key set.
User-managed keys. These keys are created, downloadable, and managed by users. They expire 10 years from creation.

For user-managed keys, you need to make sure that you have processes in place to address key management requirements such as:

Key storage
Key distribution
Key revocation
Key rotation
Protecting the keys from unauthorized users
Key recovery

Anyone who has access to the keys will be able to access resources through the service account. Always discourage developers from checking keys into the source code or leaving them in Downloads directory.

To enhance the security of keys, follow the guidance below:

Use the IAM service account API to automatically rotate your service account keys. You can rotate a key by creating a new key, switching applications to use the new key and then deleting the old key. Use the serviceAccount.keys.create() and serviceAccount.keys.delete() methods together to automate the rotation. The GCP-managed keys are rotated approximately once a week.
Use the serviceAccount.keys.list() method to audit service accounts and keys.

Using service accounts with Compute Engine

Compute Engine instances need to run as service accounts to have access to other Cloud Platform resources. To make sure that your Compute Engine instances are secure, consider the following:

You can create VMs in the same project with different service accounts. To change the service account of a VM after it's created, use the instances.setServiceAccount method.
You can grant IAM roles to service accounts to define what they can access. In many cases you won’t need to rely on scopes anymore. This gives you the advantage of being able to modify permissions of a VM’s service account without recreating the instance.
Since instances depend on their service accounts to have access to Cloud Platform resources, avoid deleting service accounts when they are still used by running instances. If you delete the service accounts, the instances may start failing their operations.

Best practices

Restrict who can act as service accounts. Users who are Service Account Users for a service account can indirectly access all the resources the service account has access to. Therefore, be cautious when granting the serviceAccountUser role to a user.
Grant the service account only the minimum set of permissions required to achieve their goal. Learn about Granting roles to a service account for specific resources.
Create service accounts for each service with only the permissions required for that service.
Use the display name of a service account to keep track of the service accounts. When you create a service account, populate its display name with the purpose of the service account.
Define a naming convention for your service accounts.
Implement processes to automate the rotation of user-managed service account keys.
Take advantage of the IAM service account API to implement key rotation.
Audit service accounts and keys using either the serviceAccount.keys.list() method or the Logs Viewer page in the console.
Do not delete service accounts that are in use by running instances on Google App Engine or Google Compute Engine.