What Is a Service Account?
A service account is a special kind of Google identity, identified by an email address like [email protected], that represents a workload (an application, VM, or automated pipeline) rather than a human user. Like any principal, a service account can be granted IAM roles on resources, and it can also be granted permission to call GCP APIs on its own behalf. Unlike a human user, a service account has no password and typically authenticates using short-lived tokens obtained automatically from the metadata server (when running on GCP compute like Compute Engine, GKE, or Cloud Run) or via a downloaded JSON key file for workloads running outside Google Cloud.
Cricket analogy: A service account is like a designated 12th man on the IPL squad — an official identity registered with the league, empowered to perform a specific role like fielding substitute, but never the public face of the team like a human captain would be.
Keys, Impersonation, and Attaching Identity to Compute
Downloadable JSON keys are long-lived credentials that, if leaked, grant whoever has them the service account's full permissions indefinitely, which is why Google strongly recommends avoiding them wherever possible. The safer alternatives are: attaching a service account directly to a compute resource (VM, GKE pod, Cloud Run service) so it authenticates via the metadata server with automatically rotated short-lived tokens, or using service account impersonation, where a human or another service account with the roles/iam.serviceAccountTokenCreator permission requests a short-lived access token for the target service account without ever holding a key. For workloads running outside GCP (like on-prem or another cloud), Workload Identity Federation lets you exchange an external identity token (e.g., from AWS or an OIDC provider) for GCP credentials, eliminating the need for a downloaded key entirely.
Cricket analogy: A long-lived JSON key is like handing out a permanent, non-expiring team pass that works forever if lost, while impersonation is like a steward checking your ID fresh at the gate for one match at a time before issuing temporary access.
Service Account Best Practices
Best practice is to create a dedicated service account per workload or microservice rather than sharing one broadly-scoped account across many applications, so a compromise of one workload's credentials doesn't expose unrelated systems; this also makes IAM audit logs meaningfully attributable to a specific application. Grant each service account only the predefined or custom roles it needs on the specific resources it touches, disable or delete unused service account keys regularly (Cloud Asset Inventory and IAM Recommender both surface stale keys), and use Organization Policy constraints like iam.disableServiceAccountKeyCreation to prevent teams from creating downloadable keys in the first place when they aren't required.
Cricket analogy: One service account per workload is like each fielding position — wicketkeeper, slip, cover — having its own designated player rather than one all-purpose substitute covering every role, so a mistake in one position doesn't compromise the whole team.
# Create a dedicated service account for a workload
gcloud iam service-accounts create billing-worker \
--display-name="Billing pipeline worker"
# Grant it a narrow predefined role on a specific bucket, not the whole project
gsutil iam ch \
serviceAccount:billing-worker@my-project.iam.gserviceaccount.com:roles/storage.objectViewer \
gs://billing-exports
# Impersonate the service account to get a short-lived token instead of downloading a key
gcloud auth print-access-token \
--impersonate-service-account=billing-worker@my-project.iam.gserviceaccount.comWhen running on Compute Engine, GKE, or Cloud Run, attach the service account directly to the resource so it authenticates via the metadata server automatically; this is the recommended default and avoids key management entirely for workloads inside GCP.
A leaked service account JSON key does not expire on its own and can be used from anywhere until it is explicitly disabled or deleted; treat any committed key found in a git repository as compromised and rotate it immediately, then audit Cloud Audit Logs for unauthorized use.
- A service account is a non-human identity representing a workload, identified by a unique email address.
- Service accounts authenticate via metadata-server tokens when attached to compute, or via JSON keys otherwise.
- Downloadable JSON keys are long-lived and risky if leaked; avoid them when a safer alternative exists.
- Service account impersonation issues short-lived tokens without ever distributing a key file.
- Workload Identity Federation lets external workloads authenticate to GCP without any GCP-issued key.
- Create a dedicated, narrowly-scoped service account per workload rather than sharing broad accounts.
- Org Policy constraints can disable service account key creation organization-wide to close off a whole risk category.
Practice what you learned
1. What identifies a GCP service account, distinguishing it from a human user account?
2. Why does Google recommend avoiding downloadable JSON service account keys when possible?
3. What permission is required to impersonate a service account and obtain a short-lived token?
4. What does Workload Identity Federation allow?
5. What is the recommended practice regarding the number of service accounts per workload?
Was this page helpful?
You May Also Like
IAM in GCP
How Google Cloud's Identity and Access Management system controls who can do what on which resources, using roles, policies, and the principle of least privilege.
Cloud KMS Basics
An introduction to Google Cloud Key Management Service for creating, managing, and using encryption keys to protect data at rest.
Cloud SQL Basics
An introduction to Google Cloud SQL, GCP's fully managed relational database service for MySQL, PostgreSQL, and SQL Server.