Service Accounts

Service accounts are special identities designed for applications, VMs, containers, and automated processes — not for humans. They are one of the most important and most frequently misconfigured aspects of GCP IAM.

---

What Is a Service Account?

A service account is:

• An identity (email address) that represents a workload, not a person
• Used to authenticate applications to GCP APIs
• Managed at the project level
• Can have IAM roles granted to it (like a user)
• Can also have IAM policies on it (controlling who can use it)

Format: <name>@<project-id>.iam.gserviceaccount.com
Example: api-backend@my-project.iam.gserviceaccount.com

---

Types of Service Accounts

Type	Created By	Example	Can Delete?
User-managed	You	my-sa@proj.iam.gserviceaccount.com	Yes
Default	GCP (when APIs are enabled)	PROJECT_NUMBER-compute@developer.gserviceaccount.com	Yes (but not recommended)
Google-managed	Google (internal)	*@cloudservices.gserviceaccount.com	No

Default Service Accounts

When you enable the Compute Engine API, GCP creates a default compute service account:

<PROJECT_NUMBER>-compute@developer.gserviceaccount.com

Important: The default compute service account has the roles/editor basic role. This is far too broad for production. Best practice is to:

1. Create a dedicated service account with only the permissions needed
2. Attach that service account to your VMs instead
3. Optionally disable or restrict the default service account

---

Creating and Managing Service Accounts

# Create a service account
gcloud iam service-accounts create api-backend \
  --display-name="API Backend Service Account" \
  --description="Used by the API backend application"

# List service accounts in a project
gcloud iam service-accounts list --project=my-project

# Describe a service account
gcloud iam service-accounts describe \
  api-backend@my-project.iam.gserviceaccount.com

# Update display name
gcloud iam service-accounts update \
  api-backend@my-project.iam.gserviceaccount.com \
  --display-name="API Backend SA (Production)"

# Disable a service account (temporarily block access)
gcloud iam service-accounts disable \
  api-backend@my-project.iam.gserviceaccount.com

# Enable a disabled service account
gcloud iam service-accounts enable \
  api-backend@my-project.iam.gserviceaccount.com

# Delete a service account
gcloud iam service-accounts delete \
  api-backend@my-project.iam.gserviceaccount.com

---

Granting Roles to a Service Account

A service account acts as a member — you grant it roles just like a user:

# Grant Cloud Storage read access
gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:api-backend@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# Grant Cloud SQL client access
gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:api-backend@my-project.iam.gserviceaccount.com" \
  --role="roles/cloudsql.client"

---

Authentication Methods

1. Attached Service Account (Recommended)

Attach the service account directly to a GCP resource. The resource receives credentials automatically via the metadata server — no key file needed.

# Attach to a Compute Engine VM
gcloud compute instances create my-vm \
  --zone=europe-west2-a \
  --service-account=api-backend@my-project.iam.gserviceaccount.com \
  --scopes=cloud-platform

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

# Attach to a Cloud Function
gcloud functions deploy my-function \
  --runtime=nodejs20 \
  --service-account=api-backend@my-project.iam.gserviceaccount.com

2. Workload Identity (for GKE)

Workload Identity maps Kubernetes service accounts to GCP service accounts without key files: