CrossProjectTrust

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 Cloud Deploy target's execution SA from a different project establishes a cross-project trust enabling CanEnterProject on that SA's home 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 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.

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 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.

GCR artifacts bucket grants storage.objects.create to a principal from another project - cross-project supply-chain trust allows external actors to inject images into this project's registry.

A key binding naming a principal/service-agent in another project is cross-project trust.

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 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 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.

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.

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.

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.

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

An IAM binding on an Eventarc Advanced message bus granting publish rights 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 training job, pipeline job, or notebook execution job binds a cross-project service account.

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

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.