GCP Service Account Security: Keys, Impersonation, WIF

The most effective way to secure Google Cloud service accounts is to stop creating downloadable service account keys and replace them with short lived credentials from Workload Identity Federation or service account impersonation. Long lived JSON keys are the single most common cause of Google Cloud credential leaks, and Google's own IAM documentation recommends avoiding them wherever possible.

If you are studying for the Professional Cloud Security Engineer exam or hardening a real GCP environment, service account security is one of the highest impact areas you can work on. This guide explains how service accounts actually work, why keys are dangerous, and the exact controls you should apply.

What a Google Cloud service account really is

A service account is a special kind of Google Cloud principal that represents an application or compute workload rather than a human. It has its own email address, it can be granted IAM roles, and it can be used to authenticate to Google Cloud APIs.

Two things confuse newcomers:

1. A service account is both an identity and a resource. It can be granted access to other resources, and other principals can be granted access to it. That second part is where privilege escalation usually hides.
2. A service account does not always need a key. In most well designed architectures, no key file ever exists.

That second point drives almost every recommendation below.

Why service account keys are the problem

A service account key is a JSON file containing a private key. Anyone who obtains that file can authenticate as the service account, from anywhere in the world, until the key is deleted. Keys do not expire by default, they do not carry device context, and they are trivially easy to copy.

In practice, keys leak through:

• Committed source code and public repositories
• CI/CD environment variables and build logs
• Developer laptops, shared drives, and chat messages
• Container images baked with credentials
• Terraform state files stored without encryption

The blast radius depends entirely on what roles that service account holds. A leaked key attached to an over privileged account is effectively a full compromise of the project. This is the same failure pattern that makes over permissive IAM policies so dangerous in AWS, which we covered in our AWS IAM security best practices guide.

The credential hierarchy: choose the most secure option available

Work down this list and stop at the first option that fits your workload.

Option	Where it fits	Credential lifetime	Key file needed
Attached service account	Workloads running on Compute Engine, GKE, Cloud Run, Cloud Functions	Short lived, auto refreshed	No
Workload Identity Federation	Workloads on AWS, Azure, on premises, GitHub Actions, GitLab, any OIDC or SAML provider	Short lived, exchanged on demand	No
Service account impersonation	Developers and automation that already have a Google identity	Short lived tokens	No
Service account key with expiry	Third party tools that support nothing else	Long lived unless constrained	Yes
Unmanaged service account key	Nowhere. This is the failure state.	Indefinite	Yes

Attached service accounts

If your code runs on Google Cloud, attach a service account to the resource and let the metadata server hand out short lived tokens. Your application uses Application Default Credentials and never touches a key. This is the default answer for GCE, GKE, Cloud Run, and Cloud Functions workloads.

Workload Identity Federation

Workload Identity Federation lets an external workload trade a token it already has for a short lived Google Cloud credential. Google supports federation with workloads running on AWS or Azure, on premises Active Directory, deployment pipelines such as GitHub and GitLab, workloads authenticating with X.509 client certificates, and any identity provider that supports OpenID Connect or SAML 2.0.

The flow looks like this:

1. Your workload obtains a token from its own environment, for example a GitHub Actions OIDC token.
2. It presents that token to Google's Security Token Service through a workload identity pool and provider.
3. Google validates the token against the provider configuration and attribute conditions you defined.
4. Your workload receives a short lived Google Cloud access token.

The critical security control here is the attribute condition. A workload identity pool provider that trusts an entire external issuer without narrowing on repository, branch, or subject is dangerously broad. Always constrain federation to the specific external identities that should be trusted, and use roles/iam.workloadIdentityUser narrowly.

Service account impersonation

Impersonation lets a principal that already has a Google identity request short lived credentials for a service account, without ever holding a key. Grant roles/iam.serviceAccountTokenCreator on the specific service account, not at the project level. This is how developers should access elevated permissions locally, and how a centrally managed service account can be used across projects.

Impersonation grants deserve the same scrutiny as the roles they unlock. If a user can impersonate a service account holding Owner, that user effectively has Owner. Audit roles/iam.serviceAccountTokenCreator and roles/iam.serviceAccountUser bindings as carefully as you audit admin roles.

Enforce it with organization policy

Good intentions do not scale. Enforce the behavior with organization policy constraints applied at the organization or folder level.

• iam.managed.disableServiceAccountKeyCreation blocks the creation of new external service account keys under a project, folder, or organization. Google's Organization Policy recommender will actively suggest enforcing this constraint when it detects that no service account keys have been created.
• iam.managed.disableServiceAccountKeyUpload blocks uploading externally generated public keys.
• iam.disableServiceAccountCreation limits where new service accounts can be created, useful for forcing a centralized model.
• iam.automaticIamGrantsForDefaultServiceAccounts should be disabled so that default service accounts do not automatically receive the broad Editor role.

