Service Accounts in Google Cloud

The core idea

In Google Cloud, Service Accounts are identities for machines, not humans .They are used by resources like VMs, Cloud Functions, Kubernetes, etc. to talk to other Google Cloud services.

Unlike AWS (where users can directly generate API keys), Google Cloud forces you to use Service Accounts when you want:

• Programmatic access

• Static credentials

• Non-interactive authentication

So:👉 If code needs access, it almost always runs as a Service Account.

----------------------------------------------------------------------------------------------

What actually happens when you create a VM

When you create a VM:

• Google Cloud automatically creates (or assigns) a Service Account

• That Service Account:

  • Appears in IAM

  • Can be granted roles just like a user

  • Is used by the VM to access other resources (Storage, APIs, databases)

You can delete this Service Account from IAM —but then your VM will break if it needs to talk to anything else.

Best practice in reality : Don’t delete it — restrict its permissions.

----------------------------------------------------------------------------------------------

The real danger: Basic Roles (Owner & Editor)

On paper

Google Cloud has Basic Roles:

• Viewer

• Editor

• Owner

They were created early on to make things “easy”.

In practice (this is where things go wrong)

The Editor role is dangerously powerful:

An account with Editor can:

• Modify resources

• Create API keys

• Use actAs to impersonate other accounts

• Create credentials for other accounts

Key insight:

Editor ≈ Owner (from an attacker’s point of view)

----------------------------------------------------------------------------------------------

Why attackers love Editor accounts

If a threat actor compromises any account with Editor:

1. They can create an API key

2. They can impersonate (actAs) higher-privileged accounts

3. They can effectively privilege-escalate to Owner

This is not theoretical — it’s abused in real incidents.

----------------------------------------------------------------------------------------------

Real-world lateral movement scenario

Let’s walk through the actual attack flow.

Step 1 – Environment setup (normal behavior)

• Infra team creates a Development Project

• VMs are deployed for developers

• Each VM has a Service Account

Everything is isolated. Looks safe.

Step 2 – Developer needs storage (very common)

• Developer needs persistent storage

• Creates a Cloud Storage Bucket

• Grants the VM’s Service Account Editor access to the bucket

From the developer’s perspective:

“It works, job done.”

Step 3 – Credentials exposure

One of the following happens:

• Service Account key committed to GitHub

• Credentials stored in code

• VM is compromised and metadata server is abused

Now the attacker has:👉 Service Account credentials with Editor permissions

Step 4 – Privilege escalation

With Editor access, the attacker can:

• Create new API keys

• Impersonate other IAM accounts

• Take over Owner accounts in the same project

Step 5 – Organization-level impact

If any Org-level bound account exists in that project:

• The attacker can impersonate it

• Escalate to the Organization

• Gain control over:

  • All projects

  • All resources

  • Entire cloud environment

Single Service Account compromise → Full Org takeover

----------------------------------------------------------------------------------------------

Why this is hard to detect (investigation challenge)

The IAM visibility problem

In Google Cloud:

• Resource owners decide access

• There’s no single place that shows:

  “What does this account have access to across the Org?”

This creates:

• Hidden trust relationships

• Accidental cross-project access

• Silent privilege escalation paths

----------------------------------------------------------------------------------------------

TInvestigator & Defender mindset

When you’re investigating or hardening Google Cloud:

Red flags to look for

• Service Accounts with Editor role

• Shared Service Accounts across projects

• Exposed Service Account keys

• Unexpected actAs activity

• API keys created by non-human identities

----------------------------------------------------------------------------------------------

Defensive mindset shift

❌ “Editor is fine for dev”✅ “Editor is a privilege escalation waiting to happen”

----------------------------------------------------------------------------------------------

One-line summary

In Google Cloud, Service Accounts with Editor permissions act as silent trust bridges—once compromised, they enable privilege escalation, lateral movement, and even full organization takeover without deploying malware.

-----------------------------------------------Dean---------------------------------------------