How to give a contractor temporary GCP access (without a service account key)
To give a contractor temporary GCP access, let them impersonate a scoped service account rather than handing over a key. You grant their identity the Service Account Token Creator role on a task-scoped service account, and they generate short-lived tokens that expire in about an hour, no key ever changes hands. Handing over a service account key is the common shortcut, and it’s the one that becomes a standing credential nobody remembers.
Why handing over a key is the wrong move
A service account key is a long-lived JSON credential. It doesn’t expire, nothing prompts you to remove it, and once a contractor has the file, you’ve lost track of where it lives. When the engagement ends, that key still authenticates, and it’s now sitting on a machine outside your team. Service account keys are the single biggest offboarding gap on GCP for exactly this reason.
So the goal is to give a contractor access without ever issuing a key. Google Cloud gives you two clean ways to do that.
Service account impersonation
Create a service account scoped to the task, and grant the contractor’s identity the Service Account Token Creator role on it. They then generate short-lived access tokens for that service account with gcloud, using impersonation, without ever holding the underlying key. The tokens expire in about an hour, and when you remove their impersonation permission, their access stops immediately. For an external identity that isn’t in your directory, Workload Identity Federation lets them impersonate without a key too.
Time-bound IAM conditions
If you’d rather grant a role directly, attach an IAM Condition with an expiry timestamp to the binding. The access simply stops applying after the time you set, so the grant cleans itself up. It’s a good fit when impersonation is more machinery than a small task needs, and it still avoids handing over anything long-lived.
Skip the plumbing: access that expires
Both native paths are the right idea, and both take setup to do per contractor. That’s why teams fall back to the key they shouldn’t hand out. The pattern underneath them is just-in-time access: access granted for a task, expiring on its own, with no per-contractor plumbing each time and no key to leak.
Where Korvalis fits
A contractor is working in an unfamiliar project, which is where a wrong command is most likely. Korvalis covers both halves on GCP: access that expires by itself, so there’s no lingering key or binding, and a watch on the live session that cuts off a destructive command before it lands, whoever’s behind it, an engineer, a stolen credential, a contractor, or an AI agent. It runs inside your own Google Cloud project. When the work wraps up, offboarding an engineer from GCP covers the keys and bindings people forget.
Frequently asked questions
How do I give a contractor temporary GCP access? Let them impersonate a scoped service account, so they generate short-lived tokens that expire in about an hour, or grant a role with a time-bound IAM Condition.
Should I give them a service account key? No. It’s a long-lived credential that doesn’t expire and is the thing people forget to delete. Prefer impersonation or a time-bound binding.
How do I revoke their access? Remove the impersonation permission or the role binding. Short-lived tokens and expiring conditions mean access largely ends on its own, with no key to hunt down.
If temporary GCP access without a key sounds right, see how Korvalis does it or join the waitlist.