That last one matters more than most people realize. Default Compute Engine and App Engine service accounts historically received Editor at the project level, which means any workload on that VM inherits sweeping permissions. Disable the automatic grant, then create purpose built service accounts with only the roles each workload needs.

Detect and monitor what you cannot prevent

Prevention will never be complete, so pair policy with detection:

• Security Command Center surfaces findings for anomalous service account impersonation and privilege escalation patterns, along with misconfiguration findings for exposed accounts.
• IAM Recommender analyzes 90 days of usage and recommends removing unused permissions. Run it regularly and act on the recommendations rather than letting them accumulate.
• Cloud Audit Logs record every GenerateAccessToken and SignJwt call. Alert on impersonation of high privilege accounts from unexpected principals or locations.
• Key usage tracking shows the last authentication time for each key, which makes it possible to identify and delete keys nobody is using.

If you want the wider picture of how these services fit together, our Google Cloud security guide covering IAM, SCC, and the PCSE exam walks through the platform level view.

A practical hardening checklist

Work through this in order:

1. Inventory every service account key in the organization and record when each was last used.
2. Delete keys with no recent authentication activity, after confirming ownership.
3. Migrate remaining key based workloads to attached service accounts, Workload Identity Federation, or impersonation.
4. Enforce iam.managed.disableServiceAccountKeyCreation at the organization or folder level.
5. Disable automatic IAM grants for default service accounts, then right size existing default account permissions.
6. Replace broad primitive roles such as Editor with predefined or custom roles scoped to the workload.
7. Narrow workload identity pool provider attribute conditions to specific repositories, branches, or subjects.
8. Audit all serviceAccountTokenCreator and serviceAccountUser bindings.
9. Enable Security Command Center and route impersonation findings to your alerting pipeline.
10. Schedule a recurring IAM Recommender review, quarterly at minimum.

How this connects to zero trust

Everything above is zero trust applied to machine identity. You are replacing a static, network independent secret with a short lived credential that is issued only after the requesting workload proves who it is, from where, and under what conditions. That is the same principle we apply to human identity, extended to code. Our practical zero trust architecture guide covers how the human and machine sides fit into one model.

Frequently asked questions

Are service account keys ever acceptable?

Yes, in narrow cases. Some third party tools and legacy systems can only authenticate with a key file. When that is genuinely the case, use a key with an expiry time, scope the service account to the minimum roles required, store the key in a secret manager rather than on disk, and track its usage so you can retire it when the tool adds support for federation.

What is the difference between Workload Identity Federation and Workload Identity for GKE?

They solve related problems in different places. Workload Identity Federation lets workloads outside Google Cloud, such as those on AWS, Azure, on premises, or in CI pipelines, exchange an external token for Google Cloud credentials. Workload Identity for GKE maps a Kubernetes service account inside a GKE cluster to a Google Cloud service account. Both remove the need for a downloadable key.

Does disabling service account key creation break existing keys?

No. The iam.managed.disableServiceAccountKeyCreation constraint prevents new keys from being created. Keys that already exist continue to work until you disable or delete them. That is why the inventory and cleanup steps come before enforcement in the checklist above.

How do I let a developer use elevated permissions without giving them a key?

Grant them roles/iam.serviceAccountTokenCreator on the specific service account and have them use impersonation from the gcloud CLI or client libraries. They authenticate with their own Google identity, then request short lived credentials for the service account. Every impersonation event is recorded in Cloud Audit Logs, so you keep individual attribution.

Which roles should I audit first when hunting for privilege escalation?

Start with roles/iam.serviceAccountTokenCreator, roles/iam.serviceAccountUser, roles/iam.serviceAccountKeyAdmin, and roles/iam.workloadIdentityUser. Each of these lets a principal act as, or obtain credentials for, another identity. Combined with a high privilege service account, any of them can quietly become an escalation path.

Is service account security covered on the Professional Cloud Security Engineer exam?

Identity and access management is a core part of the Professional Cloud Security Engineer exam, and service account handling sits inside it. Expect scenario questions about choosing the right credential type for a workload and applying the correct organization policy constraints. Always confirm current exam content against the official Google Cloud certification page, since exam guides are revised periodically.

Learn this by building it

Reading about workload identity is not the same as configuring a pool, wiring attribute conditions, and watching a pipeline authenticate without a key file. PrimeSec Academy's 20 week Cloud and AI Platform Security Engineer program puts you in real AWS, Azure, and Google Cloud environments with hands on labs, 36 projects, and a defended capstone.

See what you will build in the curriculum, or enroll now to start.

External references: Google Cloud best practices for using service accounts securely and Restrict IAM service account usage with organization policy.