Google CloudOverview
It is recommended to configure your instance to not use the default Compute Engine service account because it has the Editor role on the project.
Rationale
The default Compute Engine service account has the Editor role on the project, which allows read and write access to most Google Cloud Services. To defend against privilege escalations if your VM is compromised and prevent an attacker from gaining access to all of your project, it is recommended to not use the default Compute Engine service account. Instead, you should create a new service account and assigning only the permissions needed by your instance.
The default Compute Engine service account is named <projectNumber>[email protected].
Remediation guidance
From Google Cloud Console
- Go to the
VM instancespage by visiting: https://console.cloud.google.com/compute/instances - Click on each VM instance name to go to its details page
- Click
STOPand then clickEDIT - Under the section
Identity and API access, select a service account other than the default Compute Engine service account. You may first need to create a new service account. - Click
Saveand then clickSTART
Using Google Cloud CLI
- Stop the instance:
gcloud compute instances stop <instanceName>
- Update the instance:
gcloud compute instances set-service-account <instanceName> --serviceaccount=<serviceAccount>
- Restart the instance:
gcloud compute instances start <instanceName>
Default Value
By default, Compute instances are configured to use the default Compute Engine service account.
References
- https://cloud.google.com/compute/docs/access/service-accounts
- https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances
- https://cloud.google.com/sdk/gcloud/reference/compute/instances/set-service-account
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Instances are not configured to use the default service account
Connectors
Covered asset types
Expected check: eq []
vms(where: {serviceAccountEmail_CONTAINS: "[email protected]"}) {...AssetFragment}
