Kubernetes misconfigs let attackers jump to cloud accounts
Attackers are exploiting common Kubernetes misconfigurations—over‑privileged service accounts, weak namespace isolation and exposed control planes—to pivot from compromised containers into cloud accounts. Reports stress audit logs and early API‑abuse detection as vital for spotting token misuse, and tooling is starting to add runtime context to make alerts actionable: GitHub now surfaces Dynatrace runtime data to prioritise security findings against deployed artefacts. Put simply, static alerts alone aren’t enough; you need runtime exposure to triage what actually matters. (cybersecuritynews.com)(gbhackers.com)(github.blog)
# Kubernetes misconfigs let attackers jump to cloud accounts A Kubernetes breach used to sound like a container problem. Increasingly, it is an identity problem. The pattern showing up in incident reports is simple and ugly: an attacker gets code execution inside one container, steals the credentials that workload is already using, and then walks outward into the Kubernetes cluster and the cloud account behind it. Recent reporting says activity tied to Kubernetes service account token theft rose 282% over the last year, with the information technology sector making up more than 78% of observed activity. (cybersecuritynews.com) That shift matters because Kubernetes was designed to let software talk to other parts of the platform automatically. A process running inside a pod can use a service account identity to authenticate to the Kubernetes application programming interface server, which is the control point for the cluster. Kubernetes documents describe service accounts as identities for processes in pods, and note that in-cluster software commonly uses them to access the application programming interface. (kubernetes.io 1) (kubernetes.io 2) In a healthy setup, that identity is tightly scoped. The pod gets only the permissions it needs, only in the namespace it needs, and only for the shortest time it needs them. In a weak setup, the same mechanism becomes a master key: a stolen token can let an attacker list secrets, modify workloads, or request fresh credentials that last far longer than defenders expect. (kubernetes.io) (securitylabs.datadoghq.com) The first misconfiguration in this story is over-privileged service accounts. These are workload identities that have been granted broad Kubernetes Role Based Access Control rights, sometimes across the whole cluster rather than one namespace. If an attacker lands in a pod that uses one of those accounts, they do not need a sophisticated container escape; they can simply use the pod’s own permissions to ask the cluster what else is available. (cybersecuritynews.com) (kubernetes.io) The second misconfiguration is weak namespace isolation. Namespaces are useful for organizing teams and workloads, but they are not a complete security boundary by themselves. Kubernetes guidance on multi-tenancy stresses that real isolation usually requires a combination of namespaces, access controls, and network restrictions; without those layers, a compromise in one workload can become reconnaissance against many others. (kubernetes.io) (docs.aws.amazon.com) The third misconfiguration is the exposed control plane. In Kubernetes, almost all meaningful cluster actions flow through the application programming interface server. Kubernetes documentation describes a hub-and-spoke model in which node and pod application programming interface usage terminates at that server, and cloud provider documentation notes that some managed clusters expose that endpoint publicly by default unless customers restrict access. (kubernetes.io) (docs.aws.amazon.com) (learn.microsoft.com) Once an attacker has a token and a reachable application programming interface, the move from “container incident” to “cloud incident” can be surprisingly short. Reporting on recent cases describes a sequence in which attackers gain execution in a container, extract mounted credentials, test permissions against the Kubernetes application programming interface, and then pivot toward higher-value cloud resources. In one example cited in April 2026 reporting, the stolen token belonged to a high-privilege management service account, which allowed access across namespaces and into broader infrastructure operations. (cybersecuritynews.com) This is why defenders keep coming back to audit logs. Kubernetes auditing records who did what, when, from where, and against which resource, with events generated inside the kube-apiserver itself. If audit logging is not enabled, Kubernetes says no events are logged at all, which means one of the best sources of evidence for token misuse simply does not exist. (kubernetes.io) Audit trails matter most when they are paired with behavior detection. A useful signal is not just “a token exists,” but “a pod accessed a service account token and then immediately made direct Kubernetes application programming interface requests.” Elastic has published a prebuilt detection rule that correlates exactly that pattern, because it can indicate credential harvesting followed by lateral movement inside the cluster. (elastic.co) Another reason early detection is hard is that Kubernetes tokens can persist longer than many teams assume. Datadog Security Labs has documented abuse of the TokenRequest application programming interface, noting that Kubernetes 1.24 made token creation easier and that, by default, users can create tokens with very long durations unless the platform provider imposes a limit. Datadog also notes that these tokens cannot be directly revoked once issued; revocation depends on deleting the bound object, which is not always practical. (securitylabs.datadoghq.com) That creates a familiar security problem: static findings tell you what could go wrong, but not which issue is live in production right now. A code scanner may flag ten vulnerable images and twenty risky permissions, yet only two of those images may actually be deployed and internet-exposed. Without runtime context, the queue fills with theoretical risk while the exploitable path stays buried. That is the backdrop for GitHub’s April 7, 2026 release adding runtime context from Dynatrace to GitHub Advanced Security. GitHub says customers can now see deployment context for container images mapped to repositories, plus runtime risk signals from Kubernetes environments, and use that data to prioritize code scanning and Dependabot alerts. GitHub’s examples include filtering for findings that affect deployed artifacts and are internet-exposed, as well as artifacts with access to sensitive data. (github.blog) The idea is straightforward: if a vulnerable package sits in a repository nobody deploys, it should not compete for attention with a vulnerable image that is already running in production and reachable from the public internet. Runtime context does not replace static analysis, but it changes the order of work. It tells security teams which alert is attached to a real artifact, in a real cluster, under real exposure conditions. (github.blog 1) (github.blog 2) The deeper lesson in this story is that Kubernetes security failures are often permission failures wearing infrastructure clothes. Attackers do not always need to break isolation at the kernel level if the platform has already handed a compromised workload broad identity, weak segmentation, and a visible control plane. The fastest wins are still the least glamorous ones: cut service account privileges, harden namespace boundaries, restrict application programming interface exposure, turn on auditing, and watch for abnormal token use before it becomes a cloud-account incident. (kubernetes.io 1) (kubernetes.io 2)
