Architecture & Deployment
15 minutes from Helm install to runtime visibility.
Runtimekindle runs as a privileged DaemonSet — one pod per node, kernel-level eBPF probes, zero application code changes. Here's how the full stack connects from syscall to alert.
Technical Architecture
From kernel syscall to control plane in under 2ms
eBPF DaemonSet deploys to every node
A single helm install runtimekindle runtimekindle/agent deploys the DaemonSet across your cluster. Each pod runs a privileged eBPF agent that hooks into the Linux kernel via BTF-enabled kprobes and tracepoints — no kernel module, no code injection, no sidecar container required.
Kernel probes capture syscall telemetry
eBPF programs attached to execve, connect, openat, and 40+ other syscalls capture process events at kernel speed — before they complete. The agent tracks process lineage (parent PID, namespace, cgroup), network connections by pod identity, and file access patterns. All in a ring buffer with sub-2ms latency.
Local policy engine filters events
The on-node policy engine evaluates events against your ruleset before forwarding — suppressing known-good baselines and flagging anomalies. Policy rules are defined in YAML and updated without restarting the DaemonSet. Only actionable events leave the node, keeping control-plane bandwidth under 1 Mbps per node.
SBOM and provenance generated at CI
A separate GitHub Action / GitLab CI step runs at build time — independent of the runtime agent. It scans your build environment, generates a CycloneDX 1.5 SBOM, signs the artifact with Sigstore cosign using your CI OIDC token, and stores the SLSA L2 provenance record in Rekor. The admission webhook then enforces: unattested images cannot deploy.
Control plane correlates runtime + static data
The Runtimekindle control plane receives runtime events from all nodes and cross-references them against your SBOM library. CVEs in libraries that no running process has loaded in the observation window are deprioritized automatically. Alerts are enriched with pod identity, process lineage, and CVE severity before delivery to your SIEM or ticketing system.
Technical Details
Architecture reference
Deployment FAQ
Common questions about the deployment model
No. Runtimekindle uses BTF (BPF Type Format) CO-RE (Compile Once, Run Everywhere) programs — no kernel module required. The agent runs on Linux kernels 5.8+ with BTF enabled, which covers all major managed Kubernetes offerings (EKS, GKE, AKS) on their default node images. We don't touch the kernel source or require any kernel development headers at runtime.
The eBPF agent is designed for production carriage loads. Typical overhead: 0.05-0.15 CPU cores and 80-200 MB RSS per node under normal workloads. Network egress to the control plane is under 1 Mbps per node on busy clusters. We publish benchmark numbers for common node sizes (c5.xlarge, n2-standard-4) in the docs.
The admission webhook adds under 50ms to your pod startup time — it validates the cosign signature against your configured policy and the Sigstore public Rekor log. Webhook availability is critical for your cluster availability, so Runtimekindle deploys the webhook with multiple replicas and configures failurePolicy: Fail only for images where you explicitly require attestation. The policy is namespace-scoped — you can roll it out gradually.
Yes. Runtimekindle uses its own eBPF programs and doesn't conflict with other eBPF-based agents (Falco, Cilium, Pixie). Multiple eBPF programs can attach to the same tracepoints simultaneously — the kernel multiplexes them. We've tested coexistence with Falco 0.37+, Cilium 1.14+, and Datadog Agent 7.50+. See the integrations page for tested combinations.
Runtimekindle uses an egress-only TLS connection from the DaemonSet to the control plane. The agent sends: process execution events (binary path, args, PIDs, namespaces), network connection metadata (IPs, ports — not payload content), and file access events (paths, not content). Application data, secrets, and payload contents are never read. Event data is encrypted in transit and at rest. For compliance environments, we offer a self-hosted control plane option.
Ready to see the architecture in your cluster?
Walk through a technical deployment review with Yael. 30 minutes, specific to your K8s setup.