# Workspace and Google Cloud together: one identity, one set of groups, no shared passwords

Published: 2026-10-30  
Author: Guanacos Tech (https://guanacostech.com)  
Canonical: https://guanacostech.com/blog/workspace-and-google-cloud-together-sso-groups

> Grant Google Cloud access through your Workspace groups, find every direct grant and stale principal in a project, and close all of it when someone leaves.

**Short answer:** Google Workspace and Cloud Identity accounts are the same identities Google Cloud uses, so a Workspace user's email address is already a valid IAM principal. Grant project roles to Google Groups built around job functions rather than to individuals, keep collaboration and mailing-list groups out of IAM, and remember that suspending the Workspace account is what ends Cloud access.

Say a 14-person logistics company brings in a contractor to build one internal app on Google Cloud. The contractor is added to the project in March, finishes the work, and stops invoicing in June. In October the owner asks us to look at the bill, and the first line in the project's access list is a personal Gmail address holding Editor on everything. The contractor was never in the company's Workspace at all: they were granted a role straight on the project, with an account the company never controlled.

That gap is the subject here. Workspace and Google Cloud present as two products with two consoles, so access gets granted twice, and only one of the two grants gets cleaned up when somebody leaves.

## One account, two consoles

Google Cloud does not keep a user directory of its own. The identities it uses are the Google accounts your Google Workspace or Cloud Identity domain already manages, and Google's documentation treats the two products as equivalent for managing users, groups and authentication.

The practical consequence is that the mailbox you created in the Admin console is already a valid Google Cloud principal. You do not invite it into Cloud and you do not create a second account for it. You grant a role to the email address, and sign-in, password policy, recovery and 2-Step Verification stay where your admins already manage them. It also removes the reason teams share one Cloud login.

Two details catch people out. First, aliases: if you grant a role to someone's email alias, the grant lands on their primary address instead, which is what shows up in the policy. If your team gave out `sales@` as an alias for a person, do not use it in IAM. Second, the group email address works as a principal in exactly the same way, which is what makes the rest of this worth doing.

### The super admin is already your most powerful principal

The super administrator who creates the Google Cloud organization is given the Organization Administrator role automatically, and Google's guidance is to delegate that role to a different user or a group so duties are separated. Worth understanding what the delegation does not buy you: a Workspace super admin can implicitly modify the IAM allow policy at the organization node, and super admin access extends to deleting the account and the organization with it. Separation of duties here gives you an audit trail and a habit, not a lock. That is the real reason super admin accounts should not be the ones anyone works in day to day.

## Groups are the unit of access, and not every group should be

Google's IAM guidance is direct about this: create an access group for each job function, grant that group the roles the function needs, and then manage people by adding and removing members. Granting roles to individuals one at a time is what makes an access review unanswerable, because the only way to describe who can reach production becomes a list of names with no reason attached to any of them.

The part small teams get wrong is reusing the groups they already have. The distribution lists in daily use, `everyone@`, `finance@`, the one the warehouse reads, are collaboration groups, and Google's best-practices page says plainly that collaboration groups should not be used for access control. Membership of a mailing list drifts for reasons that have nothing to do with who should be able to drop a database. When an organizational group genuinely has to appear in access control, the documented pattern is to nest it inside an access group and grant only limited roles there, such as Organization Viewer.

So a 14-person company ends up with a short, boring set of access groups: one for the people who deploy, one for the people who read logs and dashboards, one for whoever handles billing, one for break-glass. Each gets its role at the smallest scope that works. Keep group editing in few hands, but never one, or the group goes unmanaged the first time that person is away.

## What we check first on a client project

Before changing anything we want the current answer to one question: which human identities can reach what. Cloud Asset Inventory answers it across the whole organization. The account running this needs `cloudasset.assets.searchAllIamPolicies` on the scope you pass.

```
gcloud asset search-all-iam-policies \
  --scope=organizations/ORG_ID \
  --query="policy:ana@example.com" \
  --flatten="policy.bindings[]" \
  --format="table(resource, policy.bindings.role)"
```

Per project, the allow policy itself is quicker to read:

```
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[]" \
  --filter="bindings.members:user:ana@example.com" \
  --format="table(bindings.role)"
```

One caveat on the second command, and it is the one that hides problems: it returns the roles granted on that project, not the roles inherited from a folder or from the organization. A project that looks clean can be wide open one level up, which is why we start at the organization scope.

Then we count. How many principals in the policy start with `user:` and how many with `group:`. On a project that has never been reviewed the ratio is usually the wrong way round, and every `user:` entry is a question: is this person still here, is this an account we manage, and would anyone notice if that changed.

### The entries that start with deleted:

When a Google account is deleted, Google Cloud does not drop its role bindings. The principal is rewritten in the policy as `deleted:user:someone@example.com?uid=...` and the binding stays where it was. Restore the account and the entry reverts to `user:` with the role intact. A new account created on the same address inherits nothing. So these entries grant nobody access, and they read as history: people who once had a role nobody removed. Clean them up with `remove-iam-policy-binding`, passing the full `deleted:` string, and know the trade: remove the binding and then undelete the account, and the role is not restored.

## Offboarding that actually closes the door

Access to a Google Cloud project does not live in one place, which is why "we removed them from Workspace" and "they still have access" can both be true. These are the places to look, in the order we work through them.

| Where the access lives | How you see it | What actually removes it |
| --- | --- | --- |
| The Workspace or Cloud Identity account | The user in the Admin console | Suspend first, delete later, after data transfer |
| Membership in an access group | The group's member list | Removing the member, or a membership expiry |
| A role granted to the person directly | Their address in a project's allow policy | Removing that binding on every resource that has it |
| A role granted through an alias | The **primary** address in the policy | Removing the binding for the primary address |
| A service account they created | A service account in the project | Giving it a current owner, then disabling it if nothing uses it |
| An account you do not manage | A personal address in the policy | Removing the binding; there is nothing else you control |

The order is deliberate. Suspending blocks sign-in and keeps the data in place, which is what you want on the day somebody leaves. A suspended account is billed the same as an active one, so if the mailbox has to be kept for retention, move it to an Archived User licence instead of leaving a full licence parked. Deleting is the irreversible step: the Admin console lets you restore a deleted user for up to 20 days (checked 30 October 2026), and after that untransferred data is gone. Transfer Drive ownership before you delete, and note that transferring files changes the owner without changing who else can see them.

The last row is the contractor from the opening. A personal Google account holding a role on your project is access you cannot revoke at the identity layer, because you do not own the identity. The only lever is the binding. That is the argument for giving contractors a managed account in your own domain, inside an access group, for the length of the engagement, and treating the licence cost as the price of closing it in one action.

## Two-Step Verification, and why it needs checking twice

2-Step Verification deployed from the Admin console is recognized by Google Cloud, so an account you have forced into 2SV signs in to the Cloud console under the same requirement. Google Cloud also runs its own 2SV requirement for the Cloud console and the Firebase console, with start dates that depend on the account type, and Google's documentation is explicit that the Workspace requirement is a separate one. Accounts signing in through a third-party identity provider are handled differently again, and organizations on Cloud Identity without SSO can turn the Cloud enforcement off at the organization level, which Google does not recommend. Read the requirement page for your own account type instead of assuming the Admin console setting covered it.

## What we set up so it stays true six months later

An access model built correctly once and never checked again becomes a list of people who used to work there. Two mechanisms do most of the keeping.

Membership expirations put an end date on a group membership so that access lapses on its own. The feature needs Google Workspace Enterprise or Cloud Identity Premium (checked 30 October 2026) and it applies to the member role only: owners and managers cannot carry an expiry. Group owners get an email 72 hours before one lands. Google's own best-practices guidance is to let access-group memberships expire by default, with one exception it names clearly: do not apply it to service accounts, because removing a service account from a group can interrupt whatever it was running.

Then a review on a date somebody owns. Read the organization-scope policy, not the project. Look for roles granted during an incident and never taken back. Look for `deleted:` entries that appeared since last time, because each one is a person who left while holding a role, which tells you the offboarding checklist is missing a step.

## How Guanacos Tech helps

We do this as one fixed piece of work: inventory every human principal at the organization scope, build access groups around the job functions the business actually has, move the direct grants onto those groups, and connect the Workspace offboarding checklist to the Cloud side, so suspending an account is the only thing anyone has to remember. The output is an access list the owner can read without us in the room, plus the break-glass path written down.

If the people who can reach your Google Cloud projects should be the people who currently work at your company, that is [Google Cloud consulting for small teams](https://guanacostech.com/google-cloud). Book a 30-minute call and we will tell you which direct grants and unmanaged accounts we would move first, and in what order.

## Sources

- [Google Cloud: Identity management for Google Cloud](https://docs.cloud.google.com/iam/docs/google-identities)
- [Google Cloud IAM: Best practices for using Google groups](https://docs.cloud.google.com/iam/docs/groups-best-practices)
- [Google Cloud IAM: Understanding allow policies](https://docs.cloud.google.com/iam/docs/allow-policies)
- [Google Cloud: Super administrator account best practices](https://docs.cloud.google.com/resource-manager/docs/super-admin-best-practices)
- [Cloud Asset Inventory: Search for IAM allow policies on resources](https://docs.cloud.google.com/asset-inventory/docs/search-allow-policies)
- [Cloud Identity: Managing membership expirations](https://cloud.google.com/identity/docs/how-to/manage-expirations)
- [Google Workspace Admin Help: Delete or remove a user from your organization](https://support.google.com/a/answer/33314)
- [Google Cloud: 2-step verification requirement for Google Cloud](https://docs.cloud.google.com/docs/authentication/mfa-requirement)

## Frequently asked questions

### Do I need Cloud Identity if I already pay for Google Workspace?

No. Google Cloud uses the accounts your Workspace domain already manages, and Google's documentation treats Workspace and Cloud Identity as equivalent for managing users, groups and authentication. Cloud Identity is the standalone option for teams that want managed Google accounts without the Workspace apps.

### If I delete a user in the Admin console, does their Google Cloud access disappear?

Their ability to sign in does, which is what matters on the day. The role binding itself stays in the project's allow policy, rewritten as a deleted principal with a uid. Restoring the account restores the role, a new account on the same address inherits nothing, and you can remove the stale entry yourself.

### Can I use our existing everyone@ group to grant access?

Google's IAM best-practices guidance says collaboration groups should not be used for access control, because mailing-list membership changes for reasons unrelated to access. Create separate access groups per job function. If an organizational group must appear, nest it inside an access group and grant only limited roles such as Organization Viewer.

---

Guanacos Tech is an independent consultancy with Google-certified engineers: email deliverability, Google Workspace and Google Cloud, in English and Spanish. Book a free 30-minute call: https://calendar.app.google/pq2seCCcch9U2GFV8