Show HN: Kguardian – seccomp profiles and NetworkPolicies from eBPF traces

Kguardian, a new open-source Kubernetes security tool, generates least-privilege NetworkPolicy, CiliumNetworkPolicy, and seccomp profiles from eBPF traces of pod traffic and syscalls rather than hand-authored rules. The tool uses an eBPF DaemonSet Controller to capture every TCP/UDP connection and syscall per node, a Broker that stores per-pod baselines in PostgreSQL, and a kubectl kguardian plugin that emits policy YAML for a pod, namespace, or cluster; it never applies policies itself, writing files to --output-dir for review. Kguardian also offers an AuditNetworkPolicy CRD that reports flows a policy would deny, cgroup v2 CPU/memory gauges with noisy-neighbour findings, and an optional LLM Bridge AI assistant for querying traffic and syscall data in natural language.

Least-privilege Kubernetes security policies, generated from what your pods actually do Overview -overview · In action -in-action · Features -features · Architecture %EF%B8%8F-architecture · Quick Start -quick-start · Usage %EF%B8%8F-usage · AI Assistant -ai-assistant · Compatibility -compatibility · Performance -performance · Telemetry -telemetry · Contributing -contributing · License -license kguardian watches pod traffic and syscalls with eBPF, then writes Kubernetes NetworkPolicy , CiliumNetworkPolicy , and seccomp profiles from what it sees — no hand-authored rules. It's built for platform and security teams who want policy-as-code without writing rules by hand: the Controller an eBPF DaemonSet captures every TCP/UDP connection and syscall on each node, the Broker stores the per-pod baseline in PostgreSQL, and the kubectl kguardian plugin turns that baseline into least-privilege policy YAML for any pod, namespace, or the whole cluster. | <sub Network Map — every flow eBPF saw, in one graph: trusted, egress, and would-deny edges for a live namespace here, Flux .</sub | <sub Policy Builder — a least-privilege NetworkPolicy or CiliumNetworkPolicy written from what the workload actually did.</sub | | <sub Workloads · Seccomp — per-workload syscall allow-lists with node readiness and drift against the deployed SeccompProfile , audit mode by default.</sub | <sub Policy as code — export the SeccompProfile CR, see the diff against what is deployed, commit it. kguardian never applies anything itself.</sub | - Network Policy generation — least-privilege Kubernetes NetworkPolicy and Cilium CiliumNetworkPolicy resources from observed pod-to-pod traffic. Each flow's peer is identified when it is captured, not when a policy is generated, so a recycled pod IP never allow-lists the wrong workload how peers are attributed https://docs.kguardian.dev/concepts/peer-attribution . - Seccomp profile generation — per-workload syscall allowlists derived from runtime traces, exported as a SeccompProfile CR you commit; the controller places the file on every node only once you apply it. Capture is tiered full by default, cheap thanks to in-BPF dedup; high / medium / low / custom for monitoring-only clusters , and only a full capture yields a profile safe to enforce. - Live compute gauges and noisy-neighbour detection — every pod on the map carries a live CPU/memory gauge from cgroup v2, and the broker raises a finding when a pod is starved noisy-neighbor , cpu-contended , memory-pressure or under-provisioned by its own limits cpu-throttled , memory-limit-thrash . With the optional eBPF scheduler probe it names the pod, system unit or kernel thread that was on the CPU while the victim waited — and it never blames a neighbour for a pod's own CFS throttling how it works https://docs.kguardian.dev/concepts/compute-contention . - Policy auditing before enforcement — the AuditNetworkPolicy CRD is byte-identical to an upstream NetworkPolicy , but instead of dropping packets the evaluator reports every flow the policy would deny. Ship policies with confidence instead of blackholing production. - Flexible targeting — generate per-pod, per-namespace, or cluster-wide. - Review-first by design — the CLI writes YAML to --output-dir and never applies anything to the cluster; you review and kubectl apply the files yourself. - GitOps-friendly output — plain YAML/JSON files ready for review or a GitOps pipeline. - Optional AI assistant — query traffic and syscall data in natural language via the LLM Bridge, in the web UI or from your own MCP client. Example policies for common workloads nginx, Postgres, kube-dns, Prometheus, Istio sidecar, a Go microservice live in the Policy Gallery https://github.com/kguardian-dev/kguardian/blob/main/docs/policy-gallery . For a comparison with Inspektor Gadget and Security Profiles Operator, see the docs site https://docs.kguardian.dev/ comparison-with-other-tools . graph LR subgraph "Each Node" C Controller<br/ Rust + eBPF end B Broker<br/ Rust + Actix DB PostgreSQL E Evaluator<br/ Go UI Web UI<br/ React CLI kubectl kguardian<br/ Go C -- |traffic + syscalls| B B -- DB B -- |flows| E E -- |would-deny verdicts| B UI -- B CLI -- |generate policies| B style C fill: 4E3AD9,color: fff style B fill: 6D5CE6,color: fff style E fill: 6D5CE6,color: fff style UI fill: 6D5CE6,color: fff style CLI fill: 3B2BA8,color: fff | Component | Language | Runs as | Purpose | |---|---|---|---| | Controller | Rust + eBPF C | DaemonSet | Captures every TCP/UDP connection and syscall on each node | | Broker | Rust Actix | Deployment + PostgreSQL | Stores per-pod behavioral baselines and serves the API | | Evaluator | Go | Deployment | Evaluates live flows against AuditNetworkPolicy CRDs and reports would-deny verdicts — without dropping a packet | | CLI kubectl kguardian | Go | kubectl plugin | Generates NetworkPolicies and seccomp profiles from the observed baseline | | Web UI | React + TypeScript | Deployment | Visualizes traffic, policies, and pod behavior | | LLM Bridge | TypeScript | Optional Deployment | Natural-language assistant over cluster traffic — runs all tools and policy/seccomp generation in-process, and optionally serves them to external MCP clients llm-bridge/README.md https://github.com/kguardian-dev/kguardian/blob/main/llm-bridge/README.md | Prerequisites: Kubernetes v1.19+, kubectl v1.19+, and Linux kernel 6.2+ on every node that runs the Controller DaemonSet see Compatibility -compatibility . Install the in-cluster components with Helm, then the kubectl plugin: helm install kguardian oci://ghcr.io/kguardian-dev/charts/kguardian \ --namespace kguardian --create-namespace sh -c "$ curl -fsSL https://raw.githubusercontent.com/kguardian-dev/kguardian/main/scripts/quick-install.sh " Give the Controller some time to observe real traffic, then generate policies: Least-privilege NetworkPolicy for one pod dry-run, saved to ./policies kubectl kguardian gen networkpolicy my-pod -n default --output-dir ./policies Cilium policies for every pod in a namespace kubectl kguardian gen netpol --all -n staging --type cilium --output-dir ./policies Seccomp profiles for all pods in all namespaces kubectl kguardian gen seccomp -A --output-dir ./seccomp Review the generated YAML, then apply it yourself kubectl apply -f ./policies . Manual download, custom Helm values, Kind setup, verification, upgrades, and uninstall are covered in the Installation Guide https://docs.kguardian.dev/installation . The plugin follows the standard kubectl command structure: kubectl kguardian gen <networkpolicy|seccomp pod-name flags | Flag | Applies to | Description | |---|---|---| | -n, --namespace | both | Namespace scope defaults to current context namespace | | --all | both | All pods in the selected namespace -a shorthand: networkpolicy only | | -A, --all-namespaces | both | All pods in all namespaces | | --output-dir | both | Directory for generated files network-policies / seccomp-profiles | | -t, --type | networkpolicy | kubernetes default or cilium | | --dry-run | networkpolicy | true default . Applying directly is not implemented yet — the CLI always writes files only | | --default-action | seccomp | Action for unlisted syscalls: SCMP ACT ERRNO default , SCMP ACT LOG , SCMP ACT KILL | Full command reference, including audit workflows and advanced flags, is in the CLI docs https://docs.kguardian.dev/cli . kguardian ships an optional natural-language assistant: ask questions like "what has this pod talked to in the last hour?" or "generate a seccomp profile for the payments namespace" from the Web UI. It's a single service, the LLM Bridge SSE streaming , that reads the broker's data directly and generates policies and seccomp profiles in-process — bring your own API key for OpenAI, Anthropic, Gemini, or GitHub Copilot. ai: enabled: true provider: anthropic openai | anthropic | gemini | copilot secret: kguardian-anthropic Secret holding the key under api-key Running an OpenAI-compatible gateway LiteLLM, vLLM, a proxy ? Add ai.baseUrl and ai.model . Two things to know: the API key is still required — provider availability is gated on the key alone, so point ai.secret at your gateway's virtual key or a dummy value if it's unauthenticated — and kguardian appends the request path to your base URL verbatim , never adding or stripping /v1 . See the AI assistant setup https://docs.kguardian.dev/installation ai-assistant . The same 23 tools can be served over MCP at POST /mcp on the LLM Bridge, so Claude Code — or any MCP client — can read your cluster's observed telemetry and write policies from it. Off by default; enable with ai.mcp. , port-forward, and add one server entry: kubectl -n kguardian port-forward svc/kguardian-llm-bridge 8080:8080 claude mcp add --transport http kguardian http://localhost:8080/mcp \ --header "Authorization: Bearer $KGUARDIAN MCP TOKEN" Full walkthrough: Connect an MCP Client https://docs.kguardian.dev/guides/mcp-endpoint . Env vars, routes, and local development: llm-bridge/README.md https://github.com/kguardian-dev/kguardian/blob/main/llm-bridge/README.md . The eBPF Controller requires Linux kernel 6.2 or newer on every node in the DaemonSet. Verify with uname -r before installing. | Distro | Default kernel | Compatible? | |---|---|---| | Ubuntu 24.04 | 6.8 | ✅ | | Ubuntu 22.04 | 5.15 | ❌ needs HWE 6.2+ | | RHEL 9 | 5.14 | ❌ | | Amazon Linux 2023 | 6.1 | ❌ needs kernel-6.12+ AMI | | Debian 12 | 6.1 | ❌ needs backports | | Talos / Bottlerocket | usually 6.1+ | check distro version | Kernel versions reflect the GA/server defaults shipped by each distro as of May 2026; newer kernels are typically available via each distro's opt-in channels. IPv4, IPv6, and dual-stack clusters are all supported. The Controller reads both AF INET and AF INET6 sockets, and policy generation emits /32 or /128 ipBlocks per peer — a dual-stack pod gets both families in one policy. Things to know: - Dual-stack pods and Services are tracked on every address , not just the primary one in .status.podIP / .spec.clusterIP . A peer is therefore resolved to a podSelector regardless of which family the traffic used. - Nodes built with CONFIG IPV6=n are handled: the IPv6 socket fields are read behind a CO-RE existence guard, so the Controller loads and runs normally on such kernels — it simply never sees v6 flows there. - Every service listener is dual-stack. The broker, frontend, llm-bridge and evaluator bind the IPv6 unspecified address accepting IPv4 as v4-mapped and fall back to IPv4-only on kernels without IPv6 — so the stack serves IPv4-only, dual-stack, and IPv6-only clusters alike. The broker's LISTEN ADDR env still binds verbatim when set. - Kernels with IPv6 as a module but no module BTF kernels older than 5.11, or built with CONFIG DEBUG INFO BTF MODULES=n — Debian 11's 5.10 is the common case can't attach the IPv6 UDP probes. The Controller detects this at startup, logs a warning, and runs with those probes disabled rather than failing; IPv6 TCP capture is unaffected. - UDP flows are captured from connected sockets glibc's DNS resolver connects, so pod DNS is covered on both families . Unconnected sendto datagrams carry no destination on the socket at the probe point and are not captured — the same behaviour IPv4 has always had, notable mainly for musl-based Alpine resolvers. A generated policy is only as complete as what was observed. If a workload speaks both families but was only exercised over one during the observation window, the policy will reflect that — review before enforcing, as always. Reference figures from a real-world deployment — a 3-node cluster 18 vCPU / 47 GiB RAM per node, Cilium CNI observing 234 pods across 26 namespaces of mixed traffic: - Controller eBPF DaemonSet : ~60 MiB memory and ~0.1–0.6 vCPU per node, tracking the node's connection/syscall rate. - Broker + evaluator: evaluator ~26 MiB / <0.01 vCPU idle; broker sized at 512 MiB request / 2 GiB limit with plenty of headroom at this scale. - PostgreSQL is the dominant consumer ~0.4–2 GiB RAM here, CPU spiking under ingest + autovacuum — size it generously. - Storage growth is dedup-bounded: once a workload's flow set is learned, new rows drop to ~0/min in steady state. The database grows with new behavior, not with time or traffic volume; broker.audit.retention.days caps the audit-verdict history. This is one measured data point, not a synthetic sweep — treat it as an order-of-magnitude envelope. Expect numbers to scale with flow cardinality, not raw pod count. The broker performs a daily anonymous version check-in that powers the UI's update notice and is the project's only usage signal. Exactly six fields are sent — a random install UUID, broker/chart/Kubernetes versions, node count, and CPU architecture; no cluster names, IPs, or workload data, ever. It's on by default, announced at install time, documented field-by-field in the telemetry docs https://docs.kguardian.dev/telemetry , and disabled with --set telemetry.enabled=false . Contributions are welcome — read the contributing guide https://github.com/kguardian-dev/kguardian/blob/main/CONTRIBUTING.md to get started. The release process and versioning strategy are documented in RELEASES.md https://github.com/kguardian-dev/kguardian/blob/main/RELEASES.md , and security reports go through SECURITY.md https://github.com/kguardian-dev/kguardian/blob/main/SECURITY.md . Licensed under the Business Source License 1.1 https://github.com/kguardian-dev/kguardian/blob/main/LICENSE : - Free for development, testing, evaluation, and non-production/non-commercial use - Commercial use requires a commercial license contact the licensors - Converts to Apache License 2.0 on January 1, 2029