Project

UpdateProject + PassRole swaps the service role of an existing project; the next build runs as the new (attacker-chosen) role.

Executing as a service account in a different GCP project = entering that project (GCP-scoped extension of can-control.yaml escalation logic).

Federating into a ServiceAccount homed in a GCP project gives the federated principal a foothold in that project.

An Artifact Registry repo IAM allow policy that grants roles/artifactregistry.writer (or uploadArtifacts) to a service account from a different GCP project establishes cross-project trust - that SA can push to this project's registry.

A principal in project A creates a Batch job in project B whose runtime SA has power in B.

A dataset ACL entry naming a dataset, view, or SA from another project grants cross-project data read access - a BigQuery-native cross-project trust.

A cross-project requester forging a cert a privileged consumer in the CA's project trusts enters that project.

A Cloud Scheduler Pub/Sub job targeting a topic in a different project establishes cross-project trust - the Cloud Scheduler service agent must hold roles/pubsub.publisher in the external project.

A Cloud Scheduler HTTP job whose configured SA holds role bindings in a different project establishes cross-project trust - an attacker who can create/update the job (with actAs on the SA) can invoke APIs in the other project as that SA.

A Cloud SQL read replica created in a different project enables cross-project access: principals in the replica's project can query the replica and read source database data.

A Dataproc cluster whose service account belongs to a different project creates a cross-project trust; code in jobs runs as a SA from another project.

A Cloud Deploy target's execution SA from a different project establishes a cross-project trust enabling CanEnterProject on that SA's home project.

An IAM binding on an Eventarc Advanced message bus granting eventarc.messageBuses.publish to a principal in a different project is cross-project event-injection trust - that external principal can drive all pipelines bound to the bus.

An IAM binding on an Eventarc trigger granting eventarc.triggers.update (or .create in the project) to a principal in a different project is cross-project trigger-management trust - that external principal can redirect the trigger or bind new sources to consumers in this project.

An IAM binding on an Eventarc Advanced message bus granting publish rights to a principal in a different project.

An IAM binding on an Eventarc trigger granting trigger management permissions to a principal in a different project.

A Firestore database IAM binding granting any role to a principal in a different GCP project is a cross-project trust on the database's data.

A principal in project A controls code/config of a function in project B whose runtime SA has power in B.

A cross-project principal that can read a bucket containing credentials for a principal privileged in the bucket's project effectively enters that project.

A cross-project principal that can set the bucket IAM policy can grant itself objectViewer, read the bucket contents, and enter the bucket's project data boundary - especially when the bucket contains privileged credentials.

Principal with iam.denypolicies.update or .delete can remove/weaken a deny policy, upgrading the edges it was blocking.

Decrypting another project's key that unlocks a materialized credential privileged in that project enters it.

Modify the project, folder, or org IAM policy's auditConfigs to remove DATA_READ/DATA_WRITE log types, suppressing Data Access audit log generation for targeted GCP services at the IAM policy level.

A Pub/Sub subscription IAM binding granting pubsub.subscriptions.consume to a principal from another GCP project enables the external principal to read/drain the subscription (data exfiltration via messaging-chains).

A Pub/Sub topic IAM binding granting pubsub.topics.publish to a principal from another GCP project is cross-project publish trust; feeds can-control's CanEnterProject derivation via messaging-chains.

A cross-project principal reading a secret whose payload is a credential privileged in the secret's project enters that project.

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.

source.repos.updateProjectConfig controls project-wide CSR settings, including whether Cloud Build automatic triggers fire - a meta-gate on CSR-triggered CI/CD paths in the project.

A Cloud Tasks queue IAM policy granting cloudtasks.tasks.create to a principal from another GCP project is cross-project messaging trust - the foreign principal can publish tasks to trigger the queue's consumer in the queue's project.

A principal in project A can execute code as a SA that holds privilege in project B by submitting a training job or creating a notebook bound to that cross-project SA.

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

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

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

An IAM binding on the workflow's allow policy granting workflows.executions.create to a principal in a different project is cross-project publish/trigger trust.