Cloud function deployments and the identity gap teams are missing

TL;DR: ConfusedFunction shows how a routine Google Cloud Function deployment can trigger Cloud Build under a more powerful default service account, creating indirect privilege escalation and access to sensitive project resources, according to Unosecur. The issue underlines that automated deployment identities need the same governance discipline as human and workload accounts.

NHIMG editorial — based on content published by Unosecur: ConfusedFunction: Privilege Escalation Through Google Cloud's Deployment Automation

Questions worth separating out

Q: How should teams reduce privilege escalation risk in Cloud Functions deployments?

A: Teams should treat the deployment workflow as an access boundary, not just the user who clicked deploy.

Q: Why do cloud build identities create hidden security risk?

A: Cloud build identities create hidden risk because they often execute with broader permissions than the initiating developer or pipeline.

Q: What breaks when service accounts are not reviewed in deployment pipelines?

A: What breaks is the assumption that access reviews capture the identity doing the work.

Practitioner guidance

• Scope the build identity separately from the deployer Inventory every service account involved in Cloud Functions deployment and compare its permissions with the permissions of the user or pipeline that triggers it.
• Review cross-service access reachable from Cloud Build Map what the default Cloud Build service account can reach in storage, registries, source repositories, and project-level APIs.
• Correlate deployment, build, and IAM events Alert on unexpected function updates followed by unusual build execution, then check whether IAM policy changes or sensitive resource access followed the same sequence.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step explanation of how Cloud Functions deployment triggers Cloud Build in Google Cloud.
• The specific resource classes exposed through the default Cloud Build service account, including buckets, source code, and registries.
• Concrete monitoring signals for unusual build activity and access changes following function updates.
• Practical remediation guidance for re-scoping service accounts and deployment workflows.

👉 Read Unosecur's analysis of ConfusedFunction and GCP privilege escalation →

Cloud function deployments and the identity gap teams are missing?

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →