KubernetesWorkload

A principal with Kubernetes cluster-admin RBAC (system:masters binding or equivalent ClusterRole: cluster-admin) can exec into any pod in any namespace via pods/exec. This gives OS-level code execution and access to the pod's mounted SA token / IRSA credential. Matches CanModifyConfiguration on the cluster (indicating cluster-admin access establishment).

Exec into a running pod (via cluster-admin or direct pods/exec RBAC) inherits the pod's mounted IRSA or Pod Identity token, executing as the pod's IAM role. Cites container-chains cluster-rbac-exec; dedupes on (CanExecuteAs, principal, role).

A pod whose ServiceAccount has an IRSA annotation executes as the annotated IAM role (credentials delivered by token projection + STS).

A pod whose SA is linked via an EKS Pod Identity Association executes as the associated IAM role (credentials delivered by the pod-identity-agent DaemonSet at 169.254.170.23).

A Kubernetes pod/deployment references (pulls and runs) a container image from an ECR repository. Records the tag/digest for mutability assessment.

A cluster-admin kubeconfig (from listClusterAdminCredential) grants kubectl exec into any pod in the cluster.

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).

Node-level code execution (privileged pod, hostPID, DaemonSet exec) reaches the node IMDS and mints a token for the node system-assigned / kubelet MI.

Azure Kubernetes Service RBAC Cluster Admin role (Azure RBAC mode) maps to k8s cluster-admin, granting kubectl exec on every pod.

managedClusters/runCommand/action runs arbitrary kubectl/helm inside the cluster, bypassing network isolation; equivalent to cluster-wide kubectl 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).

runCommand/action can kubectl-apply attacker manifests - new/patched Deployments - changing what code runs as each workload identity.

Modify the buildspec/pipeline/runbook/template a runner executes, then run it, to execute as the runner's service identity.

Triggering a pipeline reaches each downstream stage runner it orchestrates; propagate CanTrigger to those runners.

Trigger/start a runner whose current definition already runs attacker-influenced code, executing as the runner's identity.

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

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.

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.

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.

Pushing/overwriting an image in a registry poisons every workload that pulls it - code control propagates from the registry to each consuming Compute/KubernetesWorkload.

A workload poisoned via a registry image push runs as its identity, so the pusher executes as that identity.