Kubernetes runtime threats exploit the orchestration layer that sits between your application workloads and the underlying Linux host.
The NSA and CISA Kubernetes Hardening Guide identifies that Kubernetes clusters are commonly targeted for data and compute power theft and that misconfigured pods, containers running with excessive privileges, and overly permissive Kubernetes role assignments are documented attack vectors that allow adversaries to escape container boundaries, compromise the underlying infrastructure, and gain access to other workloads and cluster resources (Source: defense.gov,
MITRE ATT&CK for Containers (Matrix) documents the techniques adversaries use against containerized environments including Kubernetes, with techniques mapped to tactics including Execution and Defense Evasion (T1610 Deploy Container), Persistence (T1525 Implant Internal Image), Privilege Escalation (T1611 Escape to Host), and Credential Access (T1552 Unsecured Credentials, for example tokens exposed through container or cloud instance metadata services) — establishing a structured threat taxonomy specific to the container and orchestration runtime layer (Source: attack.mitre.org,
https://attack.mitre.org/matrices/enterprise/containers/
These threats fall into structural categories: container escape that breaks Linux primitive isolation, API server abuse that exploits the central authority model, workload identity abuse that federates container compromise into cloud IAM blast radius, and supply-chain threats that execute malicious code at runtime through image and admission controls. Understanding each category shapes detection priorities and hardening decisions.
The Kubernetes Runtime Threat Model
Kubernetes runtime threats differ structurally from VM-based runtime threats because of how the platform implements isolation and authority. Container isolation depends on Linux namespaces, cgroups, capabilities, and seccomp rather than hypervisor boundaries. Multiple workloads share kernel space on each node.
The CNCF Kubernetes Security Audit Working Group has documented that the kube-apiserver is the central authorization choke point for the Kubernetes control plane, and that compromise of API server credentials, service account tokens, or improperly scoped RBAC bindings provides adversaries with the same authority as the impersonated identity — establishing that Kubernetes runtime security depends on rigorous authentication and authorization at the API server boundary (Source: github.com/kubernetes,
https://github.com/kubernetes/community/tree/master/wg-security-audit
Workload identity federates into cloud IAM through mechanisms like AWS IRSA, GCP Workload Identity Federation, and Azure Workload Identity. Image execution is dynamic and ephemeral — pods can be created with images pulled from any registry the node can reach.
Each property creates attack surface. Shared kernel space means kernel vulnerabilities affect all workloads on a node. Central API server authority means credential compromise scales to cluster-wide access. Identity federation means container compromise can pivot to cloud resource access. Dynamic image execution means runtime is when supply-chain threats activate.
What changes the risk profile: understanding which threats your cluster architecture enables, and implementing controls that constrain the blast radius when compromise occurs.
Container Escape Techniques
Container escape breaks the Linux primitive boundaries that Kubernetes relies on for workload isolation. Privileged containers with CAP_SYS_ADMIN capability can manipulate kernel features that affect the host. hostPath mounts to sensitive host directories — the host root filesystem, /proc, /sys, or /var/lib/kubelet — give containers direct access to host resources.
CVE-2022-0492 in the Linux kernel cgroup v1 release_agent feature could allow a process to execute commands on the host — but in practice it required the container to already hold CAP_SYS_ADMIN or otherwise be able to mount the cgroup v1 filesystem, conditions a hardened pod (non-root, dropped capabilities, seccomp RuntimeDefault) does not meet.
It demonstrated a concrete container-escape vector rooted in a Linux primitive that Kubernetes pod isolation builds on, rather than a one-click escape from an arbitrary container. Subsequent hardening (seccomp profiles, dropping CAP_SYS_ADMIN) and the Kubernetes Pod Security Standards restricted profile address this and similar escape vectors at the orchestration layer (Source: nvd.nist.gov,
https://nvd.nist.gov/vuln/detail/CVE-2022-0492
Container runtime compromise creates another escape path. If an attacker can abuse the CRI socket (containerd or CRI-O), they can manipulate container lifecycle outside Kubernetes control. Misconfigured pod security contexts that allow capability inheritance or disable security features like AppArmor or SELinux expand the escape surface.
What constrains container escape: Pod Security Standards restricted profile enforcement blocks the most dangerous configurations. The restricted profile drops all capabilities by default, prohibits privileged containers, disallows hostPath mounts, and requires seccomp RuntimeDefault or custom profiles.
Detection logic pattern / pseudocode — validate for your platform:
High-privilege pod creation
pod_created AND (
spec.hostNetwork = true OR
spec.hostPID = true OR
spec.hostIPC = true OR
spec.containers[].securityContext.privileged = true OR
spec.containers[].securityContext.capabilities.add contains "SYS_ADMIN"
)
API Server and etcd Abuse
The kube-apiserver serves as the central authority for all cluster operations. All kubectl commands, controller actions, and admission webhook calls transit through this choke point. Authentication and authorization decisions happen at the API server, making it both the primary security boundary and the highest-value target.
ServiceAccount token abuse represents the most common API server attack pattern. ServiceAccounts are cluster identities that applications use to call the Kubernetes API. Each pod can mount a ServiceAccount token, and RBAC bindings determine what that identity can do. Overscoped RBAC creates blast radius when a pod is compromised.
Common abuse patterns include wildcard verbs in ClusterRoleBindings (verbs: ["*"]), cluster-admin access granted to ServiceAccounts that don't require it, and ServiceAccount tokens mounted in pods that do not call the API. Token volumes are mounted read-only at /var/run/secrets/kubernetes.io/serviceaccount/token by default unless automounting is disabled.
etcd stores all cluster state and can be accessed directly if an attacker reaches a control-plane node — where etcd runs — and etcd is not configured with mutual TLS client authentication; worker-node access alone does not expose it. Direct etcd access reads and writes all cluster state, bypassing API server authentication and authorization completely.
What changes API server abuse risk: RBAC least-privilege with explicit verb and resource scoping, ServiceAccount automounting disabled by default (automountServiceAccountToken: false), and audit logging configured to capture privilege escalation attempts.
Detection logic pattern / pseudocode — validate for your platform:
Suspicious API server activity
kubernetes_audit AND (
(verb = "create" AND objectRef.resource = "clusterrolebindings") OR
(verb = "patch" AND objectRef.resource = "rolebindings") OR
(verb = "create" AND objectRef.resource = "pods" AND objectRef.subresource = "exec")
) AND user.username NOT IN (known_admin_and_controller_identities)
Notes: kube-audit represents `kubectl exec` as resource="pods" with
subresource="exec" (not resource="pods/exec"), so match the subresource field.
There is no built-in "system:admin" user in Kubernetes — tune the exclusion to
your cluster's real admin/controller principals (e.g. system:kube-controller-manager,
system:kube-scheduler, your CI/CD service account) or omit it.
Workload Identity Abuse and Lateral Movement
Kubernetes workload identity federates into cloud IAM, creating a path for container compromise to escalate into cloud resource access. AWS IRSA (IAM Roles for Service Accounts), GCP Workload Identity Federation, and Azure Workload Identity allow pods to assume cloud IAM roles without storing long-term credentials in the cluster.
When a pod with workload identity is compromised, the attacker inherits the cloud IAM permissions associated with that pod's ServiceAccount. This federation happens through OIDC token exchange — the kubelet provides an OIDC token that the cloud IAM service accepts in exchange for temporary credentials.
Node IAM roles create additional lateral movement risk. If container escape is achieved, the attacker can assume the IAM role assigned to the underlying EC2 instance, EKS node group, or GKE node pool. Service mesh identity (mTLS certificates) can be abused for lateral movement between services if certificate management is compromised.
Cross-namespace lateral movement occurs through shared ServiceAccounts, network policy gaps that allow pod-to-pod communication across namespace boundaries, or shared persistent volumes. Default network policies in many clusters allow all pod-to-pod communication within the cluster.
What constrains lateral movement: workload identity least-privilege (cloud IAM roles scoped to only required resources), network policies that deny cross-namespace communication by default, and ServiceAccount isolation (unique ServiceAccount per application, no sharing across namespaces).
Supply Chain and Image Threats at Runtime
Supply-chain threats execute at runtime when malicious code embedded in container images runs in your cluster. Container images can contain compromised base images with backdoors or cryptominers, malicious dependencies, or legitimate software that has been tampered with during the build process.
Image signing and admission control represent the enforcement boundary, but bypass techniques can defeat weak policies. Admission controllers configured to allow images from unauthenticated registries, deprecated policy webhook configurations, or missing image signature verification create gaps.
Init containers execute before application containers and can be used to establish persistence or modify the runtime environment. Sidecar containers running alongside application containers can be injected through admission controller compromise or misconfiguration.
The runtime attack surface depends on image composition. Distroless images contain only the application runtime and dependencies, reducing the available attack tools. Minimal images based on Alpine Linux provide a shell but limited system utilities. Full images based on Ubuntu or CentOS provide complete operating system toolchains that attackers can leverage.
What changes supply-chain risk at runtime: admission controllers configured to require image signatures from trusted registries, distroless or minimal base images that reduce post-compromise capabilities, and image provenance logging that tracks what images execute in your cluster.
Detection logic pattern / pseudocode — validate for your platform:
Image pulled from untrusted registry
pod_created AND
spec.containers[].image NOT MATCHES "^(gcr.io/my-project|my-registry.com)/" AND
spec.containers[].image NOT MATCHES "^registry.k8s.io/"
Runtime Security Observability: What to Monitor
Kubernetes runtime visibility requires signal collection from multiple layers: cluster audit events, container runtime process execution, and cloud IAM activity downstream of workload identity federation.
kube-audit logging captures all API server requests. Critical event classes include privilege escalation (RBAC modifications, ClusterRoleBinding creation), exec into pods, and secret access. Configure audit policy to capture these events without overwhelming log volume.
Container runtime signals show what processes execute inside pods, what network connections they establish, and what files they modify. Tools like Falco, eBPF-based sensors, or runtime security agents provide this visibility. Critical signals include unexpected process execution, network connections to external IPs not in allow-lists, and file modifications in read-only mounted paths.
Cloud audit logs (AWS CloudTrail, GCP Cloud Audit Logs, Azure Activity Logs) capture IAM identity abuse downstream of pod compromise. When workload identity is used, pod compromise that leads to cloud resource access appears in cloud audit trails, not just cluster audit logs.
Image provenance and admission decisions should be logged for forensic capability. Knowing what images were allowed or blocked by admission controllers and what registries they came from helps trace supply-chain compromise.
What improves detection capability: structured audit logging with fields that support querying (user identity, resource type, verb), runtime process monitoring with baseline process lists per application, and correlated alerting that links cluster events to cloud IAM activity.
Hardening Priorities That Actually Change Outcomes
Pod Security Standards restricted profile enforcement materially reduces container escape risk. The restricted profile drops all capabilities by default, prohibits privileged containers, disallows hostPath mounts, requires non-root user execution, and mandates seccomp RuntimeDefault profiles. Implement through admission controllers that reject pods violating the profile.
RBAC least-privilege eliminates wildcard permissions that enable cluster-wide compromise. Avoid ClusterRoleBindings with verbs: ["
"] or resources: [""]. Scope RoleBindings to specific namespaces and required verbs only. ServiceAccounts should have explicit resource and verb requirements documented.
ServiceAccount automounting disabled by default prevents unnecessary API token exposure. Set automountServiceAccountToken: false in pod specs and ServiceAccount definitions unless the workload requires API access. This eliminates token files from pods that do not call the Kubernetes API.
Workload identity federation least-privilege constrains blast radius when pods are compromised. Cloud IAM roles associated with ServiceAccounts should have minimal required permissions, time-limited sessions where supported, and resource-specific scoping (bucket-level, not account-level permissions).
Read-only root filesystem where possible prevents runtime file system modification. Set readOnlyRootFilesystem: true in container security contexts. Applications requiring writable paths can use emptyDir volumes for temporary storage.
What prioritizes these controls: container escape and API server abuse represent the highest blast radius threats in most cluster configurations. Pod Security Standards restricted profile and RBAC least-privilege address these primary attack vectors. The other controls reduce lateral movement and persistence capabilities post-compromise.
Sources