Derivation rules

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.

artifactregistry.repositories.downloadArtifacts grants pull/read access to images and packages in the repo - required for consumers and useful for recon.

A principal that can set a repo's IAM policy can self-grant roles/artifactregistry.writer and then push, reaching CanModifyCode on the repo via policy manipulation.

A repository granting uploadArtifacts to allUsers allows any unauthenticated attacker on the public internet to push code - the most critical supply-chain injection vulnerability.

artifactregistry.repositories.update can disable tag immutability, change remote/virtual repo upstreams, or otherwise reconfigure a repository - enabling subsequent supply-chain attacks that were previously BLOCKED.

artifactregistry.repositories.setIamPolicy grants full control over the repo's IAM allow policy - self-grant writer access, then push to poison consumers.

Moving a tag to a different digest (artifactregistry.tags.update) is equivalent to a code push - mutable-tag consumers that re-pull will run the new image.

A principal with artifactregistry.repositories.uploadArtifacts can push/overwrite images or packages into the repo - the code-supply-chain write primitive feeding container-chains fan-out.

An Artifact Registry repo IAM binding for a Workload Identity Federation principalSet/principal with uploadArtifacts grants an external OIDC identity (e.g. GitHub Actions) direct push access - supply-chain from external CI into GCP workloads.

Create a new Batch job whose VMs run as a passable SA (create + actAs).

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

CanExecuteAs a runtime SA of strictly greater privilege.

Create a job with an attacker runnable bound to an actAs-able SA; ExecutesAs completes it. ACTIVE on create (no invoke/trigger).

Create a job WITHOUT specifying a runtime SA -> runs as the Compute Engine default SA (usually roles/editor).

Code running in the job VM reads the runtime SA token from the GCE metadata server.

Attacker with execution in the job can mint the runtime SA token.

A principal with bigquery.datasets.setIamPolicy can self-grant roles/bigquery.dataOwner and escalate its data-plane privilege.

An EXPORT DATA statement or bq extract job copies BigQuery table contents to a GCS bucket - effective data exfiltration across the project boundary.

bigquery.datasets.setIamPolicy lets a principal grant data access to any principal (including itself) for all tables in the dataset.

bigquery.routines.update on a REMOTE_FUNCTION Routine lets a principal change the Cloud Run endpoint the function invokes - effectively modifying the code/target at runtime.

bigquery.transfers.update lets a principal change a scheduled query's SQL - the code the Transfer Service runs as the attached SA.

bigquery.datasets.update lets a principal modify the dataset-native ACL (access[] entries), including adding authorized views and broad access entries.

bigquery.rowAccessPolicies.update or .delete lets a principal delete or broaden row-level security policies, gaining full-table access for themselves or others.

iam.serviceAccounts.actAs on a target SA enables re-binding which SA a scheduled query runs as.

Effective data-plane query access from bigquery.tables.getData + bigquery.jobs.create combined.

A BigQuery Connection of type cloudSql or JDBC contains encrypted database credentials stored in the connection resource.

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 scheduled query with serviceAccountName set runs as that SA; zero-cost fact enabling cicd-chains derivation.

A dataset ACL entry for allUsers makes it queryable by unauthenticated public principals - internet-accessible data.

A dataset ACL entry for allAuthenticatedUsers makes it readable by any Google-authenticated user - org-wide or tenant-wide exposure.

A BigQuery Connection resource stores or proxies credentials to an external data source (Cloud SQL, JDBC, Spark); a principal with bigquery.connections.use gains effective access to that external system.

A principal with bigtable.backups.read on a source backup AND bigtable.backups.create + bigtable.backups.restore in a destination instance (any project) can copy the backup cross-project and restore the full table contents in the destination, exfiltrating all data outside the source project boundary.

bigtable.authorizedViews.readRows grants read access to a scoped subset of a table (row key prefix / column qualifier filtering). The caller can only read the rows/columns defined by the authorized view; access to the parent table is NOT granted. CanReadData is scoped to the AuthorizedView node.

bigtable.tables.readRows constitutes effective data-plane read access: the caller can stream any row from any column family in the table via the ReadRows API. For CMEK-encrypted clusters the capability is CONDITIONAL(key_permission) on the Bigtable service agent's Cloud KMS grant, not on the caller's own KMS permissions.

bigtable.tables.readRows on a CMEK-encrypted cluster; the Bigtable service agent (not the caller) decrypts via Cloud KMS envelope encryption - CanReadData is CONDITIONAL(key_permission) on the service agent's KMS grant and the key's ENABLED state.

bigtable.tables.setIamPolicy lets a principal grant any role on the table to any principal (including itself). Self-granting roles/bigtable.user (includes bigtable.tables.readRows + bigtable.tables.mutateRows) yields full data-plane read/write access scoped to that table without project-level IAM change.

bigtable.authorizedViews.setIamPolicy lets a principal grant view-scope roles to any principal (including itself). Self-granting bigtable.authorizedViews.readRows or bigtable.authorizedViews.mutateRows on a view yields data access scoped to that view's row/column subset without modifying table-level or instance-level IAM. View-scope setIamPolicy is a distinct, view-only escalation primitive.

bigtable.instances.setIamPolicy lets a principal grant instance-scope roles to any principal (including itself). Self-granting roles/bigtable.admin on the instance yields full control over all tables, clusters, and backups within the instance without project-level IAM change. Instance-scope setIamPolicy is a higher-value escalation than table-scope because it affects all tables.