Service Account FAQs

What are Service Accounts? What are best practices for using them?

To get a basic overview of Service Accounts (SAs), we recommend reading Google’s official guidance on best practices for service accounts.

How should I locate service accounts in my project and use them?

You can find all the service accounts in your project by navigating to the Service Accounts IAM page. You'll see there are a number in there. We recommend partners either use the bq-partner service account or submit a ticket to help@techallies.org to request a new service account be generated. In your ticket, please include how you want to use the service account so we can permission it appropriately. We typically recommend one service account per pipeline/script/etc., so that you can easily troubleshoot who is running what in your project. For service account keys, you can read more here. Please note that an admin in your PAD project must approve all new service account and service account key requests; please cc them on your ticket so we can get that approval. 

Is there a place to identify all the various Google APIs that can be accessed via a service account?

There is! If you open your GCP Console, go to IAM > Service Accounts and click on the Service Account; under “Permissions,” there’s a heading that says “Resources this service account can access.”

You can also use the Policy analyzer: Policy Analyzer for IAM policies  |  Policy Intelligence  |  Google Cloud

Google seems to limit the number of service keys to 10 per role - is that a configuration that can be changed?

Bottom line: No, it can’t be changed, and we also recommend limiting the number of keys you generate for a SA to far fewer than 10 (ideally just one).

Service account keys should only be considered as a last resort. You should reconsider your use case if you are close to having 10 active keys. You can read more about Google's guidance here.

Service accounts are intended for use by applications and other non-human users. As a result, there is usually no need to create multiple keys. Each service account is intended for use by a single application in a specific environment. It is generally recommended to assign a single key to each service account to provide only the necessary access permissions. This ensures that the service account can only perform the actions it is authorized to do and limits the risk of unauthorized access.

To access GCP, human users should authenticate themselves using OAuth. This can be done by logging into the GCP console via a browser or running 'gcloud auth login' on the terminal. However, if you want a specific action to be performed from a service account instead of a user, such as creating a BigQuery object with the "owner" listed as a service account rather than a human user, we recommend using service account impersonation. This process does not require a key. Instead, you can use your regular Google login, which has permission (via an IAM role) to impersonate one or multiple service accounts.

If multiple users or processes run the same service account, is there any way to determine who or what is taking those actions? (For example, if we want to monitor usage by different entities.)

It is not possible to monitor this activity. When multiple users share a service account, it becomes risky because their actions make it difficult to identify the actual user, whether it is an automated process, a human using a key, or a human using service account impersonation.

It might be tempting to think about service accounts as being a mechanism for granting access to GCP resources, but this is not quite accurate. Instead, IAM role bindings are the preferred method for managing which users (or SAs) can take which actions on which resources. 

If you want to grant a group of people the same permissions to resources across one or more projects or lower-level resources (such as a cloud function, bucket, or BQ dataset), you should take the following steps:

1. Identify or create an IAM role with the permissions you want to enable
2. Bind that role to a user, group, service account, or domain

An individual or entity, such as a service account, user, group or domain (referred to as "principals" by Google), can be assigned multiple IAM roles. This is the recommended method for securely authorizing access to GCP resources for humans and automated systems.

PRO TIP: Never use default service accounts.

Sorry, we know this isn’t a question, but it’s an important security best practice!

CTA recommends that users never, ever, ever use default service accounts. By default, Google creates several that have extremely broad access to your project.

App Engine SA is a particularly dangerous default service account. It's easy to accidentally use a Service Account (SA) within Google Cloud Platform without realizing it. For instance, Cloud Functions operate by default as the App Engine SA. 

But why are default SAs dangerous? Well, it's because they have "Editor" access to your project, which is a legacy role that precedes the more advanced IAM we have today. In short, default SAs with the Editor role can perform virtually any action within your project. 

Google created default SAs to make things simpler for users who may not be familiar with IAM, which can admittedly be difficult and frustrating. However, this means that a Cloud Function, which is often exposed to the Internet, can access everything in your account. 

It's important to note that App Engine isn't the only default SA. The Compute Engine SA is another default SA to be wary of. Any SA that exists without being created by a user is most likely a default SA with Editor access that should be avoided at all costs.

What steps can you take to mitigate this risk? The recommended solution to this problem is to “deprivilege” the service accounts - this is what CTA does when we provision GCP projects for PAD users. If you delete them entirely, GCP falls apart (you probably don’t want to find out exactly what this means), so it’s much better to allow them to continue to exist but with all of their permissions removed except for the bare minimum.