Derivation rules

The Eventarc-managed Pub/Sub transport topic backs the trigger's event delivery - connects Topic node to EventRule node for the two-hop chain.

An Eventarc trigger has an IAM allow policy governing who may manage it.

Live Eventarc trigger (state=ACTIVE) routes events to a Cloud Run service destination.

Live Eventarc trigger (state=ACTIVE) routes events to a Cloud Function destination.

Live Eventarc trigger (state=ACTIVE) routes events to a GKE service endpoint.

Live Eventarc trigger (state=ACTIVE) routes events to a GCP Workflow destination.

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

Holding eventarc.messageBuses.publish on an Eventarc Advanced message bus lets an attacker inject arbitrary CloudEvents into the bus, driving all pipelines/enrollments bound to it - the direct Phase-10 publish primitive for Eventarc Advanced.

pubsub.topics.publish on the Eventarc-managed transport Pub/Sub topic lets an attacker inject crafted CloudEvent messages directly into the Eventarc delivery pipeline, bypassing the standard source adapter.

Publishing to an Eventarc-managed Pub/Sub transport topic directly triggers the bound destination consumer - collapses the Topic → EventRule → Compute chain into a single CanTrigger(Topic → Compute) for messaging-chains rule 1.

eventarc.messageBuses.setIamPolicy lets an attacker grant itself eventarc.messageBuses.publish on a message bus, enabling direct event injection into all bound pipelines.

eventarc.triggers.setIamPolicy lets an attacker grant itself roles/eventarc.developer (trigger update/create) on the trigger, enabling destination redirect or filter widening.

A live Eventarc trigger (state=ACTIVE) routes events from its source to the destination consumer - the event-source-binding fact feeding messaging-chains rules 1 and 2.

eventarc.triggers.update can redirect an existing trigger's destination, swap the trigger SA, or widen event filters - hijacking a live event stream to an attacker-chosen consumer or re-activating a previously-filtered trigger path.

actAs + ability to create a resource that runs as the SA.

A principal holding file.backups.get in the source project plus file.instances.create or file.instances.update in an attacker-controlled destination project can restore a Filestore backup to the destination, exfiltrating all data. This is a multi-project, multi-permission escalation path documented as one of the three central attack primitives for Filestore.

file.instances.update lets a caller patch the nfsExportOptions export rules of a Filestore instance via the googleapis.com API, adding an attacker-controlled IP range. This is a control-plane capability scoped to nfsExportOptions config. Subsequent NFS mount access (CanReadData/CanWriteData) requires network reachability.

When a principal holds CanModifyConfiguration (file.instances.update) on a Filestore instance and uses it to add an attacker-controlled IP to the NFS export rules, the principal's VM/container gains CanReadData and (if accessMode is READ_WRITE) CanWriteData to all files on the mounted share. This rule derives the data-plane access edges from the control-plane config mutation. State is POTENTIAL because the patch must be executed and network reachability must be confirmed.

A VM whose source IP falls within a Filestore NFS export range can mount the share and read (and write, if READ_WRITE) all files without any IAM check - access is purely IP-address gated. CanWriteData is emitted when accessMode is READ_WRITE; CanReadData for both READ_WRITE and READ_ONLY.

A principal holding file.snapshots.get in the source project plus file.instances.create or file.instances.update in an attacker-controlled destination project can restore a Filestore snapshot to the destination, exfiltrating all data. Snapshots are point-in-time copies of a share and can be restored cross-project exactly as with backups, making this an equally viable cross-boundary data exfiltration path.

Firebase Security Rules requiring only 'request.auth != null' (authenticated but no domain/claim restriction) make the Firestore database accessible to any Firebase Auth user - including users outside the organization.

datastore.backups.restoreDatabase on a Firestore database + access to a Firestore backup enables restoring the backup, completely overwriting all current database content. Identical attack impact to import but via backup rather than GCS export.

A Firestore database contains collections or document field names whose names indicate credential material (API keys, SA keys, OAuth tokens, database passwords).

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.

datastore.databases.export + storage.objects.create on a destination GCS bucket constitutes effective Firestore data exfiltration: the entire database is copied to an attacker-controlled or cross-project GCS bucket.

An IAM binding on a Firestore database naming 'allAuthenticatedUsers' allows access to any GCP-authenticated user, exposing data tenant-wide.

An IAM binding on a Firestore database naming 'allUsers' as a principal allows unauthenticated access to the database via the Cloud IAM / Admin SDK surface.

datastore.databases.import + control of a source GCS bucket enables importing a Firestore export, overwriting ALL existing data in the database (bypass document-level write controls).

datastore.entities.create alone enables document injection (creation of new documents); without entities.update, the attacker cannot modify existing data but can poison via new entries.

datastore.databases.update allows changing cmekConfig.kmsKeyName on a Firestore database, swapping to an attacker-controlled KMS key. Future writes are then encrypted under the attacker's key, enabling offline decryption of all subsequently written data. This is a configuration mutation on a data resource, not code execution.

firebase.rules.rulesets.create + firebase.rules.releases.update allows a principal to replace the active Firebase Security Rules with an attacker-controlled permissive ruleset, opening the Firestore database to internet access via the Firebase client SDK.

Firebase Security Rules containing 'allow read, write: if true' (or equivalent unauthenticated-access rule) make the Firestore database readable/writable by any unauthenticated internet user via the Firebase client SDK.

datastore.entities.get constitutes effective data-plane read access to Firestore/Datastore documents.

datastore.entities.get on a CMEK Firestore database; the Firestore Service Agent (not the caller) decrypts using its KMS grant. CanReadData state is ACTIVE if the service agent's KMS grant is confirmed, CONDITIONAL(key_permission) if the grant state is unknown, and BLOCKED if the grant is denied or the key is disabled.

datastore.databases.setIamPolicy writes the Firestore database IAM allow policy; the caller can grant any principal (including itself) any role on the database.

datastore.databases.setIamPolicy lets a principal grant itself roles/datastore.owner or roles/datastore.viewer on the database, then read or administer all documents.

datastore.entities.create + datastore.entities.update together constitute effective full data-plane write access to Firestore/Datastore documents (overwrite capability).

compute.firewalls.create lets an attacker insert an ALLOW rule, opening ports on any VMs matching a chosen tag or service account.

compute.firewalls.delete on a DENY rule lets an attacker unblock previously denied traffic, opening network access to matched VMs.

Ingress ALLOW from 0.0.0.0/0 on a port means any internet source can reach that port on matched VMs - a per-firewall-rule network FACT.

VM with an ingress ALLOW from 0.0.0.0/0 AND an external IP is internet-exposed on that port - any unauthenticated actor can attempt to connect.

compute.organizations.setFirewallPolicy lets an attacker replace org/folder-level firewall policy, opening ports across all projects in scope.