Derivation rules

Forging a CA-trusted cert lets the principal act as the downstream identity.

A Kubernetes ServiceAccount annotated with eks.amazonaws.com/role-arn and a matching IAM role trust policy (Federated = cluster OIDC issuer) lets any pod running as that KSA exchange its projected token for IAM role credentials via sts:AssumeRoleWithWebIdentity. Cites container-chains workload-identity-federates and federation-chains federation-maps-to-identity.

An EKS Pod Identity Association (eks:CreatePodIdentityAssociation) links a Kubernetes namespace:ServiceAccount pair to an IAM role. Pods running as that SA receive IAM credentials from the eks-pod-identity-agent at 169.254.170.23. Whoever can create or modify this association can reroute which IAM role any pod in that namespace:SA binding runs as.

Signing with a key that anchors an auth system forges the trusted identity.

Admin of a SIGN_VERIFY key can self-grant kms:Sign and forge signatures.

Cluster-admin kubeconfig -> exec any pod -> execute as every pod workload identity (cluster-wide summary edge; per-pod edges from container-chains cluster-rbac-exec).

runCommand grants cluster-wide kubectl exec; any pod's workload identity is reachable by exec-ing into the pod (container-chains cluster-rbac-exec).

A principal that can CanExecuteAs the pipeline's service-connection identity, where that identity holds ARM Contributor/Owner at subscription scope, gains a foothold in that Azure subscription.

DevOps 'Manage service endpoints' permission lets a principal create a new service connection embedding a chosen Entra SP's credentials, enabling identity-swap escalation paths.

Key Vault Administrator can sign with every signing-capable key in the vault.

Reading a secret that is a credential for a more-privileged identity is escalation.

A vault self-grant equally yields sign on every signing-capable key in the vault.

Signing with an HSM key that backs a token/cert issuer lets the caller sign as that identity.

An external CI system (GitHub Actions/GitLab CI/Azure DevOps) with an OIDC/WIF trust into a cloud role/SA can federate in as that identity; escalation roll-ups are federation-chains'.

Exec into a pod (cluster RBAC / credential / run-command) inherits the pod's mounted ServiceAccount/IRSA/Workload-Identity token, executing as that identity.

A principal whose effective permissions include key or service-account-key creation can mint new keys.

Federating in as an internal Role/ServiceAccount lets the principal act AS it, inheriting its outbound capabilities; rolled up as CanImpersonate.

Federating into a Role homed in an AWS account gives the federated principal a foothold in that account.

Federating into a ServiceAccount homed in a GCP project gives the federated principal a foothold in that project.

A realized external->internal identity mapping whose trust condition an attacker-controlled external identity can satisfy yields federation into the internal identity.

Issuing a certificate from a CA that is the trust anchor of a federation lets the issuer mint a matching external identity and federate in.

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.

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

A cert signed by the CA authenticates as the subject/SAN it names to a consuming trust.

Issue a cert for an attacker-chosen subject/SAN that a downstream trust accepts, impersonating that identity.

Workspace super-admin can authorize any service account for Domain-Wide Delegation (adding its OAuth2 client ID to the delegated clients list with chosen scopes), creating a new tenant-wide impersonation primitive.

A DWD SA with both admin-directory and cloud-platform scopes can act as a super-admin and thereby obtain GCP Organization-level control.

Service account with Domain-Wide Delegation can act as any active Workspace user in the domain for its configured OAuth2 scopes, without the user's knowledge or consent - a tenant-wide identity takeover primitive.

cloudbuild.builds.create + iam.serviceAccounts.actAs on a user SA: submit arbitrary build steps as that SA.

cloudbuild.triggers.create + iam.serviceAccounts.actAs: create a new trigger whose builds execute attacker-controlled steps as a chosen SA.

cloudbuild.triggers.update lets the principal replace a trigger's build definition (inline steps, cloudbuild.yaml path, or substitutions); the next trigger fire executes the attacker-controlled definition as the trigger's SA.

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.

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.

Holding CanPassIdentity on a target SA plus composer.environments.create gives the principal the ability to create a Composer environment running as that SA.

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.

Create a new Dataflow job whose workers run as a passable SA (dataflow.jobs.create + iam.serviceAccounts.actAs).

datafusion.instances.create + iam.serviceAccounts.actAs on a target SA: create a new Data Fusion instance whose pipelines execute as that SA.

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.

clusters.update + actAs on the new SA attaches (swaps) the cluster's runtime SA - all future jobs run as the new SA.

Create a new Dataproc cluster whose VMs run as a chosen SA (clusters.create + actAs); submit a job to execute code as that SA.

A Dataproc cluster exposes its service account's OAuth token to any code running in submitted jobs via the GCE metadata server.

Re-pointing a target's executionConfigs SA (targets.update + actAs) then promoting a rollout yields code execution as the newly attached SA.

The Cloud Deploy execution SA's Cloud Run deployment permissions (run.developer) give it CanDeploy to a Cloud Run service.

The Cloud Deploy execution SA's GKE deployment permissions (container.developer) give it CanDeploy to a GKE cluster.

Cloud Deploy job run worker (Cloud Build) executes as the target's configured execution service account.

Create a Cloud Deploy release with attacker-controlled Skaffold config + actAs(render SA) → execute arbitrary code as the render SA inside the Cloud Build worker.

Promote a Cloud Deploy release (rollouts.create) + actAs(deploy SA) → deploy Cloud Build worker executes as the deploy SA, which has runtime control over the target (GKE/Cloud Run).

A principal with deploymentmanager.deployments.create submits an attacker-controlled config; DM actuates it as the Google APIs service agent, executing code (resource creation, setIamPolicy) as that SA's identity.