Runtime security tooling alerts that a specific pod is exhibiting behavior consistent with compromise — walk through your immediate containment response.

Isolate the pod at the network level first (so it can't communicate further with whatever it's trying to reach, or spread laterally) without immediately killing it, since a live, isolated pod preserves forensic evidence (process state, memory, open connections) that a killed pod loses — then capture that evidence, and only terminate/replace the pod once the necessary forensic data has been captured, coordinating with whatever the organization's actual incident response process requires.

Network isolation, not immediate deletion, is the first containment action: applying a NetworkPolicy that denies all ingress and egress for the specific compromised pod (matched by label or name) immediately stops it from communicating further with an external attacker-controlled destination or attempting lateral movement to other pods — critically, this can be done without terminating the pod, which matters for the next step.

Preserve evidence before destroying it — a killed pod loses forensic value: once a pod is deleted, its in-memory process state, any evidence of what the attacker actually did, and potentially useful artifacts are gone — capturing kubectl exec-based process inspection, memory dumps if tooling supports it, and relevant logs before termination preserves what an actual investigation needs, versus immediately killing the pod (which stops the bleeding but destroys most of the evidence).

Check whether the underlying node itself might be compromised, not just the pod: depending on the nature of the exploit, an attacker might have achieved container escape or otherwise compromised the underlying node — if there's genuine reason to suspect this (not just routine caution), the node itself may need isolation/cordoning and separate forensic attention, not just the one pod.

Rotate any credentials the compromised pod had access to: any Secret, ServiceAccount token, or other credential the compromised pod could read needs to be treated as potentially exposed — rotating these (and reviewing what access they actually granted, to understand the realistic blast radius) is a necessary parallel action, not something to defer until after the pod-level containment is fully resolved.

Only terminate and replace the pod once evidence capture is complete: after network isolation and evidence preservation, deleting the pod (letting its controller create a clean replacement) removes the active threat from the cluster — this ordering (isolate → preserve evidence → terminate → replace) balances stopping the immediate threat against not destroying the ability to actually understand what happened.

Follow the organization's actual incident response process for anything beyond immediate technical containment: notification requirements, escalation paths, and post-incident review are typically governed by an existing IR process — the technical containment steps above feed into that broader process rather than substituting for it, especially for anything with potential compliance or customer-notification implications.

• Isolate the pod at the network level first (via NetworkPolicy), without immediately deleting it — this stops further attacker activity while preserving forensic evidence a killed pod would lose.
• Capture process state, logs, and any available forensic data before terminating the pod, since deletion destroys most of what an investigation would need.
• Check whether the underlying node itself might be compromised (container escape), not just assume the incident is contained to the one pod.
• Rotate any credentials the compromised pod had access to, and only terminate/replace the pod once evidence capture is genuinely complete.

• Falco: Documentation
• Kubernetes: Network Policies