Privilege Escalation Paths

Send Impersonate-User: cluster-admin header to the API server

API server evaluates all RBAC as the impersonated user

Read all secrets or perform any cluster-admin action

Send Impersonate-User together with Impersonate-Group: system:masters.

Kubernetes rejects group impersonation without an impersonated user.

The API server authorizes the request as a member of system:masters, a built-in group with unrestricted API-server access that bypasses RBAC/Webhook restrictions.

Perform any cluster-wide action.

Impersonate system:serviceaccount:kube-system:clusterrole-aggregation-controller

That SA has escalate on all ClusterRoles by default

Patch own bound ClusterRole to inject */* rules via impersonation

Use the escalate verb to bypass privilege-escalation prevention

Patch own bound ClusterRole to add */* rules (must be a role already bound to you)

Permissions expand via the existing binding.

No bind is needed when patching an already-bound ClusterRole.

Creating a new role and self-binding it requires bind clusterroles separately

Use escalate on roles to bypass the check that normally prevents writing permissions you do not already hold.

Create or update a Role granting arbitrary permissions in the namespace.

Activate it with a RoleBinding.

Creating or changing the binding still needs bind on the referenced Role, or the caller must already hold the referenced permissions.

The bind verb bypasses escalation prevention on ClusterRoleBindings

Create a ClusterRoleBinding from cluster-admin to your own identity

You now hold cluster-admin

A RoleBinding can reference a ClusterRole.

This is valid RBAC.

The ClusterRole's permissions are scoped to the RoleBinding's namespace.

Cluster-scoped resources remain inaccessible.

bind on clusterroles bypasses the escalation check.

Create a RoleBinding to cluster-admin or any ClusterRole you don't fully hold.

Full control over namespace-scoped resources in that namespace, but cluster-scoped resources remain blocked.

This reaches T0 in kube-system via controller SA tokens and Secrets.

Patch the subjects array of an existing ClusterRoleBinding

Kubernetes applies the same escalation check as CREATE, requiring bind on the referenced ClusterRole or already holding all its permissions

Useful for maintenance if you already hold bind.

It is not an independent bypass of the escalation check

Create or update a ClusterRole with an aggregation label such as rbac.authorization.k8s.io/aggregate-to-admin: true.

The ClusterRole aggregation controller merges its rules into the built-in admin/edit/view role.

Prevention applies at write time.

Without escalate, only rules the caller holds can be injected.

With escalate, any rules can be injected regardless of caller permissions.

All principals bound to the role gain injected permissions.

T0 only where admin/edit is cluster-bound or the namespace holds cluster-admin credentials.

Identify a running pod you have patch access to, ideally one already carrying a privileged or high-value ServiceAccount.

Patch spec.containers[*].image.

Container images are among the few pod spec fields Kubernetes allows mutating after creation.

patch alone is enough.

A raw JSON Patch naming the container index needs no read, while kubectl patch additionally needs get because it fetches current state to compute the merge.

The kubelet detects the definition change, kills the container, and restarts it running the new attacker-controlled image.

The new container inherits the pod's existing ServiceAccount token, mounted volumes, and any host namespaces or capabilities already granted.

NetworkPolicy podSelector matches on a running Pod's labels, re-evaluated continuously, not fixed at creation

Patch the label a restrictive NetworkPolicy selects on to a value outside its selector

The same running Pod, same IP, same containers, is no longer covered by that policy's ingress/egress rules

Traffic that was blocked moments earlier now flows, with no image or spec change at all

Patch a NoExecute toleration onto an already-running Pod.

Tolerations are one of the few pod spec fields addable after creation

An incident responder later taints the suspect node NoExecute to evict everything running on it

The taint manager evicts every Pod without a matching toleration.

The pre-patched Pod is skipped and keeps running

A backdoor Pod outlives the exact response action meant to remove it from the node

Create a pod with privileged + hostPID or hostPath mounting /

Set spec.nodeName to a specific control plane node to force placement there.

Taints are scheduler-only checks, so no toleration is needed

chroot or nsenter into the host to gain root on the node

Read /etc/kubernetes/pki, steal kubelet cert or SA tokens.

