Kubernetes Container Escape to Cloud Pivot: Detect at Runtime

Google Cloud's Threat Horizons H1 2026 report, the thirteenth in the series, delivers a figure that reframes the question of reaction time: a new Kubernetes cluster receives its first attack attempt within eighteen minutes of deployment. The report, published on March 11, 2026, and covering the second half of 2025, also documents a fundamental shift: exploited software vulnerabilities now account for 44.5 percent of cloud intrusions, surpassing credential theft for the first time as the initial access vector.

Beyond speed, it is the attack pattern that should hold the attention of teams running containers. Google describes an intrusion where the attacker, after abusing the control plane and hijacking a high-privilege application controller account, leveraged a pod's privileged configuration to break out of the container environment. Forensic analysis suggests this escape was achieved by abusing cluster admin privileges to probe node-level services, rather than executing a kernel exploit. From there, the actor conducted reconnaissance before pivoting to a workload managing customer information, where they found and extracted database credentials stored in cleartext in the pod's environment variables.

The pattern to detect: from escape to cloud pivot

The chain has several stages, each matching an observable technique. Deploying or hijacking a privileged container falls under T1610 (Deploy Container). Escape from the container to the host is T1611 (Escape to Host). Once on the host or in a privileged pod, the attacker queries the cloud instance metadata service, T1552.005, and steals application access tokens, T1528, which open the rest of the cloud environment.

The entry vectors are known and recurring: an exposed Docker or Kubernetes API without authentication, a docker.sock socket mounted in a container, excessive Linux capabilities granted to the pod, or a poisoned image pulled from a public registry. The common thread is that none of these vectors is detectable at install or image-scan time alone: they show up at runtime, through abnormal container behavior.

Runtime detection with Falco

Falco and Tetragon observe system calls and kernel events in real time, which makes them the right tool to catch an escape in progress. Three behaviors warrant a rule: access to docker.sock from a container, launching a process inside a privileged container, and writing to or reading from host paths mounted via hostPath.

Here is a Falco rule targeting Docker socket access from a container, a strong signal of an attempt to control the host:

- rule: Docker socket access from a container
  desc: >
    A process in a container opens the Docker socket, which allows creating
    privileged containers and escaping to the host.
  condition: >
    evt.type in (open, openat) and
    container.id != host and
    fd.name endswith "docker.sock" and
    not proc.name in (dockerd, containerd)
  output: >
    Docker socket access from a container
    (command=%proc.cmdline container=%container.name image=%container.image.repository)
  priority: CRITICAL
  tags: [container, escape, T1611]

A second useful rule watches for launching a shell or a reconnaissance tool inside a container marked privileged, often the immediate prelude to escape. On cloud hosts, finally add a rule on outbound connections to the instance metadata service address from an application container, which normally has no reason to query that address.

The admission guardrail with OPA

Runtime detection catches what happens. Admission policy prevents it from being possible. OPA, via Gatekeeper, lets you deny at admission any pod requesting a risky configuration: privileged mode, docker.sock mount, dangerous capabilities, or hostPath to sensitive directories. Here is the spirit of a Rego policy rejecting privileged pods:

package kubernetes.admission
 
deny[msg] {
    input.request.kind.kind == "Pod"
    c := input.request.object.spec.containers[_]
    c.securityContext.privileged == true
    msg := sprintf("Privileged container not allowed: %v", [c.name])
}
 
deny[msg] {
    input.request.kind.kind == "Pod"
    v := input.request.object.spec.volumes[_]
    endswith(v.hostPath.path, "docker.sock")
    msg := "Mounting docker.sock is not allowed"
}

This combination, admission prevention plus runtime detection, is the recommended posture. The OPA policy shrinks the surface upstream by refusing the configurations that make escape possible. Falco covers the rest, flagging abnormal behavior on what did get deployed.

What the eighteen-minute window imposes

Google's figure has a direct consequence: a detection that raises an alert several hours after the event arrives too late. Runtime monitoring must be active from the first deployment, not bolted on afterward. Likewise, database credentials in a pod's environment variables, the direct cause of the pivot Google describes, must be replaced by managed, short-lived secrets. A compromised container should never find a durable cloud key within reach.

Securing a Kubernetes environment against escape and pivot requires this dual layer, admission and runtime, fed by up-to-date rules. That is what the ThreatClaw cloud-native feed provides: ready-to-deploy Falco rules and OPA policies, built on the escape and pivot techniques actually observed, to keep pace with attackers who strike in minutes.