Cilium Tetragon → Sysdig Secure

Cilium Tetragon ↔ Sysdig Secure: integration to migration path.

Tetragon deploys alongside the Sysdig Agent first, in observation-only mode — both sensors on every node, Sysdig still the verdict of record, no enforcement and no re-routing. Only after each rule proves parity does detection, then enforcement, transfer to Tetragon in phases, every one reversible in minutes.

The honest exception up front: what you really lose with Sysdig is the curated rule pack, not the sensor. We name an internal rule-curation owner before the cut, because the rest of this only works if detections stay tuned.

The idea

Two sensors on every node, then transfer one rule at a time.

The topology that makes this zero-downtime: both privileged DaemonSets co-exist — there is no kernel-level mutex on attaching eBPF programs to the same tracepoint, so Tetragon can run observation-only next to a fully authoritative Sysdig Agent. Events flow to separate SIEM indices, which lets us diff Tetragon against Sysdig per rule on a (node, cgroup_id, pid, timestamp) join. Detection routing moves only after 95% parity holds for 14 days; enforcement moves only on a curated, kernel-matrix-tested rule set; and Sysdig is removed only after 30 days of Tetragon-only alerting. You are never without a runtime safety net.

The phases

Six steps. Each one reversible.

0

Baseline & inventory

We document every Sysdig rule in use — its condition, output, priority, MITRE tag and last-7-day true/false-positive history — plus each node's kernel version and BTF availability. Read-only. No BTF on a node pool is a hard blocker we surface now.

Users see: No user impact.

Rollback: N/A — nothing changed.

1

Tetragon goes live in observation mode

The Tetragon DaemonSet deploys cluster-wide with no enforcement anywhere — TracingPolicy CRDs cover the same kernel hooks as Sysdig's default pack and events ship to a separate SIEM index. Sysdig stays the only verdict source.

Users see: No user impact; SREs see two DaemonSets per node.

Rollback: kubectl delete -f tetragon/. Sysdig untouched. Under 5 minutes.

2

Rule parity translation

Each Sysdig rule we keep gets a matching TracingPolicy, deployed in observation mode, validated against a synthetic exec, then measured: Tetragon must catch 95% or more of Sysdig's alerts for that rule over 14 days. Gaps are fixed or documented.

Users see: No user impact.

Rollback: kubectl delete tracingpolicy per rule. Under 2 minutes.

3

Route SIEM detections to Tetragon

For low-blast-radius rules at proven parity, SIEM detections-as-code repoint to Tetragon's event index and the matching Sysdig alerts are suppressed at the SIEM — not disabled in Sysdig, so the comparison baseline survives. A 14-day shadow run per rule.

Users see: No user impact; the SOC UI is unchanged, only the underlying source field differs.

Rollback: Re-enable the dormant Sysdig-shaped detection. Under 10 minutes.

4

Promote Tetragon to enforcement

A curated 5–15 rule set — container escape, host mount, ptrace of PID 1, write to host /etc — carries matchActions Sigkill at the kernel tier. Sysdig inline enforcement is disabled for exactly those rules so two signals never collide. Staged non-prod to fleet.

Users see: Workloads hitting an enforced rule are SIGKILL'd by Tetragon — the intended behaviour. Sysdig still records the event.

Rollback: Remove matchActions from the policy. Under 5 minutes; Sysdig detection coverage stays present.

5

Decommission Sysdig

After 30 days of Tetragon-only alerting confirms no missed detections, the Sysdig Agent is uninstalled and the tenant is held read-only for 30 days as an evidence window before the contract is terminated.

Users see: Sysdig bookmarks 404 after the final stage — communicated 30 days ahead.

Rollback: Re-install the Sysdig Agent within the read-only window — under 2 hours including the DaemonSet roll. After the window closes, out of scope.

Feature parity

Where Tetragon matches Sysdig — and where it cannot.

