Users should not hold Service Account User or Token Creator at project level

Both roles let a person act as a service account. At project level, that means acting as every service account in the project, including ones with much higher privileges than the person has, now or in the future. Granting the role on the specific service account keeps the reach small. Google explains this in its guidance: best practices for service accounts and service account permissions.

A common way this goes wrong is a convenience grant: someone needs to deploy one Cloud Run service as a specific service account, receives the role on the whole project, and the grant stays long after the task is done. Every service account created later in that project is silently included.

In the Google Cloud console open IAM & Admin, then IAM, and filter the role column for Service Account User and Service Account Token Creator. Any user listed there at project level is a finding. Read-only command:

gcloud projects get-iam-policy <project-id> \
  --flatten="bindings[].members" \
  --filter="bindings.role:(roles/iam.serviceAccountUser OR roles/iam.serviceAccountTokenCreator)" \
  --format="table(bindings.role, bindings.members)"

For each user found, first note which service account they really need, then grant the role on that service account only and remove the project-level binding.

gcloud iam service-accounts add-iam-policy-binding <sa-email> \
  --member="user:<user-email>" --role="roles/iam.serviceAccountUser"
gcloud projects remove-iam-policy-binding <project-id> \
  --member="user:<user-email>" --role="roles/iam.serviceAccountUser"

Repeat with roles/iam.serviceAccountTokenCreator where needed. ConfigCobra only reads your environment and never changes it; the steps below are for you or your administrator to run.

People who deploy workloads that run as a service account, or who impersonate one for testing, lose that ability on service accounts they were not granted. Grant the narrow binding before removing the broad one so nobody is blocked. Running workloads and the service accounts themselves are not affected.

To avoid surprises, list the current bindings across your projects first, ask each person which service account they really use, and add the narrow bindings before you remove the broad ones. Review at the same time whether the person still needs to act as a service account at all. The remediation impact view in ConfigCobra lists the affected identities and resources before you apply a fix.