What KubeSentry detects

KubeSentry runs two layers of rules:

1. Falco's stable ruleset (25 rules, pulled as falco-rules:4) — the upstream detections, kept as-is.
2. The KubeSentry layer — 11 custom rules written for Kubernetes workloads, plus 3 tuning overrides that reshape Falco defaults rather than replacing them, so upstream improvements keep flowing.

Falco's incubating and sandbox rulesets are deliberately not loaded. They carry the bulk of upstream's false positives, and a security tool people learn to ignore is worse than no security tool.

How severity works

Rules declare a Falco priority. The dashboard collapses those into three buckets, and only the top bucket pages you:

Falco priority	Dashboard severity	Instant notification?
CRITICAL, EMERGENCY, ALERT	Critical	Yes — every configured channel
ERROR, WARNING	High	No — dashboard + daily digest
NOTICE, INFORMATIONAL, DEBUG	Warning	No — dashboard + daily digest

This is why a High-severity alert doesn't hit your inbox: paging on everything is how alerting dies. If you want to test notification delivery, use a Critical trigger from the table below.

KubeSentry rules

All 11 carry remediation guidance — what it means, how to triage, what to run.

Rule	Severity	What it catches
Crypto miner process	Critical	Known miner binaries by name or resolved path, stratum pool URLs, and monero/randomx algo flags
Sudoers or passwd modified in container	Critical	Writes to /etc/passwd, /etc/shadow, /etc/sudoers, /etc/sudoers.d/*
Curl or wget piped to shell	Critical	The curl … \| sh remote-install pattern
Binary executed from tmp	Critical	Execution out of /tmp or /dev/shm — the classic drop-and-run
New cron job in container	High	Writes under /etc/cron* — persistence
SSH binary executed in container	High	ssh, sshd, scp, sftp running inside a container
Outbound connection to suspicious port	High	TCP out of the cluster on 3333/4444/5555/14444 (mining pools, C2)
Package manager run in container	High	apt, apk, pip, npm, … at runtime — image drift
Kubectl execution from inside pod	High	kubectl inside a pod — API pivot. GitOps operators excluded
Process running with NET_ADMIN capability	High	A workload holding CAP_NET_ADMIN, which isn't granted by default
Container running as root with sensitive mount	High	Containers mounting the runtime socket, the kubelet root, or host /

Trying them out

These run against the throwaway victim pod from Verify your installation. The first is the one to use if you want a dependable test — it's the trigger the verification walkthrough is built on:

# Critical — writes to a sensitive auth file
kubectl exec victim -- bash -c "echo x >> /etc/passwd"

These three match their rule's conditions and should fire, though exactly what a given image does at exec time varies — treat them as starting points rather than guarantees:

# Critical — curl-pipe-shell pattern (fetches nothing; the pattern is the signal)
kubectl exec victim -- sh -c "curl http://127.0.0.1/install.sh | sh"

# High — cron persistence
kubectl exec victim -- bash -c "echo '* * * * * root id' >> /etc/crontab"

# High — package manager at runtime
kubectl exec victim -- apt-get --version

Crypto mining and /tmp execution need a binary that actually runs, so they get their own throwaway pod:

kubectl run kskmine --image=debian:stable-slim --rm -i --restart=Never \
  -- sh -c "cp /bin/sleep /tmp/xmrig && /tmp/xmrig 5"

That copies a harmless binary to /tmp/xmrig and runs it, firing both the miner rule and the tmp-execution rule.

Use a real distro image

The miner example uses debian:stable-slim rather than alpine on purpose. BusyBox invoked under another name exits with "applet not found" before it really execs, so the process never appears with the name the rule matches.

The remaining rules — NET_ADMIN, sensitive host mounts, suspicious outbound ports, kubectl in a pod — need a purpose-built pod spec or an outbound connection, so there's no safe one-liner. Read their conditions in rules/kubesentry-rules.yaml.

Tuning overrides

These three modify Falco defaults in place. Upstream keeps ownership of the detection logic; KubeSentry only adjusts scope and severity.

Falco rule	What KubeSentry changes	Why
Read sensitive file untrusted	Suppressed in kube-system, kube-public, kube-node-lease, falco, cert-manager, ingress-nginx	The kubelet and CNI read these files constantly. Fires in your namespaces, quiet in the platform's
Drop and execute new binary in container	Container-runtime and kubelet housekeeping excluded (runc, containerd-shim, mount helpers, platform images)	Otherwise it fires on normal pod startup on most clusters
Redirect STDOUT/STDIN to Network Connection in Container	Priority raised NOTICE → CRITICAL	This catches bash -i >& /dev/tcp/… — a live reverse shell, which upstream ships two buckets too quiet

Falco rules kept as-is

The stable ruleset contributes 25 detections. The ones you're most likely to meet:

Rule	Severity
Drop and execute new binary in container	Critical
Fileless execution via memfd_create	Critical
Detect release_agent file container escapes	Critical
Read sensitive file untrusted	High
Netcat remote code execution in container	High
Execution from /dev/shm	High
Linux kernel module injection	High
PTRACE attached to process	High
Terminal shell in container	Warning
Contact K8s API server from container	Warning

Because incubating and sandbox rules aren't loaded, some things you might expect to alert don't — writes below binary directories, privileged container launches, and shell-profile modification among them. See what won't alert, by design.

Remediation guidance

22 rules — all 11 KubeSentry rules, the 3 overrides, and 8 more Falco detections — carry a guidance entry: a plain-English explanation, ordered triage steps, concrete remediation commands, and a MITRE ATT&CK reference. It shows in the dashboard and travels with the alert into every notification channel — email, Slack, Discord, Teams, and generic webhooks.

Adding your own rules

The curated set is a starting point, not a ceiling. Add your own Falco rules through the falco values block — see Tuning detection noise.