GCP project IAM policies that grant roles to personal @gmail.com accounts

Why a personal Gmail account in IAM is an offboarding hole

A consumer Gmail account belongs to the person, not the company. When that engineer leaves, your identity team disables their Workspace or Cloud Identity account, and nothing happens to someone@gmail.com. It keeps every role it was granted on the project. It is also outside your MFA and session policies, and a domain-filtered audit of “who has access” never shows it.

Google built a control for exactly this. The domain-restricted sharing page explains that when it is active, only principals in allowed domains or organizations can be granted IAM roles in your Google Cloud organization. It also notes that organizations created on or after May 3, 2024 have the iam.allowedPolicyMemberDomains constraint enforced by default with their own domain as the only allowed value, so Gmail grants tend to live in older organizations or in projects outside any organization.

Listing Gmail principals on a project

gcloud projects get-iam-policy PROJECT_ID \
  --flatten=bindings \
  --format="value(bindings.role, bindings.members)" | grep -i '@gmail.com'

Each line shows the role and the members holding it. Repeat per project, or run it at folder and organization level with the matching get-iam-policy commands.

How ZopNight arrives at a finding

ZopNight walks each project’s IAM policy while inventorying the account and records whether any binding names a personal Gmail account. The finding is raised on the project when that record is an explicit yes. There is no count threshold: one Gmail member holding one role is enough.

Cases that stay silent

If the policy walk did not complete, ZopNight records nothing for the project rather than “no”, and the rule stays silent until a full read succeeds. Only the project’s own policy is examined, so a Gmail grant made on a folder or the organization is not attributed to the project. Projects whose members all come from your organization’s domain are silent.

An identity-control risk, not a saving

The saving is $0. What is at stake is access that outlives employment, credentials protected only by whatever the individual chose, and a gap in every access review.

Replacing Gmail access with managed identities

1. For each Gmail member, find or create the person’s account in your Workspace or Cloud Identity domain.

2. Grant that account the same roles, or narrower ones.

3. Remove the Gmail binding:

   gcloud projects remove-iam-policy-binding PROJECT_ID \
     --member=user:someone@gmail.com --role=ROLE_NAME

4. Enforce domain-restricted sharing on the organization, using iam.allowedPolicyMemberDomains or the newer iam.managed.allowedPolicyMembers constraint, so new Gmail grants are rejected.