Analyze Container Escape Primitives and Cluster-Wide Exposure
Determine the exact escape technique used (privileged container, host mount, kernel vulnerability, container-runtime CVE) and hunt cluster-wide for other workloads with the same exposure.
Actions
- 1
Identify the escape primitive from preserved pod spec and runtime evidence: privileged flag, dangerous capabilities, host mounts, host namespaces, kernel CVE exploitation.
- 2
Query the cluster for other pods with the same primitive; these are immediate candidates for the same compromise.
- 3
Review admission-controller policy to understand why the primitive was allowed; gaps in policy are part of the finding.
- 4
Correlate escape with image provenance: was the image from an untracked registry? Signed? SBOM-backed?
- 5
For kernel-CVE-based escapes, check node kernel versions cluster-wide; unpatched nodes are in-scope for follow-up remediation.
Queries
kubectl get pods -A -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged == true or (.spec.volumes[]?.hostPath?)) | {ns:.metadata.namespace,name:.metadata.name}'kubectl get nodes -o wide | awk '{print $1,$8,$9}'Notes
Escape primitives found in one namespace are almost always present in others; hunt broadly.
Admission-policy gaps are usually the primary finding; closing them requires coordination with platform engineering.
Kernel CVE exploitation is rarer than configuration-based escape but much harder to detect post-hoc; preserve node memory if suspected.