Lesson 0020 · 35 minutes · Monitoring, Logging, and Runtime Security

Detect an interactive shell in a production container

Runtime detection turns suspicious behavior into an actionable alert. A shell inside a workload is not automatically malicious, but in a defined production scope it deserves timely investigation—especially when it touches mounted credentials.

Incident reflex: make detection rules precise enough to reduce noise, but include enough event context in the alert that responders can identify the workload without re-running the search.

Timed task: 25 minutes

Review lab/lesson-20-runtime-event.json. Create lab/lesson-20-falco-rule.yaml from scratch containing one custom Falco rule.

The rule must:

Write the condition so it does not match a host-level shell or a shell in another namespace. Do not suppress the alert because the process is running as root; identity is evidence for triage, not a reason to skip detection.

Evidence and response

In lab/lesson-20-answer.md, give:

  1. The exact suspicious command from the supplied event.
  2. The affected namespace, Pod, and container.
  3. Two immediate containment actions in priority order.

This environment does not run Falco, so validate the YAML structure in your editor. On a Falco-equipped Linux node, use falco --validate /path/to/rule.yaml before reloading the rules.

Retrieval check

Question

Which condition component prevents a rule from alerting on every shell launched directly on a Kubernetes node?

Documentation target

Use the official Falco rules reference to confirm condition syntax and available output fields.

What to send me

Paste the rule and your three incident answers. I’ll assess false-positive scope, alert context, and containment quality.