Service accounts should not hold admin, Owner or Editor roles

A service account is an identity used by software. If it holds Owner, Editor or an administrator role, anyone who steals its key or gains control of the workload running as it inherits those broad rights across the project. Software is also more likely to be compromised than a person with a hardened login.

Google's best-practice pages recommend granting service accounts only the roles they need and avoiding the basic roles. They are listed under sources.

In the Google Cloud console, open IAM & Admin, then IAM. Filter the principals to service accounts and look for the roles Owner, Editor, or roles whose name ends in admin. The default Compute Engine service account is worth checking first, since it may have been granted Editor when the project was created.

This read-only command lists service-account bindings with those roles on one project:

gcloud projects get-iam-policy <project-id> \
  --flatten='bindings[].members' \
  --filter='bindings.members:serviceAccount AND (bindings.role:roles/owner OR bindings.role:roles/editor OR bindings.role:admin)' \
  --format='table(bindings.members,bindings.role)'

Every row returned is a service account with an over-broad role.

Decide what each flagged service account really does, then replace the broad role with narrower predefined roles, or a custom role if none fits. The IAM recommender in the console suggests roles based on actual permission use. Add the new roles first, then remove the old one:

gcloud projects add-iam-policy-binding <project-id> \
  --member='serviceAccount:<name>@<project-id>.iam.gserviceaccount.com' --role='<narrow-role>'
gcloud projects remove-iam-policy-binding <project-id> \
  --member='serviceAccount:<name>@<project-id>.iam.gserviceaccount.com' --role='roles/editor'

ConfigCobra only reports this setting. It never changes your Google Cloud environment; your administrator applies the fix.

Workloads that run as the affected service account may start failing with permission-denied errors if they used a permission that was only available through the broad role. Virtual machines, functions and jobs that use the default Compute Engine service account are the usual place this shows up.

To reduce risk, add the narrow roles before removing the broad one, make the change in a test project first, and watch the logs of the dependent workloads afterwards. Engineers who relied on the service account's power for ad-hoc work will need their own, appropriately scoped access. Teams that own the affected projects should be told about the change window, because a permission-denied error in a background job is easy to miss until a downstream report is late.