iam.serviceAccounts.actAs is the permission to bind a service account to a resource you create. On its own it does nothing; combined with a resource-create permission, it lets you deploy something that runs as a service account more privileged than you, then take its token or run code as it. The target service account only needs to exist and be usable in the project.

The pattern is always: find a privileged service account (gcloud iam service-accounts list, and the enumeration graph for its role bindings), confirm you hold actAs on it, then drive it through one of the deploys below.

Deploy targets#

• Compute instance: compute.instances.create with a privileged service account and full scope.
• Cloud Function: deploy a function running as the attached account.
• Cloud Run: a service or job running attacker containers as the account.
• Deployment Manager: deploy as the default-Editor Google APIs service agent.
• Cloud Build: exfiltrate the Cloud Build service account token mid-build.
• App Engine: a version running as the App Engine default account.
• Cloud Composer: an Airflow DAG task running as the environment account.
• Cloud Scheduler: a scheduled job calling an API as a chosen account.
• Vertex AI notebook: a notebook VM with the attached account.
• Dataproc: a cluster or job running as the cluster account.

References#

• Rhino Security Labs: GCP privilege escalation (part 2)
• GCP IAM privilege escalation (Rhino repo)
• Google: iam.serviceAccounts.actAs