Cluster context on the event, not joined on afterwards
A syscall does not know it happened inside a pod. Falak resolves cgroup and namespace ids against the CRI and the API server on the node, and attaches cluster, namespace, pod, workload kind, service account and image digest to the event itself. When you query six weeks later, the context is still there — even though the pod is long gone.
- Cluster, namespace, pod and workload on every event
- Container escape detection from mount + exec correlation
- Privileged and hostPath workload inventory
- Service-account token access detection
- Pod-to-pod and pod-to-node lateral movement
- One DaemonSet, no sidecars, no admission webhook required
Capabilities
What it does
Container lifecycle as a first-class class
OCSF has no container lifecycle class, so rather than bending Process Activity out of shape Falak registers one documented extension — class_uid 990001 — carrying mounts, port mappings and the full security context including privileged, hostPID and capability sets.
Escape detection that correlates two facts
A privileged container with a hostPath mount is a posture finding. A privileged container with a hostPath mount that then execs a binary whose resolved inode lives on the host device is an escape in progress. Falak correlates the mount set with the subsequent exec's device and mount point.
Workload identity on network events
Source and destination endpoints carry their own K8s context, so a connection between two pods is legible as payments/ledger-writer → identity/token-issuer rather than as two ephemeral pod IPs you have to resolve from a stale record.
Namespace-aware noise control
Sampling and exclusions are expressed per namespace and per label selector, so a chatty observability namespace can be quieted without creating a blind spot in the namespace that handles card data.
Image provenance in the finding
The image digest and its cosign attestation status ride along on the event. When a finding fires on a workload whose image is not attested, the analyst sees that on the same screen rather than in a supply-chain tool.
Node-level deployment, pod-level attribution
One DaemonSet per cluster. No per-pod sidecar, no injected library, no restart of your workloads. The sensor sees every container on the node including ones that started before it did.
Detections
Representative detection content
| Detection | Technique | Primary signal |
|---|---|---|
| Container escape via privileged mount | T1611 | 990001 mount → nsenter exec |
| Docker socket mounted into a workload | T1610 | mounts.is_sensitive |
| Service-account token read by a shell | T1552.007 | 1001 on /serviceaccount/token |
| Lateral SSH from a workload pod | T1021.004 | crossed_pod_boundary + port 22 |
| Interactive shell in a production container | T1609 | 1007 with a TTY allocated |
| Node port scan from a pod | T1046 | 40+ distinct ports in 60s |
| Image outside the registry allowlist | T1610 | 990001 container start |
| Package manager run at container runtime | T1105 | apt/apk/yum exec |
Telemetry collected
- Container lifecycle
- falak 990001
- Cluster / namespace / pod
- device.k8s.*
- Workload kind and name
- workload_kind
- Service account
- service_account
- Image and digest
- container.image
- Security context
- privileged, hostPID…
- Mount set
- is_host_path
- Namespace ids
- pid_ns, mnt_ns, net_ns
install on a cluster
helm upgrade --install falak-neo-minion \ oci://registry.falakneo.example/charts/minion \ --namespace falak-system --create-namespace \ --set core.endpoint=ingest.eu.falakneo.example:443 \ --set enrollment.token=$FALAK_ENROLLMENT_TOKEN # The DaemonSet needs CAP_BPF and CAP_PERFMON, # hostPID for cgroup resolution, and a read-only # mount of the CRI socket. Nothing else.
See your clusters the way the kernel does
Point a sensor at a staging cluster and compare what it reports against what your current tooling shows. The difference is usually the interesting part.