Understanding GCP service accounts: three common use-cases
Grace Mollison
Head Cloud Solutions Architects EMEA
If you’re building applications on Google Cloud Platform (GCP), you’re probably familiar with the concept of a service account, a special Google account that belongs to your application or a virtual machine, and which can be treated as an identity and as a resource. Depending on your use case, there are different ways to manage service accounts and to give them access to resources. In this post we will look at some of those common use cases, and help you determine the appropriate operational model for managing your service accounts.
Use case 1: Web application accessing GCP resources
Imagine your users are accessing a web app to which they are authorized via Cloud Identity-Aware Proxy (IAP). They do not require direct access to the underlying GCP resources—just to the web app that utilizes the GCP resources. The web app uses a service account to gain permissions to access GCP services, for example, Datastore. In this case the service account has a 1:1 map to the web app—it’s the identity of the web app. To get started, you create the service account in the GCP project that hosts the web application, and you grant the permissions your app needs to access GCP resources to the service account. Finally, configure your app to use the service account credentials.
Use case 2: Cross-charging BigQuery usage to different cost centers
In this scenario, departmental users query a shared BigQuery dataset using a custom-built application. Because the queries must be cross-charged to the users’ cost center, the application runs on a VM with a service account that has the appropriate permissions to make queries against the BigQuery dataset.
Each department has a set of projects that are labelled such that the resources used in that project appear in the billing exports. Each department also has to run the application from their assigned project so that the queries run against BigQuery can be appropriately cross-charged.
To configure this for each of the departments’ projects, in each of the projects executing the queries, assign the IAM permissions required to run queries against the BigQuery datasets to the application’s service account.
For more information on configuring the permissions for this scenario, see this resource.
Use case 3: Managing service accounts used for operational and admin activities
As a system administrator or operator responsible for managing a GCP environment, you want to centrally manage common operations such as provisioning environments, auditing, etc., throughout your GCP environment.
In this case, you’ll need to create a variety of service accounts with the appropriate permissions to enable various tasks. These service accounts are likely to have elevated privileges and have permissions granted at the appropriate level in the hierarchy. And like for all service accounts, you need them to follow best practices to prevent them from being exposed to unauthorized users. For example, you should add a project lien to the projects where these operational service accounts are created to help prevent them from being accidentally deleted.
Crazy for service accounts
As you can see from the use cases discussed above, one model does not fit all and you will need to adopt the appropriate operational model to fit your use case. We hope walking through these use cases helps you to think about where you logically should place your service accounts. To learn more about service accounts, try one of the following tutorials to see how to use service account credentials with the GCP compute service of your choice:
