User Identity vs Service Account in GCP: Differences, Use Cases, and Best Practices

The simple explanation

Think of a user identity as an employee badge for a person and a service account as an access badge for a piece of software.

Here is the fundamental split:

• User identity: a human who signs in through a browser with a password and MFA.
• Service account: a workload or application that authenticates automatically using short-lived tokens, with no human present.
• Humans should not use service accounts for their own access. Service accounts cannot use interactive login flows.
• The default rule: if something runs automatically, give it a service account. If a person is doing it, they use their own identity.

User identity vs service account at a glance

How it works

User identities

A user identity is a Google Account (Gmail) or a Cloud Identity or Google Workspace account managed by your organisation. When you access the Cloud Console, run gcloud on your machine, or grant access to a colleague, you are working with user identities.

Authentication is interactive. You enter a password, complete MFA if required, and Google issues a short-lived OAuth token. The IAM roles bound to your account determine what you are allowed to do.

# Grant a user IAM access to a project
gcloud projects add-iam-policy-binding my-project \
  --member="user:alice@example.com" \
  --role="roles/viewer"

Service accounts

A service account is a special GCP identity for non-human workloads. It has an email-style identifier and is managed as a resource within a GCP project. It belongs to the project, not to any individual. When a VM, Cloud Run service, or GKE pod runs with an attached service account, GCP automatically issues short-lived credentials through the metadata server. Your code does not need to manage credentials at all.

IAM roles work the same way for service accounts as for users. You grant the service account the roles it needs, and GCP enforces those permissions on every API call.

# Create a service account
gcloud iam service-accounts create backend-api \
  --display-name="Backend API" \
  --project=my-project

# Grant it a narrowly scoped role
gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:backend-api@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

When to use a user identity

Use a user identity when a human is directly taking the action:

• An engineer opens the Cloud Console to create a VM, inspect logs, or review IAM bindings
• A developer runs gcloud commands on their local machine
• An admin grants or revokes IAM access for a colleague
• A team member reviews resources in the Console during an incident
• You are granting access to a new contractor or team member

For local development, developers also authenticate as their user identity through Application Default Credentials so that local code can call GCP APIs. This is covered in the Application Default Credentials section below.

When to use a service account

Use a service account any time automated code needs to interact with GCP:

• A Cloud Run service calling Cloud Storage. Attach a service account with roles/storage.objectViewer to the Cloud Run service. No key file. No environment variable. Application Default Credentials finds the attached account automatically.

• A Compute Engine VM reading from Firestore. Attach a dedicated service account at VM creation time instead of accepting the broad default Compute Engine service account.

• A CI/CD pipeline deploying infrastructure. A GitHub Actions workflow or Cloud Build job should run as a service account with only the deployment roles it needs. Use Workload Identity Federation to avoid creating a key file.

• A GKE pod accessing a GCP API. Workload Identity binds a Kubernetes service account to a GCP service account so each pod has its own narrowly scoped identity.

• A Cloud Function triggered by Pub/Sub. The function runs as a service account and can be granted only the permissions that specific function requires.

• Any scheduled or automated job. Cloud Scheduler, Cloud Tasks, and Cloud Workflows all support running as a service account.

User identity vs service account: key differences

The distinction between a user identity and a service account is not just semantic. It affects how authentication works, how credentials are managed, and what happens when people join or leave your organisation.

Ownership and lifecycle

Authentication mechanism

User identities use interactive authentication: a browser-based OAuth flow with a password and MFA. Service accounts use non-interactive authentication: short-lived access tokens issued by the metadata server (for attached accounts) or via an external token exchange through Workload Identity Federation. No password, no MFA prompt, no browser required.

What happens in IAM

Both types are principals in IAM. You bind IAM roles to them using the same add-iam-policy-binding command. The member prefix differs: user: for user identities, serviceAccount: for service accounts. Apart from that, IAM treats them identically.

Safe for automation

User identities are not safe for automation because they are tied to an individual and require interactive re-authentication when tokens expire. Service accounts are designed for automation: credentials refresh automatically, there is no interactive login requirement, and they can be granted the minimum permissions a workload needs.

Local development vs production

The identity your code uses changes depending on where it runs. Here is how each environment should be set up.

Local development

When a developer runs code on their own machine, they typically authenticate using their user identity through Application Default Credentials:

# Authenticate the gcloud CLI (for running gcloud commands)
gcloud auth login

# Set credentials for GCP client libraries in your application code
gcloud auth application-default login

For more accurate local testing that mirrors what will happen in production, you can impersonate a service account without creating a key file:

# Run local code as if it were a specific service account
gcloud auth application-default login \
  --impersonate-service-account=backend-api@my-project.iam.gserviceaccount.com

This requires the Service Account Token Creator role on the target account. No long-lived key file is created.

Production on GCP

In production, attach a service account to every GCP resource that needs to call GCP APIs. The platform provides credentials automatically via the metadata server. Your application code changes nothing. Application Default Credentials finds the attached service account without any additional configuration.

# Attach a service account to a Cloud Run deployment
gcloud run deploy my-service \
  --region=us-central1 \
  --service-account=backend-api@my-project.iam.gserviceaccount.com \
  --image=gcr.io/my-project/my-service

# Attach a service account to a VM at creation time
gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --service-account=backend-api@my-project.iam.gserviceaccount.com \
  --scopes=cloud-platform

Application Default Credentials

Application Default Credentials (ADC) is the mechanism GCP client libraries use to find the right identity to authenticate as. Your code does not specify credentials directly. The library calls ADC, and ADC works through a lookup chain to find what is available.

The lookup order:

1. The GOOGLE_APPLICATION_CREDENTIALS environment variable: if set, ADC uses the key file it points to
2. Credentials from gcloud auth application-default login: used for local development with your user identity
3. The service account attached to the running GCP resource: the metadata server provides the token automatically
4. The default service account of the GCP environment, if present

On a VM or Cloud Run service with an attached service account, ADC skips the first two steps and resolves the attached account through the metadata server. No environment variables, no key files, no credential configuration in your application code.

# For local development: set your user identity as the ADC source
gcloud auth application-default login

# Check which identity ADC is currently using
gcloud auth application-default print-access-token

# For local testing that mirrors production: impersonate a service account
gcloud auth application-default login \
  --impersonate-service-account=backend-api@my-project.iam.gserviceaccount.com

In production, always prefer an attached service account over setting GOOGLE_APPLICATION_CREDENTIALS to a key file. The attached account approach means there is no credential to store, rotate, or accidentally expose. If you hit authentication errors, see Troubleshooting Authentication Errors for the most common causes and fixes.

External workloads and Workload Identity Federation

When code runs outside GCP (in GitHub Actions, on AWS, on Azure, or on-premises) it cannot use an attached service account because there is no GCP infrastructure to attach to. The traditional workaround was to create a service account key file and store it as a secret in the external system.

Workload Identity Federation eliminates the need for key files by mapping an external identity to a GCP service account:

1. The external workload presents its own credential (a GitHub Actions OIDC token, an AWS IAM role, a Kubernetes service account token)
2. GCP verifies the external credential against a configured identity pool
3. GCP issues a short-lived GCP access token for the mapped service account
4. The workload uses that token to call GCP APIs. No key file was created or stored.

# Create a Workload Identity Pool for GitHub Actions
gcloud iam workload-identity-pools create "github-pool" \
  --project=my-project \
  --location="global" \
  --display-name="GitHub Actions Pool"

# Allow a specific repository's workflow to impersonate a service account
gcloud iam service-accounts add-iam-policy-binding \
  deploy-bot@my-project.iam.gserviceaccount.com \
  --project=my-project \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/attribute.repository/my-org/my-repo"

Best practices

• Humans use user identities. Workloads use service accounts. Keep the two identity types completely separate. Never use a personal account for automation, and do not grant service accounts interactive Console access.

• One service account per workload. A Cloud Run service and the CI/CD pipeline that deploys it should have separate service accounts. This limits the blast radius of any compromise and keeps access auditing straightforward.

• Apply least privilege. Grant each service account only the IAM roles it needs to function. A workload that reads from Cloud Storage should have roles/storage.objectViewer, not roles/editor. See Principle of Least Privilege for a practical guide.

• Prefer attached identities over key files. If your code runs on GCP, attach a service account to the compute resource. This removes the entire class of credential-file vulnerability.

• Use Workload Identity Federation for external workloads. GitHub Actions, AWS workloads, and on-premises pipelines should use federation rather than storing a service account key file as a secret.

• Use impersonation instead of key files for testing. To test what a service account can do, use gcloud —impersonate-service-account rather than downloading a key. See Service Account Impersonation for setup instructions.

• Audit access regularly. Service account roles accumulate. Review what each service account can access quarterly and check for key files that are no longer in use with gcloud iam service-accounts keys list.

• Separate human and workload access patterns. Do not grant a service account the same broad project-level role you might grant a human admin. Service accounts should have narrower, resource-specific permissions matched to exactly what the workload does.