Hands-on Lab·Certified Kubernetes Security Specialist
Falco Runtime Detection and Resource Limits
A syscall-level detector is the only thing that sees what happens INSIDE a container. This guide installs one, proves the kernel side works, and then reports honestly what it did on hardware this size.
Monitoring and Runtime Guide 35 of 40 Advanced
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 16 min
Falco 0.41.3 with the modern eBPF engine on a 7.0 kernel with BTF. No alert output appears on this page, because none was produced.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA7001 | 192.168.0.51 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA7001-NODE01 | 192.168.0.52 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when something has to see inside a container at runtime. This matters because a syscall detector is the only thing that can - and on a small node it asks for more than the node has, which is a decision rather than a failure.
- finding the three ways a syscall detector can reach the kernel, and the two numbers that decide
- reading what it asks for in return, from the DaemonSet's own spec
- seeing what actually happened on a node this size - its state, and the alert count
- writing the part you are really asked to write: a rule, checked with no kernel probe involved
- removing it again, and confirming the nodes are unharmed
Before you start
- guide 17 - the prevention side of the same syscalls.
-
What a syscall detector needs from the kernel
-
What it asks for in return
-
What actually happened on a node this size
-
The part you are actually asked to write
-
Putting it back, and what to do instead