Derivation rules
2,433 declarative match → where → emit rules
(1,787 derived, 646 explicit).
Filter by cloud, emitted edge, node type, or text.
A principal holding dns.managedZones.update at the GCP project scope can modify the privateVisibilityConfig.networks list for a private managed zone, expanding which VPC networks can resolve the zone. This enables widening the blast radius of a private-zone DNS poisoning attack by adding attacker-controlled VPC networks to the zone's visibility scope (cross-project lateral movement via shared VPC).
A Cloud Scheduler App Engine HTTP job triggers an App Engine service on schedule. App Engine targets are always same-project. OIDC/OAuth2 auth model applies identically to HTTP targets.
Update the serviceAccountEmail field of an HTTP job's oidcToken/oauthToken to swap the execution identity (jobs.update + actAs on new SA).
cloudscheduler.jobs.create lets a principal create a new cron job - the persistence and event-source creation primitive. This feeds messaging-chains rule 3 (messaging-schedule-persists-executes-as) when paired with CanPassIdentity.
A principal with cloudscheduler.jobs.create can establish a Pub/Sub job that publishes attacker-controlled data to any topic in the project on schedule. No actAs required. Feeds messaging-chains rules 1+2 for CanTrigger -> CanExecuteAs chain.
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 Scheduler HTTP job binds to a compute target (Cloud Run, Cloud Functions, App Engine, or other HTTP endpoint). The job fires on schedule sending the OIDC/OAuth2 bearer - this is the CanTrigger binding fact consumed by messaging-chains.
A Cloud Scheduler job's HTTP body (httpTarget.body) or Pub/Sub payload (pubsubTarget.data) may embed credentials. Any principal with cloudscheduler.jobs.get / fullView can read the job definition and recover the embedded credential.
actAs on a SA that the principal names in an HTTP job's oidcToken.serviceAccountEmail or oauthToken.serviceAccountEmail is the GCP PassRole analog for Cloud Scheduler. Required to create or update a job with an authenticated HTTP target.
cloudscheduler.jobs.run triggers an immediate execution of the current job definition, bypassing the cron schedule - the on-demand CanSchedule primitive for an existing Cloud Scheduler job.
cloudscheduler.jobs.update lets a principal change an existing job's URI, headers, body, schedule, or OIDC/OAuth2 SA. This is the configuration-change primitive; URI-retarget (no new actAs needed) and SA-swap (actAs required) are the two attack patterns.
Retargeting an existing HTTP job's URI (via jobs.update) to an attacker-controlled endpoint causes the existing SA's OIDC/OAuth2 bearer token to be delivered on the next invocation - no actAs on the SA required since the SA is unchanged.
cloudsql.instances.clone creates a full copy of a Cloud SQL instance (with all databases and data) accessible to the cloning principal in the same project - direct data exfiltration without external GCS access.
cloudsql.instances.update can enable public IP (ipv4Enabled=true) and add 0.0.0.0/0 to authorizedNetworks, making the instance internet-reachable from any network.
A principal who can reset the root DB user password and then read all data in a Cloud SQL instance has escalated to full DBA-level database privilege.
roles/cloudsql.admin (including cloudsql.instances.* permissions) grants full administrative control over Cloud SQL instances.
cloudsql.users.update on a Cloud SQL instance lets a principal reset any DB user's password, including root/admin DB users.
A Cloud SQL instance may store application secrets (API keys, SA keys, connection strings, tokens) in its databases based on schema/table metadata heuristics.
cloudsql.instances.update can enable IAM database authentication (cloudsql.iam_authentication database flag), unlocking passwordless DB login for instanceUser principals.
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.
cloudsql.sslCerts.create returns a client SSL certificate private key (one-time, in the API response), which serves as a database authentication credential.
cloudsql.sslCerts.create returns a client SSL certificate private key (one-time in the API response), which serves as a database authentication credential.
cloudsql.instances.export triggers the Cloud SQL service agent to write a full SQL dump (or CSV export) to a GCS bucket; when the destination bucket is attacker-accessible, this constitutes data exfiltration.
When a Cloud SQL instance has IAM database authentication enabled (cloudsql.iam_authentication=on), a principal with cloudsql.instances.login can authenticate to the DB using its IAM token via Cloud SQL Auth Proxy - no DB password needed.
cloudsql.instances.import can import a SQL dump or CSV from a GCS bucket into a Cloud SQL instance, allowing data modification, schema changes, and stored procedure injection.
A Cloud SQL instance with a public IP (ipv4Enabled=true) and an authorized network of 0.0.0.0/0 is TCP-reachable from the internet on the DB port, exposing it to unauthenticated network-level attack (brute-force, known CVEs).
A principal that can reset the root/admin DB user password on a Cloud SQL instance gains full SQL read access to all databases in that instance.
storage.buckets.setIamPolicy on the Composer environment GCS bucket lets the principal grant storage.objects.create (dags/ write access) to itself or others, enabling the DAG-write code-execution path.
Holding CanPassIdentity on a target SA plus composer.environments.create gives the principal the ability to create a Composer environment running as that SA.
storage.objects.create on the Composer environment's GCS dags/ prefix injects a Python DAG file that Airflow executes as the environment SA; cite can-execute-as for the CanExecuteAs roll-up.
All Composer DAG task executions can mint OAuth tokens for the environment SA from the GKE metadata server; code execution in any DAG task yields the environment SA's credentials.
composer.environments.executeAirflowCommand lets the principal trigger an existing Airflow DAG run; CanExecuteAs is CONDITIONAL on the current DAG definition being attacker-influenced.
composer.environments.update + iam.serviceAccounts.actAs on a new SA: swap the Composer environment's runtime SA; future DAG tasks run as the new SA.
composer.environments.update with softwareConfig.pypiPackages injects an attacker-controlled Python package installed on all workers and the scheduler, executing code as the environment SA at import time.
Airflow web server in Composer 2 environment is internet-accessible when config.webServerNetworkAccessControl.allowedIpRanges includes 0.0.0.0/0.
Create a new Dataflow job whose workers run as a passable SA (dataflow.jobs.create + iam.serviceAccounts.actAs).
A Dataflow worker SA with storage.objects.create on an external GCS bucket can stream pipeline output (data records, query results) to that external location.
Dataflow worker SA credentials accessible via metadata server to code running in pipeline transforms (when execution is established via CanModifyCode or CanExecuteAs).
Writing to the GCS object that serves as a Dataflow Flex or Classic Template poisons the next job created from that template; the job runs the attacker-controlled pipeline code as the worker SA.
dataflow.jobs.updateContents on a streaming Dataflow job lets the principal inject attacker-controlled transforms into the live pipeline; updated code runs immediately as the worker SA.
dataflow.jobs.updateContents also allows changing job configuration parameters (worker count, machine type, autoscaling) on running streaming jobs; configuration changes alone are lower-value escalation than code injection.
datafusion.instances.create + iam.serviceAccounts.actAs on a target SA: create a new Data Fusion instance whose pipelines execute as that SA.
All Dataproc nodes in a Data Fusion pipeline cluster can retrieve OAuth tokens for the dataprocServiceAccount from the GCE metadata server; code execution in any pipeline step yields those credentials.
datafusion.instances.update (GCP IAM) + CDAP pipeline write access lets a principal deploy or replace a pipeline definition, injecting arbitrary code executed as the instance's dataprocServiceAccount on an ephemeral Dataproc cluster.
datafusion.instances.update + iam.serviceAccounts.actAs on a target SA lets a principal replace the dataprocServiceAccount; all future pipeline runs execute as the new SA.
Create a serverless Dataproc Batch job bound to a passable SA; the job runs as that SA immediately on creation.
dataproc.clusters.setIamPolicy lets a principal rewrite the cluster's IAM policy - self-granting dataproc.jobs.create -> CanExecuteCommand -> CanExecuteAs.
clusters.update + actAs on the new SA attaches (swaps) the cluster's runtime SA - all future jobs run as the new SA.