Google CloudOverview
A service account is a special Google account that belongs to your application or a VM, instead of to an individual end user. Your application uses the service account to call the Google API of a service, so that the users aren't directly involved. It's recommended not to use admin access for Service Account.
Rationale
Service accounts represent service-level security of the Resources (application or a VM) which can be determined by the roles assigned to it. Enrolling Service Account with Admin rights gives full access to assigned application or a VM. A Service Account Access holder can perform critical actions like delete, update change settings etc. without the intervention of user. For this reason, it is recommended not to have Admin rights.
Impact
Removing *Admin or *admin or Editor or Owner role assignments from service accounts may break functionality that uses impacted service accounts. Required role(s) should be assigned to impacted service accounts in order to restore broken functionalities.
Remediation guidance
From Google Cloud Console
- Go to
IAM & admin, and thenIAMusing https://console.cloud.google.com/iam-admin/iam - Under
VIEW BY PRINCIPALS, identifyUser-Managed user createdservice accounts with roles containing*Adminor role matchingEditoror role matchingOwner - Click the
Deletebin icon to remove role from member (service account in this case)
From Google Cloud CLI
Retrieve details about the IAM policies:
gcloud projects get-iam-policy <projectID> --format json > iam.json
Using a text editor, remove the role which contains roles/*Admin or roles/*admin or matches roles/editor or matches roles/owner. Add a role to the bindings array that defines the group members and the role for those members.
Update the project's IAM policy:
gcloud projects set-iam-policy <projectID> iam.json
Default Value
By default, there are no roles assigned to User Managed User created service accounts.
References
- https://cloud.google.com/sdk/gcloud/reference/iam/service-accounts/
- https://cloud.google.com/iam/docs/understanding-roles
- https://cloud.google.com/iam/docs/understanding-service-accounts
Addititonal information
User Managed (and not user-created) default service accounts have the Editor (roles/editor) role assigned to them to support GCP services they offer.
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.
Ensure Service Account has no Admin privileges
Connectors
Covered asset types
Expected check: eq []
{
iamServiceAccounts(
where: {
hasIAMRole_SOME: {
OR: [
{ name: "roles/owner" }
{ name: "roles/editor" }
{ name_CONTAINS: "admin" }
]
}
}
) {
...AssetFragment
}
}
