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 calls Google APIs assuming the identity of the service account, 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 it need?
• Where will the code assuming 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:

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

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

By treating a service account as a resource, you can grant permission to a user to access that service account. You can grant an owner, editor, viewer, or a Service Account Actor 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:

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 started that job last 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:

1. Create a service account and grant the Service Account Actor role to your employees for the service account. You want to grant this role to employees to whom you want to give permissions to start the job. When you grant the role to the employees, the service account is the resource.

2. Now the employees who have the Service Account Actor role assigned to them can act as the service account to start the job. In this case the service account is the identity.

You can use this pattern in the cases where you use service accounts to perform operations. First you treat the service account as the resource, and then you decide who can use it. Then, those with the Service Account Actor role can use the service account as an identity to act as that service account to run operations.

The following diagram illustrates this example:

Users who are Service Account Actors for a service account can access all the resources for which the service account has access. Therefore be cautious when granting the Service Account Actor role to a user.

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 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.

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. These keys cannot be downloaded. Google will keep the keys and automatically rotate them daily.

• User-managed keys. These keys are created, downloadable, and managed by users.

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 unauthorised 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 daily.

• 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 Actors for a service account can access all the resources for which the service account has access. Therefore be cautious when granting the serviceAccountActor 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.