Derivation rules

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.

Generating an HMAC key for a Service Account with greater GCS-scoped access and using it via the S3-compatible GCS API constitutes privilege escalation (storage-scoped only, not full SA impersonation).

storage.objects.get on the source bucket + storage.objects.create on a destination bucket (cross-project or attacker-controlled) constitute effective data exfiltration; achievable via storage.objects.copy (rewriteObject) which combines read+write permissions.

storage.hmacKeys.create generates a long-lived HMAC key (ID + secret) for a Service Account; the secret grants S3-compatible access to all GCS buckets the SA can reach but is scoped to the GCS API only, not full SA impersonation.

A bucket IAM binding granting any read role to allUsers, or a publicRead/publicReadWrite predefined ACL (when UBLA is disabled), makes the bucket's objects accessible to unauthenticated internet principals.

storage.objects.get constitutes effective data-plane read access to GCS objects in the bucket (permission applies at object level but IAM bindings are bucket-scoped).

storage.objects.get on a CMEK bucket; the Storage service agent (not the caller) decrypts - CanReadData is CONDITIONAL(key_permission) on the service agent's KMS grant.

A principal with CanModifyPolicy on a bucket's IAM policy can grant itself roles/storage.objectViewer or roles/storage.admin and read or administer its objects.

storage.objects.create constitutes effective data-plane write access to a GCS bucket; also enables supply-chain poisoning if the bucket backs a Cloud Function source archive.

An object write to a GCS bucket with Pub/Sub notification config pointing to a Cloud Function/Cloud Run service triggers downstream compute execution as the function's service account.

container.clusters.update allows modifying cluster-wide security configuration: disabling Workload Identity, changing master auth networks, disabling Binary Authorization, or enabling EXPOSE_ALL_SCOPES metadata - each is a misconfiguration that opens downstream escalation paths.

container.nodePools.create + iam.serviceAccounts.actAs on a chosen SA => create a new node pool running as that SA; pods on those nodes read the node SA token via the metadata server (legacy metadata mode).

container.clusters.getCredentials + cluster-admin ClusterRoleBinding (or system:masters group) => pods/exec create on all pods => CanExecuteCommand fan-out.

Executing inside a pod on a legacy-metadata node pool (no GKE_METADATA) allows the code to call the GCE metadata server and retrieve the node pool SA's access token.

container.clusters.getCredentials yields a kubeconfig (endpoint + CA) authenticated with the caller's GCP token; k8s RBAC then governs what actions are permitted.

A GKE node pool with workloadMetadataConfig.mode != GKE_METADATA allows pods to reach the GCE metadata server and read the node pool SA's OAuth token - the node SA credential is exposed to every pod on those nodes.

K8s RBAC clusterrolebindings/create (or wildcard *) verb lets a principal bind cluster-admin to any subject, effectively granting itself full cluster control - the k8s privilege escalation via RBAC.

K8s RBAC deployments/update (or equivalent patch verb) on a Deployment lets a principal change the container image reference - direct CanModifyCode into the workload, triggering a rollout with attacker-controlled image.

K8s RBAC pods/exec create (or ClusterRole containing it) on a namespace/cluster grants CanExecuteCommand on pods in scope - the direct exec path independent of GCP IAM.

artifactregistry.repositories.uploadArtifacts on an Artifact Registry repository (or storage.objects.create on a legacy GCR bucket) lets an attacker push/overwrite an image tag that GKE workloads pull - registry-level CanModifyCode, propagated by container-chains to each consuming workload.

container.nodePools.update + iam.serviceAccounts.actAs on a privileged SA allows changing an existing node pool's service account - converts existing pod workloads to run as the new (more privileged) SA via legacy metadata access.

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

A principal with compute.backendServices.update can set iap.enabled=false on a backend service that currently has IAP enabled, disabling the authentication gate. If the backend service is internet-facing (via an external HTTPS load balancer), this immediately exposes the protected application to unauthenticated internet access. This is a weaken-control primitive: IAP removal + internet-facing LB = ExposedToInternet on the backend app.

A principal with iap.tunnelDestGroups.accessViaIAP can reach hosts in a TunnelDestGroup via IAP TCP forwarding. DestGroups enable IAP tunnels to non-GCE endpoints (Cloud Run internal, on-prem hosts, or other private services reachable within the VPC). This provides private-network reach to those endpoints without a VPN.

A principal with iap.tunnelInstances.accessViaIAP can open a TCP tunnel through Google IAP to any port on the target GCE instance (SSH/22, RDP/3389, or any custom TCP port) without the instance having a public IP. This provides direct network-level reach to a private VM from any location with HTTPS access to Google's infrastructure.

A principal with iap.webServiceVersions.accessViaIAP (or parent-level iap.webTypes.accessViaIAP / iap.web.accessViaIAP) can reach an IAP-protected web application (App Engine, Cloud Run, GKE Ingress, or backend service via HTTPS LB) after authenticating through Google IAP. This provides network-level reach to the backend application, though the backend's own authorization layer may further gate access.

cloudkms.cryptoKeyVersions.useToDecapsulate lets a principal decapsulate a shared secret with a KEM key.

cloudkms.cryptoKeyVersions.useToDecrypt lets a principal decrypt with the key.

cloudkms.cryptoKeyVersions.macSign on a MAC key forges message authentication codes.

cloudkms.cryptoKeyVersions.useToSign on an ASYMMETRIC_SIGN key forges signatures.

A CMEK-encrypted Secret Manager payload authenticates as another identity, completing CanExecuteAs -> CanReadSecret -> CredentialsFor.

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

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

useToDecrypt on a CMEK key resolves the key_permission condition on a CanReadData edge the consuming-service rule already emitted.

A principal that can execute as a workload SA holding useToDecrypt can decrypt.