How to Tame Kubernetes Security: From Roles to Token Risks

What is Kubernetes

Kubernetes is a container‑orchestration platform that automates the deployment, scaling, and lifecycle management of containerised applications. It provides a unified control plane (API server, scheduler, controller manager) and a set of extensible resources that enable large‑scale micro‑service architectures.

Security‑relevant resources

Roles – Defined by Role and ClusterRole objects and bound to users or ServiceAccounts via RoleBinding / ClusterRoleBinding. They implement fine‑grained RBAC permissions.

Pods – The smallest execution unit in Kubernetes. Containers in a Pod share a network namespace and storage volumes. If a Pod is compromised, an attacker can use its network connectivity and mounted credentials to move laterally inside the cluster.

Attack surface

The complexity of Kubernetes creates two broad attack directions:

Escaping the container sandbox to gain host access.

Moving laterally within the cluster after gaining a foothold inside a Pod.

Container escape

Exploiting kernel bugs, container‑runtime vulnerabilities, or vulnerable applications can break out of the container isolation layer. On a Kubernetes node, a successful escape gives the attacker control over the host OS and, consequently, over all workloads scheduled on that node.

Lateral movement inside the cluster

Once inside a Pod, an attacker can:

Abuse overly permissive Role / ClusterRole bindings to list or modify resources.

Exploit misconfigured NetworkPolicy that permits unrestricted pod‑to‑pod traffic.

Leverage known vulnerabilities in Kubernetes components (kube‑apiserver, kubelet, etc.).

These actions can lead to privilege escalation, where the attacker obtains control‑plane rights (e.g., system:master or cluster-admin) and can fully compromise the cluster.

ServiceAccount tokens

Every Pod automatically receives a ServiceAccount token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token unless the feature is disabled. The token is a JWT that the pod can present to the kube‑apiserver to authenticate as the associated ServiceAccount.

If the token has permission to read Secret objects, the attacker can request the cluster‑admin token stored in a secret, achieving total takeover.

Pod creation permission risk

Even a seemingly harmless create pod permission is dangerous because the attacker can:

Specify arbitrary container commands or entrypoints, effectively executing any code on the node.

Mount any ServiceAccount, including high‑privilege accounts, thereby inheriting their permissions.

This combination enables direct privilege escalation and cluster compromise.

Managed vs. self‑hosted clusters

Managed services (AKS, EKS, GKE, etc.) offload control‑plane operation to the cloud provider, reducing the operational burden of upgrades, patching, and high‑availability management. Self‑hosted clusters require teams to manage control‑plane components, apply security patches, handle scaling, and ensure availability, offering greater flexibility at the cost of expertise.

Risk assessment: cloud‑hosted is not automatically safer

While managed clusters remove some operational risks, organizations must still understand Kubernetes’s intrinsic security model. Mis‑aligned IAM‑to‑Kubernetes role mappings, node‑role permissions, and insufficient pod security policies can introduce new attack vectors even in managed environments.

Case study: AWS EKS permission‑mapping vulnerability

An attack demonstrated by An Trinh and Duc Nguyen shows how a low‑privilege Pod can lead to full cluster takeover.

Phase 1 – Obtain a temporary token

From inside the Pod, the attacker calls the AWS STS API to request a Kubernetes token. STS identifies the request as originating from the EC2 node (the Pod’s underlying instance) and maps the node’s IAM role to the Kubernetes system:node group.

Phase 2 – Privilege escalation

With system:node rights, the attacker can read the ServiceAccount tokens of other Pods running on the same node.

Phase 3 – Lateral movement

Using the harvested tokens, the attacker can request higher‑privilege ServiceAccount tokens (e.g., a token that can read Secret objects) and eventually obtain cluster-admin privileges, achieving full control of the EKS cluster.

Mitigation checklist

Identify and restrict high‑risk Role / ClusterRole bindings (e.g., avoid granting create pod or read secret to low‑privilege ServiceAccounts).

Enforce pod security standards: disable automatic ServiceAccount token mounting when not needed, use automountServiceAccountToken: false, and apply PodSecurityPolicy or the newer PodSecurity standards.

Apply strict NetworkPolicy rules to limit pod‑to‑pod communication.

Audit IAM‑to‑Kubernetes role mappings in managed clusters to ensure node roles do not grant excessive Kubernetes permissions.

Regularly scan for known container‑runtime and Kubernetes component vulnerabilities and patch promptly.

Illustrations