Derivation rules

A principal with deploymentmanager.typeProviders.create registers a custom type provider backed by an attacker-controlled endpoint; a DM deployment using that type causes DM to call the endpoint as the cloudservices SA, yielding execution as that SA. Uses CanModifyConfiguration path (typeProviders.create emits CanModifyConfiguration on the Deployment).

A principal with deploymentmanager.deployments.update replaces an existing deployment's config; DM re-executes as the cloudservices SA.

Every Deployment Manager deployment runs as the Google APIs service agent (PROJECT_NUMBER@cloudservices.gserviceaccount.com), which by default holds roles/editor at the project.

The Google APIs service agent's effective permissions include resourcemanager.projects.setIamPolicy ONLY when it holds roles/owner. A DM config can instruct the SA to call setIamPolicy at project scope, granting the deployer project-level roles.

The Google APIs service agent's effective permissions include *.setIamPolicy on resources it manages when it holds roles/editor (GCS, SA, Pub/Sub, etc.). A DM config can instruct the SA to call setIamPolicy, granting the deployer any role on those resources.

An Eventarc trigger uses its serviceAccount field as the delivery identity when calling the destination endpoint.

actAs on a SA that the principal can configure as the trigger's serviceAccount is the GCP PassRole analog for Eventarc trigger SA assignment.

storage.hmacKeys.create generates a long-lived HMAC key (ID + secret) for a Service Account; the secret grants S3-compatible access to all GCS buckets the SA can reach but is scoped to the GCS API only, not full SA impersonation.

container.nodePools.create + iam.serviceAccounts.actAs on a chosen SA => create a new node pool running as that SA; pods on those nodes read the node SA token via the metadata server (legacy metadata mode).

Executing inside a pod on a legacy-metadata node pool (no GKE_METADATA) allows the code to call the GCE metadata server and retrieve the node pool SA's access token.

A GKE node pool with workloadMetadataConfig.mode != GKE_METADATA allows pods to reach the GCE metadata server and read the node pool SA's OAuth token - the node SA credential is exposed to every pod on those nodes.

A CMEK-encrypted Secret Manager payload authenticates as another identity, completing CanExecuteAs -> CanReadSecret -> CredentialsFor.

Signing as a key that anchors an identity (JWKS/JWT/code-signing) forges that identity.

pubsub.subscriptions.create (or pubsub.subscriptions.update) + iam.serviceAccounts.actAs on a push SA allows creating a push subscription that delivers the SA's OIDC token to a push endpoint, attaching the SA's identity to the event source.

A Pub/Sub push subscription delivers a Google-signed OIDC token for its pushConfig.oidcToken.serviceAccountEmail to the push endpoint on every delivery; code at the endpoint can extract and replay the token, exposing the push SA's identity.

The secret's payload authenticates as another identity / service account / data store.

Reading a secret whose payload is an SA JSON key yields long-lived credentials for that SA.

A CSR repo IAM binding that grants source.repos.update to a service account from a different GCP project establishes cross-project trust - that SA can push to this project's repository and arm Cloud Build triggers.

cloudtasks.tasks.create with a per-task httpRequest.oidcToken.serviceAccountEmail (or oauthToken) requires iam.serviceAccounts.actAs on the chosen SA - the per-task identity override path.

cloudtasks.queues.update + iam.serviceAccounts.actAs on a SA allows an attacker to configure that SA as the queue-level OIDC/OAuth token identity - the GCP actAs guard rail for Cloud Tasks queue-SA attachment.

Create a Workbench notebook instance whose underlying GCE VM runs as a passable SA. The instance persists; accessing JupyterLab (notebooks.instances.use) executes code as the SA.

Create a Vertex AI custom training job / pipeline job / notebook execution job whose workers run as a passable SA (create + actAs). Job runs immediately on creation - no invoke step.

A training job, pipeline job, or notebook execution job binds a cross-project service account.

Workbench notebook instance explicitly declares its service account.

Training job, pipeline job, or notebook execution job explicitly declares its service account.

A Workbench notebook instance binds a cross-project service account.

Principal holds iam.serviceAccounts.actAs on a service account (explicit permission normalization).

A training job or Workbench notebook exposes its runtime SA credentials to any code it runs via the GCE metadata server.

A service-project service account holding compute.networkUser on a host-project subnet can create workloads whose NICs land in that subnet, giving those workloads internal-IP reachability to all other resources in the subnet (including those from other service projects).

setIamPolicy on a ServiceAccount lets a principal add/loosen the workloadIdentityUser binding that maps an external WIF subject to the SA.

Federating into a WIF-impersonated ServiceAccount gives the external principal a foothold in the SA's home project.

An external identity the WIF provider accepts and a workloadIdentityUser binding resolves can federate into the impersonated ServiceAccount.

actAs on a SA that the principal can attach to a workflow (create/update) is the GCP PassRole analog for Workflows.

Reading a credential that is credentials for an identity yields the ability to authenticate as that identity.

Reading a secret that is credentials for an identity yields the ability to authenticate as that identity.

Signing tokens as an identity yields impersonation when a downstream trust validates those signatures.

A Kubernetes workload-identity binding (KSA<->GSA / IRSA / AKS Workload Identity) lets the pod's projected SA token federate into a cloud Role/ServiceAccount; escalation roll-ups are federation-chains'.