Kubernetes Runtime Security: Threats and Defenses

Kubernetes is not simply a larger container runtime. The orchestration layer introduces a central authority in the API server, workload identities that can federate into cloud IAM, and a continuously changing set of images and pods that may execute across many nodes. Those properties do not exist in a standalone container, and they change both the blast radius of a compromise and the evidence defenders need to investigate it.

Container escape mechanics still matter, but they are only part of the Kubernetes threat model. A compromised pod can abuse its ServiceAccount token, reach the API server, move across namespaces, inherit node or cloud permissions, or pull an untrusted image into a new workload. Recent runtime vulnerabilities also show that race conditions in mount and file descriptor handling are a repeatable escape class, not a theoretical edge case.

This article explains how Kubernetes threats differ structurally, what recent escape and race-condition vulnerabilities teach us, how API server and workload identity abuse work, and which controls reduce the most risk. It also shows where cluster and cloud telemetry stop, and why application runtime context is needed to explain which code inside a workload caused a suspicious action.

Key Takeaways

• Kubernetes threats differ from single-container threats because many workloads share a node kernel, the API server acts as a central authority, and workload identity can extend a pod's permissions into cloud IAM.
• The MITRE ATT&CK matrix for containers organizes the threat surface into techniques such as escape to host, deploy container, implant internal image, and unsecured credentials.
• The 2025 runC vulnerabilities CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881, along with 2024 BuildKit flaws, show that timing windows around mounts, symlinks, and file descriptors can produce real isolation failures.
• ServiceAccount token abuse is one of the most practical API server attack patterns. Broad RBAC and default token automounting can turn one compromised pod into cluster-wide access.
• The highest-impact baseline controls are the restricted Pod Security Standards profile and RBAC least privilege, supported by correlated cluster, runtime, cloud, and application signals.

Why Kubernetes Security Vulnerabilities Need Their Own Threat Model

A Structural Difference From Single-Container Risk

Multiple workloads share the kernel on each node, so a kernel or runtime flaw can affect every pod scheduled there. The API server is a single decision point for authentication and authorization, which means a stolen credential can scale from one workload to an entire cluster.

Cloud Kubernetes adds another boundary. AWS IAM Roles for Service Accounts, GCP Workload Identity Federation, and Azure Workload Identity let a pod exchange an OIDC token for cloud permissions. That removes long-lived cloud keys from the cluster, but it also means a compromised pod can inherit whatever cloud authority was attached to its ServiceAccount.

Image execution is dynamic as well. Controllers create and replace pods continuously, and those pods may pull images from any reachable registry unless policy constrains them. A Kubernetes runtime defense therefore has to understand workloads, identities, admission decisions, node placement, and image provenance, not only process activity inside one container.

A Structured Threat Taxonomy

The MITRE ATT&CK matrix for containers gives teams a shared way to describe this surface. Its techniques include Deploy Container under Execution and Defense Evasion, Implant Internal Image under Persistence, Escape to Host under Privilege Escalation, and Unsecured Credentials under Credential Access.

Those techniques map to four useful categories for Kubernetes runtime security: container escape, API server abuse, workload identity abuse, and supply-chain or image abuse. The categories overlap during a real incident, but they help defenders identify which boundary failed and where to collect evidence.

Kubernetes Runtime Threat Paths and Defenses

Escape and Race Conditions at the Runtime Layer

Race Conditions Are a Proven Escape Class, Not a Theory

The runC project disclosed three related vulnerabilities in 2025: CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881. They involved timing windows and path-redirection problems during container setup, including masked paths, mount targets, symlink swaps, and writes through procfs. In the wrong conditions, an attacker could redirect a privileged runtime operation before isolation protections took effect.

BuildKit provided an independent example in 2024. CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653 covered race conditions and unsafe handling around cache mounts and build inputs. The BuildKit advisory for CVE-2024-23651 describes how parallel malicious build steps sharing a cache mount could expose host files to a build container.

These flaws sit beneath application code. Secure input validation or application framework hardening cannot prevent a vulnerable runtime from mishandling a mount or file descriptor. The relevant defenses are patched runtimes, a hardened pod security context, restricted build inputs, and detection of behavior that attempts to cross the container boundary.

What Actually Constrains Escape in Practice

The Kubernetes Pod Security Standards restricted profile has the greatest practical impact because it removes common escape prerequisites. It prohibits privileged containers and hostPath volumes, requires workloads to run without privilege escalation, restricts Linux capabilities, and requires an approved seccomp profile such as RuntimeDefault or Localhost.

That does not make every runtime vulnerability harmless. It does mean many techniques lose the capabilities, mounts, or host access they need to succeed. Older escape paths such as CVE-2022-0492 also depended on conditions that a properly restricted pod should not receive.

The operational goal is to make a compromised pod less powerful. A hardened security context reduces the attacker's options before an incident, while runtime monitoring reveals whether the workload still attempts a mount, write, process, or network action outside its normal behavior.

API Server and Service Account Abuse

The API Server Is the Central Authority Attackers Target

Every kubectl command, controller action, and admission request passes through kube-apiserver. Authentication establishes the caller's identity, admission decides whether a request may proceed, and authorization determines what that identity can do.

