Architecture

KubeSentry has two runtime paths: the in-cluster detection pipeline (what happens when something suspicious occurs) and the license flow (what happens when you buy and activate). Everything security-relevant stays inside your cluster.

In-cluster runtime

                    ┌─────────────┐
   each node ─────► │    Falco    │  detects kernel-level events (DaemonSet)
                    └──────┬──────┘
                           ▼
                    ┌───────────────┐
                    │ Falcosidekick │  routes events over HTTP
                    └──────┬────────┘
                           ▼
                    ┌─────────────┐
                    │  Collector  │  aggregate · dedupe · store
                    └──┬───┬───┬──┘
                       ▼   ▼   ▼
                  Dashboard  DB  Notifier
                  (live)  (PVC)  (email + webhook)

• Falco runs as a DaemonSet — one pod per node — watching the kernel for suspicious runtime behavior (shells in containers, unexpected network activity, sensitive file access, and more).
• Falcosidekick receives Falco's output and forwards it over HTTP to the collector. The chart pins the Falcosidekick Service name and the Falco output URL so the two agree regardless of quirks in name generation — Falco posts to kubesentry-falcosidekick, which forwards to kubesentry-collector. (This is also why you install with the release name kubesentry: the collector Service must resolve to that fixed name.)
• The collector is the heart of KubeSentry: it aggregates and deduplicates incoming events, persists them to an embedded SQLite database on a PersistentVolume, serves the live dashboard, and drives notifications.
• The dashboard shows alerts within a few seconds of the underlying event.
• The notifier sends instant email on high-severity alerts and a daily digest of the rest, plus optional Slack/Discord/Teams webhooks.

Alert data never leaves the cluster unless you configure email/webhook egress.

License flow

Buying and activating touches an external payment path, but your cluster never talks to it directly — you receive a token and apply it offline.

  Customer buys ──► Lemon Squeezy ──► Cloudflare Worker (license server)
                                            │
                                            ▼
                                    mint Ed25519-signed license
                                            │
                                            ▼
                                    Resend ──► license email ──► customer
                                            │
                                            ▼
                              helm upgrade --set license=…
                                            │
                                            ▼
                              collector verifies signature offline

• A purchase in Lemon Squeezy fires a signed webhook to a Cloudflare Worker (the license server).
• The Worker verifies the webhook signature, then mints an Ed25519-signed license token encoding the plan and expiry.
• The token is emailed to the customer via Resend.
• The customer applies it with helm upgrade. The collector validates it offline using the public key compiled into the binary — no runtime dependency on the license server.

This split matters: the license server is only involved at purchase time. Your running cluster verifies licenses on its own, which is why activation works in air-gapped environments and why there's no phone-home.

Design principles

• Self-hosted first — detection, storage, and dashboard all live in your cluster.
• No phone-home — offline license verification, no runtime telemetry.
• Lightweight collector — a ~15 MB distroless image; Falco is the only heavy component, and it has to be, since it reads the kernel.
• Fail open on licensing — a bad or missing token degrades to trial behavior rather than taking your monitoring offline.