Using Service Accounts Securely Without Key Files

Overview and What You Will Learn

In this lab, you will create a Service Account, attach it directly to a Compute Engine VM so the VM authenticates automatically with no key file at all, and separately use impersonation to generate a short-lived token from your own already-authenticated session - two patterns that both avoid ever downloading a permanent credential.

Why This Matters in Production

A developer downloads a Service Account's JSON key file to test something locally, commits it to a repository by accident, and that key - which never expires on its own - remains a valid, fully working credential until someone notices and manually revokes it. Both patterns in this lab exist specifically to remove the need for that key file to ever be created in the first place.

Core Principles

A Service Account is an identity used by applications and infrastructure, not humans, and GCP provides two genuinely safer alternatives to downloading its permanent key file.

Both patterns eliminate the actual object that causes most Service Account security incidents - a long-lived, downloadable, leakable key file.

Detailed Step-by-Step Practical Lab

1. Create a Project and enable the Compute Engine API:

2. Create a Service Account with no key file generated at all:

3. Grant that Service Account a specific, scoped role:

4. Create a VM, attaching this Service Account directly - the VM will authenticate as this identity automatically:

5. SSH into the VM and confirm it can call GCP APIs using its attached Service Account identity, with no credential file present anywhere on the instance:

6. Now demonstrate impersonation - from your own already-authenticated local session, generate a short-lived token acting as this Service Account, without ever downloading its key:

Note

For impersonation to work, your own user identity must first be granted the roles/iam.serviceAccountTokenCreator role on this specific Service Account - impersonation is itself an IAM-controlled action, not an open capability available to anyone who knows a Service Account's name.

7. Grant yourself that impersonation permission, then retry step 6 to see it succeed:

8. Clean up:

Production Best Practices & Common Pitfalls

Security

Avoid creating and downloading Service Account key files whenever a safer alternative exists. A downloaded key file is a long-lived credential that never expires on its own and can leak exactly like an AWS access key or an Azure service principal secret - attaching the Service Account to the VM directly, or using impersonation, removes that risk entirely.

Tip

If a key file genuinely must exist for a workload running outside GCP entirely (like a script on a developer's laptop or a server in another cloud), treat it with the same care as any other long-lived secret - store it in Secret Manager rather than a local file, and rotate it on a defined schedule.

• --scopes=cloud-platform on the VM creation command controls what the VM's Service Account is technically permitted to attempt - the actual IAM role bindings still determine what it can successfully do. Both need to align for an API call to actually succeed.
• Service Account impersonation is itself governed by IAM, specifically the roles/iam.serviceAccountTokenCreator role - granting this role is equivalent in sensitivity to granting whatever permissions the impersonated Service Account itself has.

Quick Reference & Troubleshooting Commands