Google CloudOverview
It is recommended to assign the Service Account User (iam.serviceAccountUser) and Service Account Token Creator (iam.serviceAccountTokenCreator) roles to a user for a specific service account rather than assigning the role to a user at project level.
Rationale
A service account is a special Google account that belongs to an application or a virtual machine (VM), instead of to an individual end-user. The application/VM-Instance uses the service account to call the service's Google API so that users aren't directly involved. In addition to being an identity, a service account is a resource that has IAM policies attached to it. These policies determine who can use the 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 have access. Similarly, SSH access to a Compute Engine instance may also provide the ability to execute code as that instance/Service account.
Based on business needs, there could be multiple user-managed service accounts configured for a project. Granting the iam.serviceAccountUser or iam.serviceAccountTokenCreator roles to a user for a project gives the user access to all service accounts in the project, including service accounts that may be created in the future. This can result in elevation of privileges by using service accounts and corresponding Compute Engine instances.
In order to implement least privileges best practices, IAM users should not be assigned the Service Account User or Service Account Token Creator roles at the project level. Instead, these roles should be assigned to a user for a specific service account, giving that user access to the service account. The Service Account User allows a user to bind a service account to a long-running job service, whereas the Service Account Token Creator role allows a user to directly impersonate (or assert) the identity of a service account.
Impact
After revoking Service Account User or Service Account Token Creator roles at the project level from all impacted user account(s), these roles should be assigned to a user(s) for specific service account(s) according to business needs.
Remediation guidance
From Google Cloud Console
- Go to the IAM page in the GCP Console by visiting: https://console.cloud.google.com/iam-admin/iam.
- Click on the filter table text bar. Type Role:
Service Account User - Click the
DeleteBin icon in front of the roleService Account Userfor every user listed as a result of a filter. - Click on the filter table text bar. Type Role:
Service Account Token Creator - Click the
DeleteBin icon in front of the roleService Account Token Creatorfor every user listed as a result of a filter.
Using Google Cloud CLI
- Using a text editor, remove the bindings with the roles/iam.serviceAccountUser or roles/iam.serviceAccountTokenCreator.
- Update the project's IAM policy:
gcloud projects set-iam-policy <projectID>
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.
IAM users are not assigned the Service Account User or Service Account Token Creator roles at project level
Connectors
Covered asset types
Expected check: eq []
GCP110IAM6{...AssetFragment}