CapabilityCilium TetragonSysdig SecureParity
Runtime detection (eBPF/kprobe) TracingPolicy kprobes, tracepoints and LSM hooks Sysdig Agent modern_bpf plus managed Falco rules At parity
Kernel-tier event filtering selectors evaluated in eBPF before userspace modern_bpf partial filter pushdown Partial
Sequence-based detection (IOA) selectors chained via FollowFD / TrackSock Stateless Falco rules plus Risk Spotlight stitching Partial
Inline enforcement Sigkill / Override / NoPost at the kernel tier Sysdig inline enforcement (detection-first heritage) Partial
Process ancestry / tree Full tree to PID 1 with pod and container enrichment Equivalent cgroup_id, pid, ppid, comm, exe At parity
Policy-as-data / GitOps TracingPolicy CRD in Git Sysdig UI policies plus Terraform provider Partial
Managed rule pack curation None — public policy library only Sysdig Threat Research curated packs SaaS only
Capture replay / deep IR tetra getevents plus bpftrace (no UI) Sysdig Inspect — .scap full-syscall replay SaaS only
Risk-prioritized correlation None Risk Spotlight (runtime, vuln, posture) SaaS only
Per-image behavioural baseline None Sysdig Image Profiles per-digest SaaS only
Network flow (L3/L4/L7) Hubble (requires Cilium CNI) Sysdig agent network context Partial
Alerting / routing gRPC GetEvents / tetragon-export-stdout to SIEM Sysdig backend to forwarders At parity
Cost model Self-hosted compute Per-node / per-vCPU SaaS licensing At parity
Compliance boundary (SOC 2 / FedRAMP) Self-operated, your audit scope Vendor SOC 2 / FedRAMP boundary SaaS only

What we're honest about

The gaps most vendors leave out.

You inherit rule curation — that is the real product

Sysdig's threat-research team curates and tunes the managed Falco rule packs you rely on. Tetragon ships a public policy library, not a curated, threat-intel-fed pack. Without a named internal owner for the rule library, this is the risk that actually lands — so we budget for a curation owner before, not after, Sysdig comes out.

No capture-replay, no Risk Spotlight, no Image Profiles

Sysdig Inspect replays full-syscall .scap captures around an alert; Tetragon emits matched events and tetra getevents or bpftrace is the closest analogue — not a UI. Risk Spotlight's runtime-plus-vuln-plus-posture correlation and per-digest Image Profiles have no OSS parity either. We document each gap and either keep a residual Sysdig SKU or train the SOC on the replacement workflow.

Enforcement has a kernel-version matrix

Sigkill on some syscalls can race the kernel side-effect on older kernels; clean denial via LSM Override needs kernel 5.7-plus with BPF LSM enabled. Your fleet kernel matrix is the gating constraint — we inventory it in Phase 0 and taint-exclude non-conforming pools rather than let one slip into enforcement.

Self-hosting moves the boundary to you

Sysdig's SaaS backend, ingest and retention sit in their SOC 2 report. A self-hosted Tetragon sensor and your SIEM bring those into your audit scope — patch cadence, retention, IR runbooks become yours. We update the SSP and run at least one audit cycle with both sensors before retiring Sysdig as evidence.

Why this beats a flag day

Reversible in minutes, retired only after a soak.

Every integration and detection phase rolls back in under 15 minutes — a kubectl delete of a policy, or re-enabling a dormant Sysdig-shaped detection while both sensors still run. Enforcement promotes a rule at a time and reverts in under 5 minutes by removing matchActions. The Sysdig Agent is uninstalled only after at least 30 days of Tetragon-only alerting with no missed detections, and the tenant is then held read-only for a further 30 days as an evidence window before the contract is cancelled.

See whether your runtime detections migrate cleanly.

A 30-minute call with a senior container-security engineer. We inventory your Sysdig rules and your fleet kernel matrix, identify the rules that key on vendor enrichment and cannot move as-is, and tell you honestly which Sysdig SKUs you should keep — before you commit to anything.

Map my migration →