What is a Google Cloud Service Account?

Definition

A Google Cloud Service Account is a special, non-human identity that workloads (applications, VMs, containers, CI/CD pipelines, automation) use to authenticate and call Google Cloud APIs.

It is created within a Google Cloud project and named with the format:

NAME@PROJECT_ID.iam.gserviceaccount.com

Service accounts are both identities (you grant them roles) and resources (you control who can act as them or impersonate them).

In simple terms:

A service account is a robot identity in Google Cloud — used by workloads, with its own permissions and credentials.

---

Why Service Accounts Matter

• They are the dominant non-human identity in GCP.
• Compromise of a high-privilege service account = workload-scale or project-scale breach.
• Service account keys are a major credential-leak vector.
• Impersonation chains (Token Creator) enable privilege escalation.
• Default service accounts often hold over-broad roles.

---

How Service Accounts Authenticate

1. Attached to a Resource (Recommended)

• Compute Engine VM, Cloud Run, Cloud Functions, GKE workload (via Workload Identity).
• The runtime issues short-lived credentials automatically; no key needed.

2. Workload Identity Federation

• External workloads (GitHub Actions, AWS, Azure, on-premises Kubernetes) authenticate via OIDC/SAML/AWS to a workload identity pool, then impersonate a service account.
• No long-lived keys.

3. Service Account Impersonation

• A user or another service account (with roles/iam.serviceAccountTokenCreator) calls iamcredentials.generateAccessToken to get short-lived credentials for the target service account.
• Audit-friendly.

4. Service Account Keys (Discouraged)

• Long-lived JSON files containing private keys.
• Easily leaked; a top breach vector.
• Should be eliminated in favor of the above patterns.

---

Common Service Account Patterns

Application Service Accounts

• One service account per workload, with specific roles for that workload's needs.
• Attached to GCE/Cloud Run/Cloud Functions/GKE.

CI/CD Service Accounts

• Workload Identity Federation from CI provider → impersonate deploy service account.
• Deploy SA has roles for the target environment.

Cross-Project Access

• Service account in project A is granted roles on resources in project B.
• Or impersonates a service account in project B.

Default Service Accounts

• Compute Engine and App Engine projects come with default service accounts.
• Default Compute SA historically had Editor role on the project — extremely broad.
• Tame these (disable, restrict role).

---

Service Account Risks

• Service account keys stored in code/config/CI secrets.
• Default service accounts with Editor.
• Over-broad roles (Owner/Editor) on service accounts.
• roles/iam.serviceAccountUser assigned broadly, enabling principals to pass SA to compute resources.
• roles/iam.serviceAccountTokenCreator assigned broadly, enabling impersonation chains.
• Cross-project SA usage without governance.
• Stale / unused service accounts.
• Unmanaged ownership — no one owns the SA.

---

Real-World Examples

1. Service Account Key Leak

Developer accidentally committed service-account.json to a public GitHub repo. Attacker found it; service account had Storage Admin → mass data exfiltration.

2. Default Compute SA Compromise

GKE pod misconfiguration exposed metadata to in-cluster attacker. Default Compute SA had Editor → attacker pivoted across project.

3. Impersonation Chain Privilege Escalation

User dev-user had Token Creator on low-priv-sa. low-priv-sa had Token Creator on high-priv-sa (Owner). Two impersonation steps = Owner.

4. Workload Identity Federation Done Right

Pipeline uses OIDC to impersonate cicd-sa with deploy permissions, scoped strictly to a folder. No keys; full audit trail.

---

Best Practices

1. Eliminate Service Account Keys

• Default to attached service accounts on GCP runtimes.
• Workload Identity Federation for external workloads.
• Service Account Impersonation for ad-hoc human use.
• If keys absolutely needed: short-lived, vaulted, rotated, restricted by Org Policy.

2. Tame Default Service Accounts

• Disable creation of default SAs at Org level (iam.automaticIamGrantsForDefaultServiceAccounts: false).
• Remove default Editor role from existing default SAs.
• Replace with purpose-built service accounts.

3. Least Privilege

• One SA per workload with only the permissions needed.
• Avoid Owner/Editor on service accounts.
• IAM Recommender to right-size.

4. Govern Impersonation

• roles/iam.serviceAccountTokenCreator granted only when needed; on specific service accounts.
• Audit impersonation events.

5. Lifecycle

• Tag SAs with owner / purpose.
• Inventory and clean up unused SAs quarterly.
• Audit logs on SA creation, role changes, impersonation.

6. Cross-Project Hygiene

• Document cross-project SA usage.
• Use iam.disableServiceAccountKeyUpload and similar Org Policies.

---

Checklist

• Service account keys eliminated where possible?
• Workload Identity Federation in CI/CD?
• Default service accounts disabled or restricted?
• Per-workload SAs with least privilege?
• Token Creator scope minimal?
• SAs tagged with owner / purpose?
• Quarterly cleanup of unused SAs?
• Audit log alerts on key creation, impersonation, role changes?
• Org Policies disabling key upload / external IDs / etc.?

---

How Forestall Helps

Forestall maps service accounts across projects:

• SAs and their effective permissions.
• Key inventory and age.
• Impersonation chains visualized.
• Default SA risk.
• Stale SAs.
• Cross-project usage and governance gaps.

---

Frequently Asked Questions

Are service accounts users?

No — they're non-human identities. They have email-like names but cannot sign in interactively (and shouldn't have human-style credentials).

Can a service account have a password?

No — they authenticate via tokens, keys, or attached identity.

What's better: keys or impersonation?

Impersonation (and federation) — short-lived, audit-friendly, no long-lived secrets.

Can a service account impersonate another?

Yes, with Token Creator role. Watch impersonation chains carefully.

Should I disable the default Compute SA?

Yes — or replace its broad Editor role with purpose-built SAs per workload.

---

Conclusion

Service accounts are the workhorse non-human identities of Google Cloud. Used carelessly — with broad roles, long-lived keys, default Editor, and unmanaged impersonation chains — they're a major breach risk. Used well — least privilege, federation/impersonation in lieu of keys, default SAs tamed, lifecycle and audit in place — they enable secure, scalable workload identity. Make service account governance a continuous discipline and your GCP attack surface shrinks dramatically.