Mitigating the Risk of Default Service Accounts in Google Cloud

Google Cloud has created service accounts to provide secure methods of authentication for non-human identities. These service accounts can request authentication tokens on behalf of a resource, application, or service, granting the access needed to perform various operations. According to the H1 2025 Google Cloud Threat Horizons Report, however, attackers are increasingly leveraging over-privileged service accounts for lateral movement. This blog takes a deeper look at a specific type of service account in Google Cloud, the default service account, and the risks posed when these accounts are present in your organization’s environment. We’ll also describe methods of defending against abuse of service accounts.

Security Benefits of Service Accounts

To better understand the benefits of leveraging service accounts, let’s begin by looking at an example of how different resource types in Google Cloud may need access to each other.

In Figure 1, we see a web server that connects to cloud storage to retrieve static assets. Additionally, the web server connects to an application server that uses Firestore and CloudSQL as part of its operations. The challenge that service accounts seek to solve is how each of these components can authenticate access without providing access to everyone.

With service accounts, policies can be applied to limit access. For example, the service account running on the web server can be granted read-only access to assets in cloud storage as needed to render the website. Similarly, a service account attached to the application server can be given Write access to the CloudSQL server to modify databases.

Along with a more accurate audit trail, service accounts provide several security benefits over the use of an IAM user’s login credentials.

1. Short-Lived Credentials: While service accounts can also use long-term API keys, they alternatively can be authenticated via short-lived tokens. Unlike long-lived credentials, such as API keys or usernames and passwords, even if access to the credentials are obtained, they will only be useful for a short period of time.
2. Automated Credential Management: When using API keys or passwords, the credentials will only change if administrators make the effort to implement credential rotation procedures. This causes increased overhead. With service accounts in Google Cloud, the tokens are automatically rotated and do not require manual maintenance.
3. Least Privilege Control: Using policies assigned to service accounts, access can be restricted to ensure only specific actions can be taken against necessary resources. When these policies are properly implemented, a token that is stolen presents much less risk.

Of course, this all requires organizations to establish proper procedures and policies for service account use. Next, we’ll look at the use of default service accounts, which provide a quick and easy way to generate service accounts but introduce the risk of abuse by threat actors.

Compute Engine Service Accounts

Compute Engine is Google Cloud’s infrastructure-as-a-service (IaaS) product that offers virtual machine instances running in their cloud infrastructure. These virtual machines can be used for a wide variety of purposes, such as for web or application servers (as shown in Figure 1). Historically, to ease the creation of service accounts, default service accounts were created when enabling the Compute API and attached to any newly created virtual machine instances. As of May 2024, this behavior is blocked by default at the organizational level. However,these accounts are still prevalent in many environments that have existed before that constraint became the default.

Without this constraint in place, default service accounts are the default option when creating new compute instances and the default service account is granted the Editor role. The effective permissions granted when requesting a short-lived token for the service account will be limited by the access scope applied on a per-VM basis. There are three access scopes that can be set:

• Allow default access: Includes read-only access to cloud storage, read-only access to container images, and more.
• Allow full access to all Cloud APIs: Grants all permissions (read and write) for data across all services within the project.
• Set access for each API: Fine-grained control specifying specific permissions granted based on a selectable.

Once the access tokens and accounts are configured, the short-lived token can be retrieved on the host from the metadata server. This means that if the attacker gains access to a compute host with an associated default service account, they can obtain the credentials for that service account. A basic attack flow targeting default service accounts is as follows:

1. Compromise compute infrastructure
2. Query metadata server for default service account info
3. Retrieve service account token from metadata server
4. Test IAM permissions for token
5. Use available permissions to further attack

For a VM that set its service account to have an access scope of full access to all cloud APIs, an attacker could perform any actions against any resources at the project level (such as deploying cryptomining VMs or establishing persistence with additional credentials). Even with only the default access, an attacker could read from buckets within the project which may contain confidential information or credentials for other services.

Given this is such a commonly targeted attack vector, it is important for organizations to evaluate their posture, remediate any risks, and implement preventative controls.

Defending Against Default Service Account Abuse

For environments that were created before May 2024, the first step is to identify any existing default service accounts and switch to using custom service accounts with stricter policies. The following gcloud CLI commands can be run to find default service accounts. The first command looks for all default service accounts, while the second narrows down to the riskier “Full Cloud API Access” accounts.

gcloud compute instances list

--filter="serviceAccounts.email~'-compute@developer.gserviceaccount.com'"

gcloud compute instances list

--filter="serviceAccounts.email~'-compute@developer.gserviceaccount.com'

AND serviceAccounts.scopes=('https://www.googleapis.com/auth/cloud-platform')"

Additionally, if your organization was created before May 2024, you need to enable the iam.managed.preventPrivilegedBasicRolesForDefaultServiceAccounts constraint to prevent such accounts from being created again.

Along with the above constraint enablement, there are two more preventative measures worth considering to avoid accidentally introducing risk in future. The first is specific to Kubernetes workloads running on Google Kubernetes Engine. GKE workloads can also lead to default service accounts being provisioned. By enabling Workload Identity Federation, however, IAM policies can be used to grant Kubernetes workloads access to Google Cloud APIs. With this enabled, credentials returned from the metadata server will have no effective permissions.

For all service account usage, the organization should adopt the habit of creating single-purpose service accounts. Unlike how default service accounts are shared across VMs in a project, this means creating service accounts with policies that restrict access to only the specific resources and APIs that are needed. While it may take extensive work to identify all service accounts currently in use and their purposes, in the long-term adopting the habit of single-purpose service accounts will greatly strengthen your security posture.

Additionally, VMs that don’t communicate with other cloud services shouldn’t be configured with service accounts at all. Services accounts are only needed for cloud service-to-cloud service communications.

Learn How to Track Service Account Usage in FOR509

While service accounts may be one of the most common lateral movement vectors leveraged by threat actors on cloud workloads, when properly managed they provide the security benefits discussed in this article. With just a few simple controls and best practices, the threat vector of default and over-permissioned service accounts can be removed.

Given the prevalence of service account abuse in Google Cloud, the new release of SANS FOR509: Enterprise Cloud Forensics and Incident Response includes content covering the topic and four new labs teaching investigators how to track the use of service accounts in logs.

Register for FOR509 here.