create pods

Create a workload with serviceAccountName set to a privileged ServiceAccount in the same namespace.

Any controller-backed kind works, since the controller creates the pod.

The token is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token, or projected explicitly by the manifest.

Reading it back needs a channel, and the cheapest costs no RBAC at all: the container sends the token outbound itself.

This is why removing pods/log does not close the path.

With get on pods/log, the container prints the token to stdout and the attacker reads it back.

With get on pods, the container writes the token to /dev/termination-log and the attacker reads terminated.message from the pod's status, with no pods/log needed.

Authenticate as the ServiceAccount with the stolen token.

Create a PriorityClass with a very high value and preemptionPolicy PreemptLowerPriority.

Create a pod referencing that PriorityClass, with requests large enough that it only fits by evicting a running pod.

The scheduler preempts a lower-priority victim to make room.

This crosses namespaces, because priority is compared node-wide and the scheduler has no notion of which namespace owns the capacity.

The gain is scheduled capacity taken from another team, not credentials or API permissions.

An IAM role must already exist whose trust policy names the cluster OIDC provider and conditions on sub system:serviceaccount:<namespace>:<name> plus aud sts.amazonaws.com

The IAM role trusts the cluster OIDC provider and evaluates whatever token claims its trust policy names, most commonly the subject and the audience

Those conditions are policy specific rather than built into IRSA, and the ServiceAccount annotation takes no part in the authorization decision

A pod running under that ServiceAccount, projecting a serviceAccountToken with audience sts.amazonaws.com, receives an assertion STS accepts

AssumeRoleWithWebIdentity is unauthenticated, so the exchange needs no AWS credentials and returns whatever the role itself grants

create serviceaccounts/token mints the same assertion with no pod involved, and the credentials work from outside the cluster

The eks.amazonaws.com/role-arn annotation only drives the pod-identity-webhook, which injects at admission and so never reaches running pods

That annotation is also the discovery path, since it names the role and the ServiceAccount it trusts, and reading it needs only list serviceaccounts

A federated identity credential must already exist on the managed identity, naming the cluster OIDC issuer and system:serviceaccount:<namespace>:<name> as its subject

Entra matches that credential on issuer and subject alone, so the ServiceAccount name is the whole secret and no annotation takes part in the trust decision

A pod running under that ServiceAccount, projecting a serviceAccountToken with audience api://AzureADTokenExchange, receives an assertion Entra accepts

Exchanging the assertion returns an access token for the managed identity, carrying every Azure role assigned to it

create serviceaccounts/token mints the same assertion with no pod involved, and the token it buys is usable from outside the cluster

The pod label azure.workload.identity/use and the ServiceAccount client-id annotation only drive the addon webhook, a convenience for applications rather than the control

Create a hostPath PersistentVolume mounting node / (or use an existing one via a PVC)

Claim the volume from an otherwise restricted-compliant pod.

PSA does not inspect the PV behind a PVC, so even the restricted profile does not block it

Read or write arbitrary node filesystem paths.

This is T0 on control plane nodes

Or set the PV's claimRef to a victim's PVC name and namespace, including one not yet created, so the victim's future workload silently binds to attacker-controlled storage

Create a pod with spec.hostNetwork set to true.

The pod shares the node's network namespace and uses the node's address, so it is no longer on the pod network.

NetworkPolicy selects pods by their pod-network identity, so an ordinary namespace policy does not constrain it.

Some CNIs provide a separate host-level firewall that can.

Node-local services become reachable, including the kubelet on 10250 and anything bound to the node's loopback or link-local addresses.

The dependable control is Pod Security Admission at baseline or restricted, which rejects spec.hostNetwork at admission.

Create a kubernetes.io/service-account-token Secret annotated with the target ServiceAccount name.

The token controller populates .data.token with a signed JWT for that ServiceAccount which does not expire.

Population happens after the create response returns, so the token is never in the create result.

Retrieval therefore needs get, list, or watch on secrets, or a pod that mounts the Secret.

create alone mints a credential the caller cannot read.

Authenticate as the target ServiceAccount with the retrieved token.

Create a RuntimeClass whose scheduling.tolerations and scheduling.nodeSelector target a control-plane node.

Create a pod that sets only runtimeClassName.

The RuntimeClass admission plugin merges the toleration and nodeSelector into the pod spec during that same request.

The pod's own manifest carries neither field, so manifest review, GitOps diffs, and static scanning miss it.

Validating admission does see the merged spec and can still catch it.

Placement alone is a scheduling-policy bypass.

A standard pod sitting on a control-plane node reads nothing it could not read elsewhere.

It becomes host compromise only with a pod spec that reaches the host, such as privileged or a hostPath mount of /etc/kubernetes.

An IAM policy must already bind a role to the principal identifier for this namespace and ServiceAccount name in the cluster workload identity pool

No annotation and no cloud service account are involved, which is the current recommended configuration rather than a legacy one

IAM never checks that the ServiceAccount exists, so the binding can predate the object and the name can be squatted

Creating a ServiceAccount with the bound name, or running a pod under it, claims the identity

Pods then obtain tokens for that principal carrying the roles bound to it, with no annotation anywhere in the chain

The metadata service answers any caller that can reach it, and returns credentials for the node identity rather than for any workload identity

Whether an ordinary pod can reach it is a platform and provisioning property, not a Kubernetes one, so the required pod shape differs per cluster

Where the address is redirected per pod network namespace, as GKE does with GKE_METADATA, a hostNetwork pod runs in the host namespace and reaches the real service

Where nothing intercepts it, which is the AKS default and the eksctl default on EKS, a plain unprivileged pod reaches it with no host access at all

On EKS the barrier is the IMDSv2 hop limit of 1, and it holds only while tokens are required.

An IMDSv1 GET is not hop limited and returns the credentials anyway

Workload identity does not prevent this.

It changes which credential the SDK resolves, not which address the pod can reach, and a hostNetwork pod always reaches it

Mounting the host root as root is an independent second route, reading the kubelet credentials and the cloud provider config from disk

The node identity ceiling varies from no cloud permissions at all to full control of the node resource group, so read its role bindings before rating impact