This is T0 on the control plane

Create a pod using hostNetwork, hostPID, hostIPC or hostPath as available

hostNetwork reaches cloud metadata and the API server from the node network namespace.

hostPID reads host process env vars

hostPath to / reads other pods' SA tokens under /var/lib/kubelet and the cluster CA private key if scheduled on a control plane node

Compromise a scheduler component, built-in or custom, whose ServiceAccount holds create on pods/binding but not pods itself, matching the real system:kube-scheduler role

RBAC cannot filter by a Pod's schedulerName field, so any Pod already Pending in the cluster is fair game, not only ones addressed to that scheduler

Create a Binding object for a target Pod naming the desired Node directly, skipping the scheduler's own logic entirely

The kubelet does not re-check taints at admission, so the Pod runs even on a NoSchedule-tainted node with no matching toleration

Admission policy engines typically register their webhook on pods CREATE/UPDATE only.

Binding is a different subresource they never inspect, so node-placement policies never see it

Targeting a control plane node places a workload past the taint meant to keep it off.

Combined with a privileged/hostPath Pod spec, this reaches node compromise

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.

get on pods/log returns it if the container prints it to stdout.

Without pods/log, write it to /dev/termination-log and read terminated.message from the pod's status, which needs get on pods.

Neither verb is needed if the container sends the token outbound itself, which is why removing pods/log does not close this.

Authenticate as the ServiceAccount with the stolen token.

Create a pod with a gitRepo volume whose repository contains an ext:: command

kubelet runs git clone as root, executing the injected command on the node

Exfiltrate node credentials.

This is T0 on control plane nodes

Create a DaemonSet with tolerations using operator Exists so it schedules onto every node, control plane included.

create alone is enough.

The DaemonSet controller creates the pods, so the caller never needs a pods verb.

Put privileged and hostPID in the pod template to reach the host namespaces.

Pod Security Admission evaluates each generated pod against its namespace labels, so a baseline or restricted namespace rejects them and the DaemonSet reports failures instead.

Where the namespace does not enforce pod security, this is root on every node at once.

Patch or update an existing Deployment, DaemonSet, or StatefulSet pod template, or a CronJob's jobTemplate.

Add an attacker sidecar or replace the image.

A Deployment rolls out at once, as do DaemonSets and StatefulSets under the default RollingUpdate strategy.

Under updateStrategy OnDelete they wait for pod recreation.

A CronJob applies the change on its next scheduled run with no extra trigger.

Code runs with the workload's existing ServiceAccount, which is T0 for kube-system workloads.

Patch or update an existing ReplicaSet or ReplicationController pod template

The change does not affect already-running pods.

ReplicaSet/RC only apply the template to pods they create afterward

Wait for or force pod replacement, using manual scale, pod deletion, node eviction, or voluntary disruption

The replacement pod is created from the poisoned template and inherits the workload's existing SA

Update alone forces replacement by scaling replicas (0 then 1).

Delete on pods is not required, it only makes replacement immediate without changing the replica count

With patch or update on a namespaced object, set metadata.ownerReferences to point at an owner that does not exist, using a resolvable apiVersion and kind with any name and UID.

The garbage collector resolves the reference, confirms the owner is absent, and deletes the object within seconds on the next sync.

No delete permission on the object is required, and no ownership check runs unless the OwnerReferencesPermissionEnforcement admission plugin is enabled, which it is not by default.

Applies to any namespaced resource the principal can patch or update, turning patch rights into a deletion primitive for objects that delete access would otherwise gate.

Hold update on the pods/status subresource, a grant separate from update on pods itself.

The kubelet normally owns these fields

Forge status.podIP on a Service backend pod.

kube-proxy programs the forged IP into the pod's EndpointSlice and routes live Service traffic there, blackholing or redirecting connections

Or forge the Ready condition, marking a healthy backend NotReady to drop it from the Service, or marking an unhealthy pod Ready to insert it into the ready endpoint set

The kubelet reverts status within seconds, but kube-proxy consumes the forged state during that window.

A slow readiness probe cadence widens it

No write access to Services, Endpoints, or EndpointSlices is required

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.

A PodDisruptionBudget only constrains the eviction subresource.

The core pod delete path never consults it

Delete a PDB-protected pod directly with delete on pods.

The API server removes it without checking the budget

This defeats a control that blocks kubectl drain, cluster autoscaler consolidation, and node upgrades from disrupting the pod

Same end state as an allowed eviction but reachable when eviction is refused.

It also forces recreation, pairing with template-poisoning that only lands on pod replacement

Leader election for control-plane components like the scheduler and controller-manager is coordinated through a Lease in kube-system

Patch the component's Lease to set holderIdentity to a foreign value with a fresh renewTime, so the running leader observes a conflicting holder

The real component stops leading and its static pod crashes.

A full crash, restart, and re-election cycle runs for tens of seconds with no scheduler or controller acting

Repeating the patch after each recovery compounds kubelet CrashLoopBackOff, sustaining and lengthening the outage

Enumerate pods to find one running as root, privileged, or with a powerful SA

Exec or attach into it

Steal the mounted SA token, access the node, or move laterally

If the pod sets shareProcessNamespace, the exec'd container sees every sibling container's processes and /proc, letting the attacker read another container's env vars and in-memory secrets

Update pods/ephemeralcontainers to inject a debug container into an existing running Pod.

The debug container runs in the target Pod context and can access the Pod's mounted volumes, ServiceAccount token, and selected process namespace depending on target/runtime support.

Powerful lateral movement inside privileged Pods.

Not the same as kubectl debug node/<name>, which requires create pods and spawns a separate privileged Pod.

list or watch secrets cluster-wide, or in kube-system alone, and receive every Secret's data in the response.

Auto-created ServiceAccount token Secrets are gone from modern clusters, so what is harvested is whatever was deliberately stored.

That is the credential material the cluster actually runs on, including registry pull secrets, database and cloud credentials, TLS private keys, and any long-lived token created on purpose.

Revoking the permission afterwards does not undo the exposure.

Every credential returned stays valid until it is individually identified and rotated.

get or list secrets in an accessible namespace

Extract cloud API keys, DB credentials, TLS keys, or kubeconfigs

Use the credentials to escalate inside or outside the cluster

get a known service-account-token Secret name in kube-system.

Before 1.24, these were auto-created for every ServiceAccount under a predictable name, so they could simply be guessed

Auto-creation is off by default from 1.24, so on a current cluster the Secret has to already exist, and operator-managed clusters commonly keep one

Where secrets-create is also held, the precondition can be manufactured rather than found.

Annotate a new Secret for a privileged ServiceAccount, and the token controller fills in the token

Reuse the controller ServiceAccount token for cluster-admin-equivalent access.

Tokens from Secrets carry no expiry claim, so the access does not lapse

Identify a high-privilege ServiceAccount in scope.

The clusterrole-aggregation-controller SA in kube-system has effective cluster-admin rights and is a prime target.

Mint a bound token through the TokenRequest API with an extended lifetime, for example --duration=87600h for ten years.

The API server honors the request unless --service-account-max-token-expiration is set.

kubeadm does not set it, so the full 87600h is issued.

Managed providers commonly do set it.

Authenticate as the ServiceAccount with the minted token.

T0 when targeting kube-system controller service accounts such as clusterrole-aggregation-controller or kube-controller-manager.

An IAM role must already exist whose trust policy names the cluster OIDC provider plus this namespace and ServiceAccount

Add the eks.amazonaws.com/role-arn annotation naming that role to the ServiceAccount

Pods using the ServiceAccount receive credentials for the role, bounded by whatever that role grants

An IAM policy binding must already grant this namespace and ServiceAccount roles/iam.workloadIdentityUser on the target GCP service account

Add the iam.gke.io/gcp-service-account annotation naming that service account

Pods using the ServiceAccount obtain GCP tokens carrying exactly that account's IAM roles

A federated identity credential must already exist on the managed identity, matching the cluster issuer and this namespace and ServiceAccount as subject

Label the ServiceAccount azure.workload.identity/use and annotate it with the identity's client ID

The workload identity webhook projects a token for that managed identity into pods using the ServiceAccount

Connect to the exec endpoint via WebSocket.

The HTTP GET upgrade handshake maps to the 'get' verb at the kubelet, so get nodes/proxy alone is sufficient

The kubelet never performs a secondary 'create' check for the exec operation that follows the handshake

Path A, via API server proxy, uses curl with Upgrade: websocket headers.

Auth is logged as a nodes/proxy check only, the actual exec is invisible to audit

Path B is direct to the kubelet on port 10250, using websocat wss://$NODE_IP:10250/exec/....

Zero API server audit events are generated

Execute arbitrary commands in any pod on the node, and steal service account tokens to pivot

Register a fake Node object with status.addresses[InternalIP] = API server internal IP and daemonEndpoints.kubeletEndpoint.Port = 6443

Proxy a request through the fake node by running kubectl get --raw /api/v1/nodes/evil-node/proxy/api/v1/secrets

The API server proxies outbound to that address using its apiserver-kubelet-client certificate, so it authenticates to itself

Before kubeadm 1.29 the certificate carried O=system:masters.

From 1.29 it carried O=kubeadm:cluster-admins, a group bound to cluster-admin, so the inner request still returned full cluster access

Current kubeadm binds the certificate to system:kubelet-api-admin instead, narrowing the inner request to the node API (nodes/proxy, metrics, stats, log) rather than cluster-admin

The redirection itself is unchanged by that fix, so the API server can still be pointed at an attacker-chosen address

Post-fix, the gain is network position rather than RBAC, since triggering it already requires get on nodes/proxy.

The API server reaches addresses the caller cannot, under its own identity

Register a fake Node with a DNS rebinding hostname that initially resolves to a valid public IP

API server checks isProxyableHost before connecting.

At check time, DNS resolves to the allowed IP

By connect time, DNS flips to 127.0.0.1 or 169.254.x.x.

The blocklist check is not re-run (TOCTOU)

SSRF reaches loopback services such as kube-proxy :10249 configz, etcd :2379, and control-plane localhost ports

Read kubelet-managed logs for pods and system components on a node.

Through the API server proxy this is gated by nodes/proxy.

nodes/log applies to a direct kubelet connection on port 10250

Applications commonly log credentials, tokens, connection strings, and startup configuration.

Harvest high-value secrets without exec access.

On vulnerable Windows nodes with NodeLogQuery, CVE-2024-9042 made this a command-injection path.

After compromising one node, patch other nodes with NoSchedule/NoExecute taints

Sensitive pods are forced to reschedule onto the compromised node

Stealing their tokens or intercepting traffic is a separate step needing its own access on the compromised node (secrets read, exec, or hostNetwork).

Tainting only performs the steering

Create a MutatingWebhookConfiguration with clientConfig pointing at a server you control that the API server can reach.

Set rules to match CREATE on the resources you want, for example pods and secrets, across all namespaces.

Every matched object is sent to the webhook and comes back patched, so sidecars can be injected and securityContext stripped.

failurePolicy sets the trade.

Fail makes the mutation reliable but breaks admission whenever the endpoint is down, while Ignore is quieter and silently skips objects.

sideEffects and admissionReviewVersions must be declared or the API server rejects the configuration.

Create a ValidatingWebhookConfiguration whose rules match the kinds you want to read.

Validating webhooks receive the full object, so Secret and ConfigMap contents leave the cluster on every admission.

The configuration write and each triggering request are both recorded in the audit log.

What no Kubernetes log holds is the payload sent outbound, so the copy itself leaves no cluster-side record.

failurePolicy Ignore keeps admission working when the endpoint is unreachable, which is what makes it quiet.

Delete the ValidatingWebhookConfiguration or MutatingWebhookConfiguration objects that back a policy engine.

Third-party enforcement such as Gatekeeper, Kyverno, or image signature verification stops rejecting anything.

Pod Security Admission is unaffected.

It is a built-in API server controller rather than a webhook, so namespace enforce labels still apply.

On its own this only removes a guard.

It becomes privilege only alongside a verb that creates the workload the webhook was rejecting.

Enumerate User subjects already bound to cluster-admin or other high-privilege ClusterRoles via kubectl get clusterrolebinding.

Create a CSR using a CN matching one of those usernames and request the kubernetes.io/kube-apiserver-client signer.

Approve the CSR.

This requires both update on certificatesigningrequests/approval and approve on signers for that exact signerName.

The built-in signing controller issues a real, CA-signed certificate automatically.

No CA key or extra access is needed from the caller.

The cert authenticates as the matched username, inheriting all its RBAC permissions.

It works until expiry.

Individual revocation requires CA rotation.

Create an APIService for an API group pointing at an attacker-controlled backend

Requests for that group are proxied with trusted X-Remote-User and X-Remote-Group identity headers.

Caller bearer tokens and TLS certificates are NOT forwarded to the backend

Observe or spoof responses for the claimed API group.

This gives data interception within that group, not a generic credential-theft primitive

Create a CRD that registers a conversion webhook pointing at an attacker-controlled server.

Every read and write of that custom resource type is routed through the webhook, which can read and rewrite objects in flight.

The API server requires a CA bundle and TLS, so this needs a serving certificate the API server will accept.

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

With patch on namespaces, remove the pod-security.kubernetes.io/enforce label from an existing namespace, or set it to privileged, disabling PSA there

Or with create on namespaces, create a fresh namespace with no PSA label at all, which starts permissive

Either path assumes no restrictive cluster-wide default (AdmissionConfiguration).

With such a default, both fall back to it instead of to permissive

Create privileged pods freely in the now-unenforced namespace

Create a permissive PSP and bind it, or delete the restrictive PSP

All pod-security guardrails are removed cluster-wide

Create privileged pods.

This only applies to clusters before 1.25

This is EKS-specific and requires the cluster's authentication mode to be CONFIG_MAP or API_AND_CONFIG_MAP.

A cluster fully migrated to API mode ignores this ConfigMap entirely.

If aws-auth doesn't exist yet (self-managed clusters, or a fresh EKS cluster before it's applied), create it directly instead of patching.

Patch or create the aws-auth ConfigMap in kube-system, mapping your AWS IAM ARN to the system:masters group

Authenticate via AWS CLI as cluster-admin

Delete the NetworkPolicy that isolates the target workload.

A pod is only isolated while some policy selects it.

Once the last selecting policy is gone, the pod accepts traffic from anywhere again.

Where another policy still selects the pod, deletion narrows nothing and the remaining policy keeps enforcing.

Previously unreachable workloads become reachable for lateral movement, and monitoring that relied on the policy blocking traffic sees nothing change.

Create or modify Endpoints or EndpointSlices so a Service resolves to addresses it was never meant to reach, such as node-local services or an attacker-controlled host.

kube-proxy programs those addresses and every client of that Service follows them.

Callers keep using the Service name they trust, which is what makes the Service the confused deputy.

End-to-end delivery depends on the CNI and kube-proxy mode in use, so the reachable destination set varies by cluster.

Use services/proxy through the API server

Reach internal Services that do not require authentication internally

Access dashboards, metrics-server, or internal admin APIs

Read Node objects with get and list on nodes.

The flannel.alpha.coreos.com/public-ip annotation gives each node's underlay IP, backend-data gives its VTEP MAC, and spec.podCIDR gives the pod range

This requires a host with flat L2 reach to the node underlay and CAP_NET_ADMIN, such as a bastion, a compromised VM, or a hostNetwork pod with NET_ADMIN

Build a matching device there with ip link add flannel.1 type vxlan id 1 dev eth0 dstport 8472 nolearning

Add the peer by hand with bridge fdb append <vtep-mac> dev flannel.1 dst <node-underlay-ip> self permanent, then ip neigh add <pod-cidr-base> lladdr <vtep-mac> dev flannel.1

Route into the pod range sourced from the attacker's own underlay IP so replies return, using ip route add <pod-cidr> via <pod-cidr-base> dev flannel.1 onlink src <attacker-underlay-ip>

Reach pod IPs directly, defeating Service-level abstraction.

A Service with no endpoints silently drops traffic while the pod IP behind it still answers

Workloads deliberately hidden from this principal become reachable.

The RBAC half is only get and list on nodes, and the rest of the cost is root on an underlay-connected host.

Create or patch a Service and set spec.externalIPs to an address used by another pod, a node, or an off-cluster host.

kube-proxy programs DNAT for that address on every node, sending traffic for it to the Service's endpoints.

NetworkPolicy does not contain this, since policy selects on pod addresses rather than on a Service's externalIPs.

The API server accepts an address already claimed as another Service's ClusterIP.

Which rule wins is decided by the dataplane, not by validation.

Behaviour differs by kube-proxy mode.

iptables favours the first matching rule, while IPVS and eBPF dataplanes resolve collisions on their own terms, so confirm the mode before relying on precedence.

Update the CoreDNS ConfigMap in kube-system to add a rewrite rule or a stub zone.

CoreDNS reloads its configuration within seconds without a restart.

Every pod in the cluster then resolves the targeted name to an address of your choosing.

Whether that yields credentials depends on the client.

It needs a listener on the redirected address and a client that does not verify the server certificate against the name it asked for.

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 pod targeting a Windows node with spec.securityContext.windowsOptions.hostProcess: true

Container starts as NT AUTHORITY\SYSTEM in the host network and volume namespaces

Windows HostProcess is blocked by both Baseline and Restricted Pod Security Standards.

Only namespaces enforcing Privileged level or unlabeled namespaces are vulnerable

Full Windows node compromise follows, with lateral move to other workloads or extraction of node credentials

Create a MutatingAdmissionPolicy whose CEL sets privileged and hostPID on every pod spec.

Create a MutatingAdmissionPolicyBinding for it.

A policy with no binding never runs.

Mutating admission completes before validating admission, so Pod Security Admission evaluates the mutated pod and rejects it in a namespace enforcing baseline or restricted.

Where no namespace enforces pod security, the mutation stands and every new pod there runs privileged with host access.

A MutatingAdmissionPolicy must already exist in the cluster with no binding, so it is dormant and not enforced.

Create a MutatingAdmissionPolicyBinding naming it, which matches cluster-wide unless matchResources narrows it.

The policy takes effect on the next CREATE.

What it does is whatever that policy already specifies, which may be harmless.

Create a ValidatingAdmissionPolicy with a CEL expression that denies creation of pods or another critical resource.

Create a ValidatingAdmissionPolicyBinding targeting all namespaces.

A policy without a binding is not enforced.

Every matching create is rejected cluster-wide, so deployments, scaling, and recovery all stall until the policy is found and removed.

This denies and never grants.

It is a persistent control-plane denial of service, not a route to any additional identity or credential.

Patch an existing MutatingWebhookConfiguration to replace the clientConfig.url with an attacker-controlled endpoint

All requests matching the webhook's existing rules are now proxied through the attacker server

Capture SA tokens and secrets.

Silently mutate pod specs or block deployments

Create a ClusterTrustBundle containing a CA certificate you control.

Nothing trusts it on creation.

Only pods that project it through a clusterTrustBundle volume read the bundle at all.

Those pods then accept certificates signed by that CA, so the TLS connections they make can be intercepted.

Workloads using the container image's own CA store, which is the common case, are unaffected.

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.

Proxy an HTTP request through the API server to a known Pod name and port

Reach an internal admin, debug, metrics, or application endpoint not exposed externally.

NetworkPolicies do not apply to API-server-proxied traffic

Extract credentials or invoke privileged application actions via the unauthenticated internal endpoint

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.

Create a StorageClass, or patch an existing one, and set the storageclass.kubernetes.io/is-default-class annotation to make it the cluster default

The API server allows more than one default class, and the DefaultStorageClass plugin breaks the tie by newest creationTimestamp, so a freshly created default wins without touching the existing one

With reclaimPolicy Retain on that class, the provisioned volume and its data survive deletion of the requesting namespace

Every PersistentVolumeClaim that omits storageClassName then binds through the attacker class.

Patch alone also suffices, since it moves the annotation between existing classes with no create

Create a PodDisruptionBudget whose selector matches the attacker pod, with minAvailable 1 or maxUnavailable 0.

The eviction API refuses to remove the pod and returns 429, so kubectl drain retries and then gives up.

A bare pod is enough.

The budget reports disruptionsAllowed 0 with reason InsufficientPods, which blocks eviction just as effectively.

This binds the Eviction API only.

Deleting the pod outright, drain --disable-eviction, deleting the budget, or deleting the owning controller all get past it.

The value is delay and friction during maintenance or incident response, not durable persistence.

Create a HorizontalPodAutoscaler targeting a workload with a high minReplicas floor

The controller scales the target to minReplicas immediately, with no metrics-server or metric data required

Used for resource exhaustion, or to multiply the replicas of a workload whose pod template already carries elevated privileges

With create on the pods/eviction subresource alone, and no pod get, list, or delete, evict a named victim pod

Forces the victim workload to reschedule, which can move it onto an attacker-controlled node, or cause targeted disruption

A privileged operator or controller renders an object like a pod from a ConfigMap it owns, then applies it under its own cluster-wide ServiceAccount

Write access to that ConfigMap (get plus patch or update) lets an attacker set the rendered pod privileged with hostPID, or supply arbitrary manifests, without holding those rights directly

For example, the local-path volume provisioner builds its helper pod from its local-path-config ConfigMap.

Poisoning that ConfigMap runs an attacker command as root on a node whenever a PVC is provisioned.

Trigger it with an ordinary PVC and pod in the attacker's own namespace.

The attacker borrows the controller identity.

A GitOps controller is the same pattern, applying attacker manifests cluster-wide

Patch the subjects array of an existing RoleBinding to add the attacker.

The roleRef field is immutable, so the Role or ClusterRole it points at cannot be swapped for a more privileged one

Kubernetes applies the same escalation check as create, requiring bind on the referenced Role or ClusterRole, or already holding all of its permissions

Yields whatever that binding already grants, scoped to its namespace.

This is not an independent bypass of the escalation check

The external-attacher CSI sidecar reconciles VolumeAttachment objects and reads status.attached to decide whether a volume is still attached to a node

Write status.attached false through the volumeattachments/status subresource.

The same write aimed at the main resource returns success and is silently dropped

The attacher acts on the reported state and can detach a volume that a running pod still has mounted, so in-flight writes fail with I/O errors

spec is immutable after creation, so an attachment cannot be retargeted to another node or volume.

Only the reported state can be corrupted

Inert without a registered CSI driver running an external-attacher sidecar.

On a cluster with no such driver, the object is reconciled by nothing

Delete the CRD that a security controller or operator reconciles.

Deleting a CRD garbage-collects every custom resource of that type, so the controller's policy objects go with it.

Whether the controller then fails open or fails closed is implementation-specific.

Losing its input can equally stop it admitting anything.

Treat this as loss of a control and of its configuration, not as a reliable route to a privileged workload.

Create a portforward request against a known pod and port.

The API server opens a stream to the kubelet, which connects to that port inside the pod.

The caller's own machine now talks to the pod's listener directly, with no route into the pod network and no Service or Ingress in front of it.

Databases, admin consoles, and debug handlers bound inside the pod are reachable, including ones bound to loopback that no Service could expose.

The tunnel is not pod-to-pod traffic, so a NetworkPolicy written to isolate the workload does not apply to it.

Unlike the API-server proxy subresources, this needs no HTTP semantics.

Any TCP protocol works, which is what makes it useful against non-HTTP listeners.

Create a second NetworkPolicy selecting the same pods, with an unconditional allow rule for ingress or egress.

Allowed traffic is the union of every policy that selects the pod, so the permissive rule reopens what the restrictive policy closed.

The restrictive policy is untouched and still present, so an audit or GitOps diff of existing objects shows it intact.

Patching an existing policy reaches the same result by adding allow rules or by narrowing its podSelector so it stops selecting the target.

Quieter than deletion, because nothing that was there is missing.

The new object is the only evidence.

Create a PriorityClass with globalDefault true.

Every pod created afterwards with no priorityClassName inherits that priority, cluster-wide.

No pod create verb is needed.

The effect lands on other people's future workloads, not on one the attacker submits.

Existing pods keep the priority they were admitted with, so the change is invisible until the next rollout.

Only one PriorityClass may be the global default, so setting it also displaces whatever the platform team configured.