Breaking the Cluster: A Practitioner's Guide to Kubernetes Attack Paths and How to Close Them

Kubernetes has become the de facto orchestration platform for containerized workloads across US enterprises, from financial services firms running transaction processing pipelines to healthcare organizations managing patient-facing applications. Its flexibility is a genuine engineering advantage. From a security standpoint, that same flexibility produces an environment where a single misconfiguration can cascade into a cluster-wide compromise.

Security teams tasked with auditing Kubernetes environments frequently encounter a shared challenge: the platform's complexity makes it difficult to know where to begin. This guide provides a structured entry point, covering the attack paths most commonly exploited in real engagements, the detection logic that exposes them, and the configuration controls that close them.

Understanding the Attack Progression

Successful Kubernetes attacks rarely begin with a sophisticated zero-day exploit. They begin with a foothold—typically a compromised container running a vulnerable application—and progress through a sequence of escalation and lateral movement steps enabled by permissive defaults or misconfigured policies.

The progression generally follows this pattern: initial container compromise, enumeration of the pod's service account permissions, escalation to cluster-level access, lateral movement to other namespaces or nodes, and ultimately persistence through backdoored workloads or credential theft. Understanding this progression is essential for prioritizing both detection coverage and remediation effort.

High-Value Misconfigurations: Where Attackers Look First

Overpermissive Service Account Bindings

Kubernetes automatically mounts a service account token into every pod unless explicitly disabled. In environments where service accounts have been granted broad RBAC permissions—often because developers requested elevated access during initial deployment and those permissions were never scoped down—a compromised pod inherits those permissions immediately.

Attackers enumerate service account permissions using the kubectl auth can-i --list command or by directly querying the API server using the mounted token. Permissions to create pods, read secrets, or modify cluster role bindings are particularly valuable, as each enables a distinct escalation path.

Detection: Audit service account bindings for wildcard verb grants or permissions on sensitive resources (secrets, pods, clusterrolebindings). Flag any service account with cluster-admin equivalent permissions that is mounted into a workload-facing pod.

Remediation: Disable automatic token mounting for pods that do not require API server access. Apply least-privilege RBAC bindings scoped to the specific namespace and resource types required by each workload.

Privileged Container and Host Namespace Access

Containers running with privileged: true in their security context, or with hostPID, hostNetwork, or hostIPC enabled, present a direct path to the underlying node. A privileged container can mount the host filesystem, access host processes, and in many configurations load kernel modules—effectively breaking out of the container boundary entirely.

In a penetration testing context, a privileged container on a worker node provides access to the kubelet's credentials, which can then be used to query the API server and enumerate the broader cluster.

Detection: Query the API server for pods running with privileged: true or host namespace flags enabled. In production environments, the presence of these settings in non-system namespaces warrants immediate review.

Remediation: Enforce Pod Security Admission policies at the namespace level, restricting privileged containers and host namespace access to explicitly approved system workloads. Document and justify each exception.

Exposed Kubernetes API Server and Kubelet Ports

The API server is the central control plane for the entire cluster. In environments where it is exposed without network restriction—or where the kubelet's read-only port (10255) or authenticated port (10250) is accessible from within the cluster network—attackers with pod-level access can interact directly with cluster management interfaces.

The kubelet API, when accessible, allows an attacker to execute commands within any pod on that node without going through the API server's RBAC controls. This is a significant privilege escalation vector that bypasses most standard audit logging.

Detection: From within a test pod, attempt to reach the kubelet port on the node IP (https://<node-ip>:10250/pods). Successful responses indicate the kubelet is accessible without proper network controls.

Remediation: Restrict kubelet API access using network policies or firewall rules. Ensure --anonymous-auth=false is set on the kubelet configuration and that webhook authorization is enforced.

Network Policy Gaps Enabling Lateral Movement

By default, Kubernetes applies no network restrictions between pods. Without explicit NetworkPolicy resources in place, a compromised pod can initiate connections to any other pod across any namespace within the cluster. This flat network model transforms a single compromised workload into a lateral movement platform.

In practice, many organizations deploy network policies in some namespaces and not others, or implement policies that restrict ingress but leave egress unrestricted. Attackers will enumerate reachable services from a compromised pod to identify high-value targets—database services, internal APIs, and the metadata endpoint of the cloud provider hosting the cluster.

Detection: From a test pod in each namespace, attempt connections to pods in other namespaces and to the cloud metadata endpoint (169.254.169.254 for AWS, GCP, and Azure environments). Document reachable services.

Remediation: Implement default-deny NetworkPolicy resources in every namespace, then explicitly allow only the traffic flows required by each workload. Treat namespace-level network isolation as a mandatory baseline, not an optional enhancement.

Exploit Scenarios for Internal Testing

Security teams conducting internal assessments should walk through the following scenarios to validate detection and response capabilities:

Scenario 1 — Service Account Token Abuse: Deploy a test pod with a deliberately overpermissive service account. Using only the mounted token, attempt to list secrets in other namespaces and create a new pod with elevated permissions. Verify whether the API server audit logs capture these actions and whether any alerting fires.

Scenario 2 — Privileged Container Breakout: With authorization, deploy a privileged pod and attempt to mount the host filesystem and access the kubelet credential files. Measure the time between the privileged pod deployment and detection by your security tooling.

Scenario 3 — Metadata Endpoint Access: From an unprivileged pod, attempt to reach the cloud provider metadata endpoint. Successful access may expose instance credentials with permissions extending beyond the cluster. Verify whether egress network policies prevent this access.

A Structured Audit Checklist

For teams conducting Kubernetes security reviews, the following checklist provides a starting baseline:

• Audit all ClusterRoleBindings and RoleBindings for wildcard permissions or cluster-admin grants applied to non-system accounts
• Verify automatic service account token mounting is disabled for pods that do not require API access
• Confirm Pod Security Admission is enforced at the namespace level with restricted or baseline profiles
• Scan all running pods for privileged containers, host namespace flags, and hostPath volume mounts
• Validate that NetworkPolicy resources exist in every namespace and enforce default-deny posture
• Test kubelet API accessibility from within the cluster network
• Verify API server audit logging is enabled and logs are forwarded to an external SIEM
• Confirm cloud provider metadata endpoints are blocked by egress network policy
• Review image pull policies and verify images are sourced from trusted, scanned registries
• Test RBAC controls against the scenarios described above using a dedicated test namespace

Closing Notes for Practitioners

Kubernetes security is not a configuration exercise completed at deployment time. It is an ongoing discipline requiring periodic reassessment as workloads evolve, team members change, and new platform features introduce new attack surfaces. The organizations that maintain the strongest Kubernetes security posture treat cluster audits as a recurring operational activity, not a one-time checklist.

The attack paths described here are not theoretical. They appear consistently in real engagements across industries and cluster configurations. Security teams that walk through these scenarios in their own environments—methodically, with authorization, and with detection tooling active—will understand their actual exposure far more accurately than those who rely on configuration scanning tools alone.