← All walkthroughs

Kubernetes: exposed workload to cluster-admin

From an exploitable pod, through a container escape and a service-account token, to control of the whole cluster — mapped to the MITRE ATT&CK Containers matrix.

Kubernetes cluster Advanced KubernetesContainersCloud-native
Authorized testing only. This is a conceptual, defensive-aware walkthrough that maps an attack path to MITRE ATT&CK, detection and mitigation, and links to references for the detail. It is not a copy-paste playbook. Use it only against systems you own or are explicitly permitted to test.

Scenario

An authorized assessment of a Kubernetes platform. A public-facing application running in a pod has an exploitable flaw. The objective is to show whether a compromised workload can take over the cluster.

Practice this path: Containers & Kubernetes · Cloud attacks
  1. 1

    Initial Access

    Compromise a workload

    T1190 Exploit Public-Facing Application

    Exploit the in-scope application flaw to obtain command execution inside its container — the starting point is an ordinary pod, not the host.

    Detection

    Web-tier exploitation signatures plus a container process spawning a shell are visible to admission/runtime security tooling.

    Mitigation

    Patch workloads, run them read-only and non-root, and enforce the Restricted Pod Security Standard.

    References kubernetes-pentest · file-upload-bypass
  2. 2

    Discovery

    Survey the container and its identity

    T1613 Container and Resource DiscoveryT1552.001 Unsecured Credentials: Credentials In Files

    Examine the container for its mounted service-account token, environment, capabilities and whether host namespaces or sensitive mounts are exposed — the inputs that decide if escape is possible.

    Detection

    Reads of the service-account token path and in-pod enumeration can be caught by runtime sensors (Falco-style rules).

    Mitigation

    Set automountServiceAccountToken: false where not needed, drop capabilities, and forbid hostPath/host namespaces via policy.

    References kubernetes-pentest · docker-security
  3. 3

    Privilege Escalation

    Escape to the node (if misconfigured)

    T1611 Escape to Host

    Where the pod is privileged or over-permissioned (privileged flag, host mounts, dangerous capabilities), demonstrate a break-out to the underlying node; otherwise, document that escape was not possible as a positive finding.

    Detection

    A container process acting on the host (mount, nsenter-like behaviour, writes to host paths) is a high-severity runtime alert.

    Mitigation

    Never run privileged pods for workloads, block hostPath mounts and CAP_SYS_ADMIN, and enforce Pod Security Admission.

    References docker-security · kubernetes-pentest
  4. 4

    Credential Access

    Use the service-account token against the API

    T1552.007 Unsecured Credentials: Container API

    Query the Kubernetes API with the pod's service-account token to learn exactly what the identity may do — the real privilege boundary in a cluster.

    Detection

    API-server audit logs show the service account's requests; unusual verbs (secrets list, pods/exec) stand out.

    Mitigation

    Least-privilege RBAC per service account, no wildcard verbs, and tight control over secrets and pods/exec.

    References kubernetes-pentest
  5. 5

    Lateral Movement / Impact

    Leverage RBAC to control the cluster

    T1610 Deploy ContainerT1053.007 Scheduled Task/Job: Container Orchestration Job

    If the identity (or a reachable one) holds powerful RBAC, demonstrate control by scheduling a workload onto other nodes or reading cluster-wide secrets, proving the blast radius and then cleaning up.

    Detection

    Creation of privileged pods/daemonsets, cronjobs, and cluster-wide secret reads are critical API-audit events.

    Mitigation

    Separate workload and admin RBAC, restrict pod-creation rights, use namespaces plus NetworkPolicies, and alert on privileged pod creation.

    References kubernetes-pentest

Key takeaways

  • A pod is only a weak boundary when it is privileged or over-permissioned — configuration decides everything.
  • The service-account token and its RBAC are the true privilege boundary; scope them tightly.
  • Pod Security Admission (Restricted), no privileged pods, and least-privilege RBAC break this chain early.