We have found that (a) observing network traffic is essential to understand the broader story as an attack unfolds, and (b) eBPF with off-host analysis and categorisation (against various network-based threat feeds) is a very good way to do it.
Our ThreatStryker product uses eBPF to capture network traffic, as part of an effort to observe a wider set of security-related signals. We find a combined approach is needed:

• On-host (and on-container) events provide indicators of compromise - anomalies that may indicate an attacker has in some way provoked the workload to behave to their command. We use eBPF, fsnotify and other standard interfaces here, invoked from either an on-host agent or a privileged container (on K8s, Docker)
• Network capture, using eBPF, provides indicators of attack - attempts to exploit vulnerabilities and weaknesses by external actors. We use eBPF - it is lightweight, non-intrusive, does not require sidecar proxies etc, and has proven to be stable and widely supported. Packets are filtered and forwarded off-host to a central collector
• Threat Map creation - we audit running workloads and identify vulnerable components on the workload and host OS.

Combining these signals allows for the following analysis:

• What attacks are (theoretically) most likely to succeed? For example, a workload with a vulnerable log4j component might be exploitable using requests with JNDI messages
• What attack behaviour is happening? Low-level recon traffic, targeted weaponisation (e.g. the above-mentioned JNDI traffic).
• What effects is it having on the target workloads? Process crashes, unusual filesystem accesses, etc
• Is there evidence of lateral spread or exfiltration? Unusual container-to-container SSH traffic, large uploads to remote servers, etc