Verify your installation

A five-minute check that proves the whole path works — Falco on the node, through falcosidekick, into the collector, onto the dashboard, and out to your notification channels.

Everything here runs against a throwaway pod you delete at the end. Nothing touches your real workloads.

1. Check the pods

kubectl get pods -n kubesentry

You should see three kinds of pod:

Pod	How many	What it does
<release>-falco-*	one per node	Reads kernel events (DaemonSet)
kubesentry-falcosidekick-*	one	Routes Falco events to the collector
kubesentry-collector-*	one	Dedup, storage, dashboard, notifications

Compare the Falco count against kubectl get nodes — one Falco pod per schedulable node is the expectation. A missing one means that node isn't being watched.

Only two of the three names are pinned

The collector and falcosidekick Services are pinned (kubesentry-collector, kubesentry-falcosidekick) so Falco can reach them under any release name. The Falco DaemonSet itself is not pinned — it's named after your release. Install as kubesentry and you get kubesentry-falco; install as ks and you get ks-falco.

Wait until everything is Running before continuing.

2. Open the dashboard

kubectl port-forward -n kubesentry svc/kubesentry-collector 8080:8080

Open http://localhost:8080/dashboard. On a fresh install: a yellow trial banner and an empty feed. Leave this open in a second terminal — you want to watch alerts land.

3. Create a throwaway target

kubectl run victim --image=ubuntu -- sleep 3600
kubectl wait --for=condition=Ready pod/victim --timeout=60s

4. Fire a High-severity detection

kubectl exec victim -- cat /etc/shadow

Within a few seconds the dashboard shows:

• Rule: Read sensitive file untrusted
• Severity: High
• Workload: victim / default

That's a Falco rule KubeSentry keeps and narrows — it stays quiet in kube-system and other platform namespaces, where reading these files is routine, and fires in your namespaces, where it isn't.

Use /etc/shadow, not /etc/passwd, for the read test

Falco's sensitive-file list is /etc/shadow, /etc/sudoers, /etc/pam.conf, and /etc/security/pwquality.conf. Reading /etc/passwd is world-readable, unremarkable, and deliberately not a detection — testing with it will look like KubeSentry is broken when it's working as designed.

5. Fire a Critical detection

kubectl exec victim -- bash -c "echo x >> /etc/passwd"

• Rule: KubeSentry: Sudoers or passwd modified in container
• Severity: Critical

Writing to /etc/passwd is a different matter from reading it — it's how an attacker adds an account. This is a KubeSentry rule, and it's the one to use when you're testing notifications.

6. Test your notification channels

Instant notifications fire for Critical alerts only (Falco CRITICAL, EMERGENCY, or ALERT). Everything else lands on the dashboard and in the daily digest, but doesn't page you.

That means step 5 sends a notification and step 4 does not — by design. If you're verifying that Slack or email is wired up correctly, use the /etc/passwd write:

kubectl exec victim -- bash -c "echo x >> /etc/passwd"

Within a few seconds you should get the alert in every channel you've configured, carrying the rule, the workload, the raw Falco output, and the remediation steps. Nothing arriving? Check the collector logs — notification failures are logged there and never block the alert from being stored:

kubectl logs -n kubesentry deploy/kubesentry-collector | grep -i notifier

See Notifications for per-channel setup.

7. Clean up

kubectl delete pod victim

The alerts stay in your history — they're on the collector's PersistentVolume, not in the pod.

What won't alert — by design

KubeSentry ships a curated ruleset, not raw Falco. A lot of activity that looks alarming in a demo is either normal in a real cluster or generates so many false positives that it trains people to ignore alerts. If you try these and see nothing, that's the product working:

You try	Why nothing fires
kubectl exec victim -- cat /etc/passwd	Not a sensitive file — world-readable by design. The write is what matters.
kubectl exec victim -- cat /root/.bashrc	Not on the sensitive-file list. Reading a shell profile isn't an attack signal.
kubectl exec victim -- cp /bin/ls /usr/bin/ls.evil	Writes below binary directories are in Falco's incubating ruleset, which KubeSentry doesn't load — it's noisy on any cluster that runs package updates in containers.
kubectl exec victim -- bash -c "id" (no -it)	The terminal-shell rule requires an attached TTY. Non-interactive exec is how most tooling and health checks work, so it isn't flagged.
Anything in kube-system	Platform namespaces are excluded from the sensitive-file rule — the kubelet and CNI read these files constantly.

Add -it and you'll see the difference:

kubectl exec -it victim -- bash     # fires "Terminal shell in container" (Warning)

For the full list of what does fire, see What KubeSentry detects.

Nothing showed up at all?

• Are all Falco pods Running? kubectl get pods -n kubesentry
• Did the collector receive anything? kubectl logs -n kubesentry deploy/kubesentry-collector
• Is falcosidekick reaching the collector? See Troubleshooting.