Cloud IAM: Service Accounts

In Google Cloud, identities aren’t just for humans. Service Accounts are special types of accounts used by applications and compute workloads (like Compute Engine VMs or GKE pods) to make authorized API calls. They represent the “machine identity” rather than a “user identity.”

The Analogy: The Hotel Valet Key

Think of a Service Account as a Valet Key for a car. When you give your car to a valet, you don’t give them your house keys or your wallet. You give them a specific key that only allows them to start the car and drive it a short distance. Similarly, a Service Account provides an application with exactly the permissions it needs to perform its job (e.g., writing to a specific Cloud Storage bucket) without giving it your owner-level credentials.

Detail Elaboration: Identity vs. Resource

A unique characteristic of a Service Account is that it is both an Identity and a Resource:

As an Identity: It can be granted roles to access resources (e.g., “This SA has the storage.objectViewer role”).
As a Resource: Users need permission to use the service account. You grant a developer the iam.serviceAccountUser role on the Service Account so they can attach it to a VM.

Core Concepts & Best Practices

Security (Least Privilege): Never use the “Default Compute Service Account” with Editor permissions in production. Create a fine-grained User-Managed Service Account.
Reliability: Service accounts don’t have passwords that expire, ensuring long-running automated tasks don’t fail due to credential rotation.
Operational Excellence: Use Service Account Impersonation instead of downloading JSON keys to local machines.

Comparison: Service Account Variants

Feature	Default Service Account	User-Managed Service Account	Google-Managed Service Account
Creation	Automatic (when API is enabled)	Manual (Created by Admin)	Automatic (Internal GCP use)
Naming Convention	`project-number-compute@developer.gserviceaccount.com`	`name@project-id.iam.gserviceaccount.com`	`service-project-number@container-engine-robot.iam.gserviceaccount.com`
Default Permissions	Often “Editor” (Too Broad)	None (You define them)	Specific to the GCP Service
Best Use Case	Quick testing/Sandbox	Production Workloads	Internal GCP service communication

Decision Matrix: If/Then Scenarios

If you need an application on a VM to upload files to Cloud Storage… Then create a User-Managed SA with roles/storage.objectCreator and attach it to the VM.
If a developer needs to run a script locally that accesses GCP… Then use gcloud auth application-default login or SA Impersonation; avoid downloading JSON keys.
If you are using GKE and need pods to have specific identities… Then use Workload Identity to map a K8s service account to a GCP service account.

Exam Tips: ACE Golden Nuggets

The “ServiceAccountUser” Role: To attach a service account to a resource (like a VM), the user needs the iam.serviceAccountUser role on that specific service account.
Scopes vs. IAM: For Compute Engine, Access Scopes are the “legacy” way. The modern best practice is to set the scope to cloud-platform (full access) and then use IAM Roles on the Service Account to restrict actual permissions.
JSON Keys: GCP recommends avoiding service account keys whenever possible because they are long-lived and pose a security risk if leaked to GitHub.
Default SA: The default Compute Engine service account has the Editor role by default. This is almost always the “wrong” answer in a security-focused exam question.

Visualizing Service Account Flow

The VM fetches temporary credentials from the Instance Metadata Server to authenticate as the Service Account.

Key GCP Services

IAM: Manage roles/permissions.
Resource Manager: Hierarchy control.
Cloud Logging: Audit SA activity.

Common Pitfalls

Committing key.json to Git.
Using 1 SA for 10 different apps.
Deleting an SA while VMs still use it.

Architecture Patterns

Workload Identity: Best for GKE.
SA Impersonation: Best for Devs.
Cross-Project Access: SA in Proj A accessing Bucket in Proj B.