Offboarding an engineer from GCP: the access checklists miss
To offboard an engineer from GCP, suspend their Cloud Identity or Workspace account, then revoke what that doesn’t touch: delete any service account keys they created, remove their IAM policy bindings across projects, folders, and the organization, and clear OAuth grants, GKE access, and repository credentials. The mistake most teams make is assuming suspension cut off their access. On GCP it doesn’t, and the service account keys are where offboarding quietly fails.
Why suspending the Workspace account isn’t enough
Suspending someone in Cloud Identity or Google Workspace stops them signing in. It does not delete a service account key they created, and it doesn’t always invalidate OAuth refresh tokens they authorized. Those keep working, because they weren’t tied to the human login you just suspended.
That’s the gap between IT offboarding and GCP offboarding. The IT checklist covers the Workspace seat. The IAM and service-account layer underneath it is where an engineer can still reach production after they’ve left.
The GCP access to revoke
Go through what the engineer accumulated across your projects:
User-managed service account keys they created, deleted explicitly. Their IAM policy bindings, and these can exist at project, folder, and organization scope, so check all three rather than one project. OAuth authorized applications and any gcloud application-default credentials sitting on their machine. GKE cluster access through kubeconfigs. Access to Cloud Source Repositories, Artifact Registry, and Cloud Build triggers tied to them. And any keys or secrets they stored in Secret Manager.
Service account keys are the big one
User-managed service account keys are the credential GCP offboarding misses most. They’re long-lived JSON keys, they don’t expire, and an engineer can create them for a service account without anyone noticing. One generated for a script months ago still authenticates today. List keys per service account and delete the user-managed ones, and consider an organization policy that disables service account key creation entirely, so the gap can’t reopen. Prefer service account impersonation or Workload Identity over handing out keys in the first place.
Speed matters more than completeness
For a sensitive departure, delete the service account keys and remove any high-privilege IAM bindings first, especially the primitive Owner and Editor roles, which are broad. Every minute a working key lingers after someone leaves is an open door. Getting the worst of it done in five minutes beats a perfect sweep in five hours.
The better default: less to revoke
Offboarding on GCP is hard because bindings and keys end up scattered across projects, folders, and the org. The fix isn’t a better checklist, it’s fewer of them existing at all. Grant access per task so it expires, lean on short-lived tokens from impersonation rather than long-lived keys, and use IAM Conditions with expiry timestamps. Moving toward zero standing privileges means there’s barely anything left to clean up when someone goes.
The same problem exists on other clouds with different mechanics: see offboarding from AWS and Azure.
Where Korvalis fits
On GCP the leftover problem is service account keys. Korvalis leans on short-lived, expiring access instead, so there’s little standing credential left when someone leaves, and it watches live sessions to cut off a destructive command mid-run, closing the window before a full key sweep is even done. It runs inside your own Google Cloud project.
Frequently asked questions
Does suspending a Workspace account revoke GCP access? Not fully. It stops sign-in, but user-managed service account keys and some OAuth tokens keep working until deleted or revoked.
What do people forget to revoke? Service account keys, IAM bindings at project, folder, and org scope, OAuth grants, gcloud credentials, GKE access, and repository access. The service account keys are the biggest miss.
How fast should you revoke? Delete service account keys and remove high-privilege bindings first, ideally within minutes for a sensitive departure, then do the full sweep.
If you’d rather have little left to revoke, see how Korvalis handles access or join the waitlist.