Google Cloud access should use company-managed accounts, not personal ones

A personal account is owned by the individual, not the company. You cannot enforce password or sign-in policy on it, you cannot suspend it when the person leaves, and you cannot see how it is protected. If such an account holds a role in your projects, its security depends on someone else's choices.

Google describes the managed identity model in Overview of Google identity management. Using managed accounts from Cloud Identity or Google Workspace keeps the joiner and leaver process, sign-in policy and audit trail in one place that your administrators control.

In the Google Cloud console go to IAM & Admin, then IAM, choose the organization from the project picker and review the Principal column. Look for addresses on public mail domains or domains your company does not own.

A read-only command that lists the members with a role at the organization level:

gcloud organizations get-iam-policy <ORGANIZATION_ID> \
  --flatten="bindings[].members" --format="table(bindings.members, bindings.role)"

To search every project and folder under the organization for one domain, use Cloud Asset Inventory:

gcloud asset search-all-iam-policies --scope=organizations/<ORGANIZATION_ID> \
  --query="policy:gmail.com" --format="table(resource, policy.bindings.role, policy.bindings.members)"

Repeat the query for any other consumer domain you see in use.

Portal steps:

• Create a managed account for each person who needs access, in Cloud Identity or Google Workspace.
• In IAM, grant that account the roles the person needs, then remove the personal account's roles.
• Consider the organization policy Domain restricted sharing so that only identities from your own domains can be granted roles in future.

Script (changes your Google Cloud when run; ConfigCobra never changes it):

gcloud projects add-iam-policy-binding <PROJECT_ID> --member="user:<person>@<your-domain>" --role="<role>"
gcloud projects remove-iam-policy-binding <PROJECT_ID> --member="user:<personal-address>" --role="<role>"

Always add the managed account first and confirm it works before removing the old one.

The people behind a personal account must start signing in with their company account. Anything that ran as the personal identity, such as scripts, local tool configuration or saved credentials, stops working after the roles are removed and has to be switched to the new identity or, for automation, to a service account.

If you turn on domain restricted sharing, partners and contractors outside your domains can no longer be granted roles directly; they need a managed account or a group in your domain. ConfigCobra's remediation impact analysis shows the affected identities before you change anything.