That makes the API server both the primary control plane boundary and the highest-value target. An attacker does not always need to exploit the server itself. Stealing a legitimate credential with broad permissions can be enough.

ServiceAccount Token Abuse

Pods can receive a ServiceAccount token automatically, and RBAC bindings define the authority behind it. Common failure patterns include wildcard verbs or resources in ClusterRoles, cluster-admin granted to application ServiceAccounts, and tokens mounted into workloads that never call the Kubernetes API.

The direct fix is explicit. Set automountServiceAccountToken: false on workloads that do not need API access, use short-lived projected tokens where access is required, and remove wildcard permissions from RBAC. A compromised pod can then do no more than the workload genuinely needs.

Audit logs should also distinguish expected controller behavior from interactive or unusual API activity. Token use from an unfamiliar source, namespace enumeration by an application identity, or a new RoleBinding created by a workload are stronger signals when paired with the exact ServiceAccount and pod involved.

etcd Exposure, With the Actual Precondition

etcd stores cluster state, including Kubernetes Secrets. Direct access can bypass API server authorization, but worker-node access alone does not normally expose etcd.

The attacker must be able to reach a control-plane node where etcd is listening, and mutual TLS client authentication must be absent, misconfigured, or compromised. Defenders should state that precondition clearly so a generic warning about etcd does not distract from the more common paths through stolen API credentials and overscoped RBAC.

Workload Identity Federation and Lateral Movement

When a Compromised Pod Becomes a Compromised Cloud Identity

Workload identity federation allows pods to assume cloud roles without storing long-term credentials. The pod presents a Kubernetes-issued OIDC token, and the cloud provider exchanges it for temporary credentials tied to an AWS, Google Cloud, or Azure identity.

This design is safer than static keys, but permission scope still matters. If a compromised pod can assume a role that reads production secrets, writes to object storage, or manages infrastructure, a single application incident becomes a cloud account problem. This is part of why attackers target cloud applications: the application is often the shortest path to identities and data that live beyond the cluster.

Cross-Namespace and Node-Level Lateral Movement

Three paths repeatedly widen the blast radius. A container escape can expose the node's own IAM role. A ServiceAccount reused across namespaces can carry the same permissions into unrelated workloads. A cluster without default-deny NetworkPolicies may let one pod connect freely to services throughout the environment.

Least privilege has to span all three layers. Restrict the pod, scope the Kubernetes identity, scope the cloud role behind that identity, and limit east-west network paths. A strong control in only one layer cannot compensate for broad authority in the others.

What Actually Reduces Risk and Enables Kubernetes Attack Detection

Pod Security Standards and RBAC Least Privilege

Start with the restricted Pod Security Standards profile and RBAC least privilege. The restricted profile blocks many escape prerequisites, while narrow RBAC prevents a stolen ServiceAccount from turning local code execution into cluster administration.

These controls are more valuable than a long checklist of optional hardening settings because they directly remove high-impact capabilities. Enforce them through admission policy, test exceptions, and review the exceptions as production risk.

Workload Identity and Token Hygiene

Scope every cloud IAM role attached to a ServiceAccount to the minimum resources and actions its workload needs. Disable token automounting by default, then enable it only for workloads that genuinely call the Kubernetes API.

Also avoid sharing ServiceAccounts across unrelated applications or namespaces. A distinct identity makes both authorization and investigation more precise.

Runtime Visibility Across Cluster, Runtime, and Cloud Logs

No single log source can reconstruct the whole attack. Kubernetes audit logs show API server activity, container runtime signals show process and network behavior inside pods, and cloud audit logs show what happened after a federated identity reached a cloud service.

Detection should correlate those sources around workload identity. If a pod makes an unexpected cloud API call, responders should be able to move from the cloud principal to the ServiceAccount, namespace, pod, image, node, and process that used it.

Where the Runtime Layer Still Needs Application Context

Which Code Actually Used That Token

Cluster and cloud audit logs can show that a ServiceAccount token called a cloud API or that a workload's federated identity made an unexpected request. They do not show which code inside the application made the call, whether it was intended business logic, a compromised dependency, or attacker-controlled code running in the process.

That is the gap application detection and response and runtime application security address. Raven traces the behavior to the specific library, function, and call chain responsible, so the investigation starts with the application cause instead of working backward from a cloud audit record.

Raven does not replace kube-audit logs, admission controls, runtime isolation, or cloud IAM monitoring. It adds the layer those controls cannot provide on their own: which code used the identity and what execution path led to the action. That context helps teams decide whether the request was expected, vulnerable, or malicious without turning the entire article into a product claim.

Kubernetes runtime threats span a wider surface than a single container. Proven runtime race conditions, API server authority, and cloud identity federation can turn one compromised pod into a node, cluster, or cloud incident.

Pod Security Standards and RBAC least privilege close the highest-impact gaps. Visibility across cluster, runtime, and cloud logs catches attacks already in progress, while application runtime context explains which code actually caused the suspicious behavior.

See how Raven traces Kubernetes runtime incidents back to the exact application code responsible.