Ebpf on Tarragon

Falco

Mon, 18 May 2026 00:00:00 +0000

Falco 是 CNCF Graduated 的 runtime cloud-native threat detection engine、原 Sysdig 開源、Apache 2.0 license。它在 host / container 上用 eBPF（或 kernel module / userspace fallback）攔截 syscall、跟 Plugin 拉到的 audit log 串成同一條 event stream、丟給 Rule engine 比對 YAML rule、命中後 alert 到 stdout / Falcosidekick / SIEM。它跟商業 CNAPP runtime 模組（Datadog CWS / Lacework Polygraph / Prisma Cloud Defender）的差異在 OSS rule-based vs SaaS ML-based + 平台廣度 + 自動 response 的工程責任歸屬、偵測技術本身相近。

服務定位

Falco 的核心定位是 K8s container runtime detection engine 的 OSS 基準、不是 full CNAPP、也不是 inline enforcement。底層 Driver 分三層：modern eBPF（Linux 5.8+、預設）、legacy kernel module (kmod)（舊 kernel fallback）、pdig userspace probe（沒 root 或非 Linux）；Driver 抓 syscall 跟 K8s audit / cloud audit event、送進 Falco engine；engine 用 Sysdig filter syntax 比對 YAML rule、命中後吐 alert。Plugin 系統讓 Falco 看到非 syscall event（K8s audit log、Okta event、GitHub audit、AWS CloudTrail）— 變成 general detection engine、不只 host runtime。

跟 Cilium Tetragon 比、Falco 走 rule engine + alert-only、Tetragon 走 eBPF + 可 enforce kill action；Falco 偵測為主、Tetragon 偵測 + 防護。跟 Datadog Security（CWS）比、Datadog 是 SaaS observability 上加 runtime security view、ML-based behavioral baseline 內建、但 vendor lock + per-host 計費；Falco 是 OSS 自管、rule 完全可寫、但 ML baseline / threat intel / cross-source correlation 要自己接 SIEM。跟 Lacework Polygraph 比、Lacework 走 behavior graph 自動建 baseline、Falco 走 rule-explicit、邊界看得到也好 audit。

關鍵張力：偵測 vs 防護 跟 rule-explicit vs ML-baseline 是兩條取捨軸。Falco 預設只發 alert、要 inline kill / cordon 要靠 Falco Talon 或外接 SOAR；rule 完全可寫是優點也是負擔 — 自家 anti-pattern 要自己寫成 condition、不像 SaaS CNAPP 預設有 ML baseline。

本章目標

讀完本頁、讀者能判斷：

Falco 在 K8s runtime security stack 中承擔哪一段（syscall detection / audit log detection / alert forwarding）、哪些要外接（Talon / SIEM / SOAR）
Driver 選擇（modern eBPF / kmod / pdig）跟 kernel 環境 / 部署模型的對應、選錯會 silent miss event
Rule 寫作的 ownership 設計（誰寫、誰 review、staging 怎麼觀察 false positive）
何時用 Falco、何時改走 Tetragon（要 enforcement）或商業 CNAPP（要 ML baseline + 跨雲 posture）

最短判讀路徑

判斷 Falco deployment 是否健康、最少看四件事：

Driver 是否符合 kernel 環境：modern eBPF on 5.8+ / kmod on legacy / pdig on serverless 或 non-root container；driver 跟 kernel 不對等於 silent miss，要看 falco --version 跟啟動 log 確認 driver 載入成功
Rule ownership 跟 lifecycle：Falco 內建 rule（falco_rules.yaml / k8s_audit_rules.yaml）+ 自家 custom rule 是否走 Git PR review、staging tenant 跑幾小時觀察 false positive、再 promote production
Alert sink + downstream routing：Falco 預設輸出 stdout / file / syslog、production 幾乎都接 Falcosidekick 做 fan-out（Slack / SIEM / S3 / Webhook），跟 Splunk / Elastic Security / Datadog Security 的接點明確
Response 是 alert-only 還是有 enforcement：純 alert 走 8 事故處理 routing；要自動 kill pod / cordon node 需 Falco Talon 或 SOAR、且 high-impact action 走 approval gate

四件事任一缺失、就是 Detection Coverage and Signal Governance 邊界的待補項目。

日常操作與決策形狀

Driver layer：Falco 三種 driver — modern eBPF（CO-RE、Linux 5.8+、預設、不需 kernel header）、legacy kernel module（kmod、舊 kernel 唯一選、要 DKMS build）、pdig（userspace、ptrace-based、非 root container 或 macOS dev 環境用、效能差）。production K8s deployment 幾乎都走 modern eBPF、DaemonSet 部署到每個 node、kernel 版本不夠才走 kmod；不要混用 driver、否則 alert source 難對齊。

Rule YAML 結構：Falco rule 由 condition（Sysdig filter syntax、類 SQL where）、output（alert template、含 field interpolation）、priority（emergency / alert / critical / error / warning / notice / informational / debug）、tags（mitre / cis / NIST 對應）組成。condition 寫法跟 Linux syscall 緊耦合（evt.type=execve、fd.name=/etc/passwd、proc.name=nc）— rule engineer 要對 syscall 跟 process tree 熟悉。macro 跟 list 讓 rule 可重用（macro: container_started / list: shell_binaries）、production rule 庫應該 macro-first、不是每條 rule 重寫 condition。

Plugin ecosystem：Plugin 把 Falco 從 host syscall 擴張到任意 event source — k8saudit plugin 接 K8s API server audit log（看 RBAC change / Secret access）、cloudtrail plugin 接 AWS CloudTrail、okta plugin 接 Okta system log、github plugin 接 GitHub audit log。Plugin 讓 Falco 成為 general detection engine、不只 container runtime；但 plugin event source 跟 SIEM 重疊、要清楚 ownership — Falco 做近 host 即時偵測、SIEM 做跨來源歷史 correlation、別兩邊都跑同一條 rule。

Falcosidekick + alert fan-out：Falco engine 預設輸出 stdout / file / gRPC、production 接 Falcosidekick（DaemonSet 旁邊或單獨 Deployment）做 fan-out — 同一個 alert 同時 forward 到 Slack（SOC chat）、Splunk HEC / Elastic / Loki（SIEM 持久化）、S3（合規 archive）、Webhook（自家 dashboard）、Prometheus（metrics）。Sidekick 是 stateless forwarder、不做 dedup / aggregation、那層要在 SIEM 處理。

Falco Talon + 自動 response：Talon 是 response orchestrator、訂閱 Falcosidekick 的 webhook output、依照 rule action 自動執行 — kill pod、cordon node、加 NetworkPolicy、call webhook 通知 SOAR。Talon 把 偵測 → 處置 從手動 SOC playbook 變 declarative YAML、但 high-impact action（kill prod pod、cordon node）必須走 approval gate 或限制在 staging namespace、不能黑箱 fire-and-forget。對應 Detection to Response Routing 的章節原則。

Helm chart 部署 + GitOps：Falco 官方 Helm chart 把 DaemonSet（Falco engine + driver）、Deployment（Falcosidekick）、ConfigMap（rule YAML）、ServiceAccount + RBAC 包成一組。生產 deployment 走 Argo CD / Flux 同步 Helm value、rule YAML 進 Git PR review、merge 觸發 staging tenant deploy、人工觀察 24-48hr false positive、再 promote production。Rule 直接改 ConfigMap、不走版控等於 detection drift、後續審計接不上。

跟 SIEM / 8 事故處理整合：Falco alert 經 Falcosidekick 進 Splunk / Elastic Security / Datadog Security 後、走跟其他 detection signal 同一條 correlation + triage 管線、不獨立 channel。Notable / high-priority alert 進 8 事故處理的 IR queue、走 incident commander handoff。

核心取捨表

取捨維度	Falco	Cilium Tetragon	Datadog CWS	Lacework Polygraph
License	Apache 2.0 OSS	Apache 2.0 OSS	Commercial SaaS	Commercial SaaS
Detection 模型	Rule-explicit（YAML + Sysdig filter）	Rule-explicit（YAML + TracingPolicy）	ML-based behavioral baseline + rule	Behavior graph 自動 baseline
Enforcement	Alert-only（Talon 補 response）	Inline enforce（kill / signal、可阻擋）	Inline enforce（Datadog Agent）	Alert + workload baseline drift
Driver	modern eBPF / kmod / pdig	eBPF only（cilium ecosystem）	eBPF（Datadog Agent）	eBPF（Lacework Agent）
涵蓋面	Container + host + plugin (audit log)	Container + host（cilium 整合 network）	Container + host + cloud + app	Cloud + container + workload + IaC posture
Cross-source	靠 Plugin + Falcosidekick → SIEM	靠 Cilium Hubble + 外接 SIEM	內建（Datadog observability plane）	內建（Polygraph graph）
學習曲線	中 — Sysdig filter + macro	中 — TracingPolicy + cilium 知識	緩 — 沿用 Datadog UI / Workload Security	緩 — SaaS console
適合場景	OSS-first、SIEM 已部署、rule 想完全可寫	要 inline enforcement、cilium CNI 已用	Datadog 已用、cloud-native、預算允許	CNAPP + posture 一站、跨雲
退場成本	低 — rule 是 YAML、可移植 Sigma	中 — TracingPolicy 跟 cilium 綁定	高 — Workload Security rule 跟 platform 綁	高 — Polygraph data 跟 platform 綁

選 Falco 的核心訴求：K8s container runtime detection、OSS + rule-customizable、SIEM 已部署、SOC 有 detection engineer 寫得了 Sysdig filter rule。要 inline enforcement 直接走 Tetragon；要 ML baseline + 跨雲 posture + 不想自管 rule lifecycle 直接走 Datadog CWS / Lacework / Wiz + CrowdStrike Falcon CS。

進階主題

Custom rule 設計：production rule 庫應該 macro-first、把可重用條件抽成 macro（container_started / sensitive_mount / shell_in_container）跟 list（shell_binaries / sensitive_files）；rule 引用 macro 而非重寫 condition、修改 macro 等於同時更新所有引用 rule。Rule 反例是 single-event noisy rule（看到一個 shell exec 就 alert）— production rule 應該 context-bounded（shell exec in container + parent 不在 allowlist + image 非 trusted registry）+ priority 階梯（生產 Notice、staging Warning、新規則先 Informational 觀察）。

eBPF driver vs kmod 取捨：modern eBPF 用 CO-RE（Compile Once, Run Everywhere）、不需 per-kernel build、運行時動態 attach；kmod 需要 DKMS 在 host build、跟 kernel version 強耦合、升級 kernel 要重 build。所有現代 Linux distro 預設都該走 modern eBPF；只有 RHEL 7 / 老 Ubuntu LTS（kernel < 5.8）才有理由用 kmod。pdig 給沒 root / 沒 eBPF 的環境（某些 serverless container、macOS dev）、效能差不適合 production。

Falco Talon 自動 response 設計：Talon 把「Falco alert → 自動處置」變 declarative — rule action 可以是 kubernetes:terminate-pod、kubernetes:label-pod、kubernetes:cordon-node、aws:disable-iam-user、calico:add-networkpolicy。production 用 Talon 的關鍵原則：high-impact action 走 approval gate（PagerDuty incident → human approve → execute）、containment-first not deletion（先 cordon + label、再人工決定是否 terminate）、blast radius 限制（只能影響特定 namespace / label selector）、audit trail（每個 action 進 Splunk + IR queue）。

Plugin ecosystem 邊界：Plugin 把 Falco 變 general detection engine、但要明確 plugin event 跟 SIEM 重疊處的 ownership。建議：host syscall + container runtime → Falco rule（即時 + low latency）、K8s audit + cloud audit + IdP audit → 同時跑 Falco plugin（近即時 alert） + SIEM（歷史 correlation）、純跨來源 correlation（多 user 多 source 多時段）→ SIEM 為主。別讓 Falco plugin 跟 SIEM rule 跑重複條件、會 double-alert 也 double-cost。

Sigstore + SBOM 整合的位置：Falco 不做 image scan / SBOM 驗證（那是 Trivy / Syft & Grype 的位置）、但 runtime detection 是 Supply Chain Integrity 縱深防禦的最後一層 — image scan 過、簽章驗證過、但 runtime 出現異常 syscall（log4shell 觸發 outbound LDAP、SolarWinds 合法簽章但行為異常）、Falco rule 是最後抓的點。

排錯與失敗快速判讀

Falco 啟動成功但完全沒 event：driver 沒載入（modern eBPF 在舊 kernel fallback 失敗）— 看啟動 log 確認 driver loaded successfully、falco --version 對 driver 版本、舊 kernel 改 kmod
大量 false positive 淹沒 SOC：rule 寫太寬（shell in container 但合法 debug shell 也 trigger）— staging tenant 跑 48hr 統計 FP、加 exception list 或改 macro 排除已知合法 source、新 rule 先 Informational priority 觀察
Alert 沒進 SIEM：Falcosidekick 沒接、或 output channel 設錯 — 確認 Falcosidekick Deployment up、output webhook 對、SIEM HEC token 沒過期；Falco engine 本身的 stdout / file output 仍會留、不會 silent miss
Rule update 後 detection drift：直接改 ConfigMap、沒走 Git PR + staging 觀察 — 強制 GitOps（Argo CD / Flux）、ConfigMap immutable、rule change 必須走 PR review + staging promote
Plugin event lag / 漏抓：plugin polling cloud audit log（CloudTrail / Okta）的 latency 跟 API rate limit、不是即時 — 純即時偵測別靠 plugin、改靠 SIEM streaming ingest；plugin 適合補 syscall 看不到的層
Talon 自動 response 誤殺 prod：rule action 直接 kill pod、沒 approval gate — 高影響 action 拆成兩步（先 label + cordon、再人工 approve terminate）、blast radius 限 namespace / label selector、audit trail 全進 SIEM
eBPF driver 跟 kernel 升級不對齊：node kernel 升級後 modern eBPF 仍 CO-RE 自動適配、但 Falco 版本太舊不支援新 syscall — Falco engine 跟著定期升級、別 pin 在兩年前的 version

何時改走其他服務

需求形狀	改走
要 inline kill / enforcement	Cilium Tetragon
ML behavioral baseline + 跨雲	Datadog Security、Lacework、Wiz
Full CNAPP + posture + runtime	Prisma Cloud、CrowdStrike Falcon CS
Image scan / SBOM / SCA	Trivy、Syft & Grype、Snyk
Cross-source SIEM correlation	Splunk、Elastic Security、Google Security Operations
Incident routing	8 事故處理 vendor 清單

不在本頁內的主題

Sysdig filter syntax 完整 reference、syscall field 細目
Falco source code 內部架構（libsinsp / libscap）
Sysdig Secure（Falco 的商業版、Sysdig Inc. 維護、含 ML baseline + cloud posture）的功能對照細節
Container image scan / SBOM 驗證（屬 Trivy / Syft & Grype 的位置）
Kubernetes RBAC / Pod Security Standards / NetworkPolicy 的設計（屬 K8s 平台層、不在 runtime detection 範圍）

案例回寫

Falco 在 07 案例庫沒有直接 vendor-level 事件、但多個 runtime / supply chain case 都是 Falco rule 第一線該抓的場景：

案例	跟 Falco 的關係（對照啟示）
3CX 2023 Desktop App Supply Chain	Falco rule 偵測 desktop app process spawn 異常子程序 + outbound callback、補簽章驗證之外的 runtime 行為層
Log4Shell CVE-2021-44228	Falco rule 偵測 JNDI lookup 觸發的 outbound LDAP / DNS、補 Trivy image scan 之外的 runtime detection
SolarWinds 2020 Sunburst	合法簽章 binary 但 runtime 行為異常（process tree / outbound C2 / 異常 file access）、Falco rule + Talon containment 是最後一層
Snowflake 2024 Credential Abuse	對照啟示：Falco 主場是 host / container runtime、cloud-native data warehouse 行為偵測要走 SIEM + 平台層 audit、非 Falco 範圍
Detection Engineering Lifecycle (section)	Falco rule + macro + list 走 propose → staging tune → promote → review 的工程 lifecycle、不是 ConfigMap 直改
Alert Fatigue and Signal Quality (section)	Falco rule priority 階梯（新規則先 Informational、staging 觀察 48hr、再 promote Warning / Critical）是 alert fatigue 的工程化解法

下一步路由

上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle、Detection to Response Routing
平行：Cilium Tetragon、Datadog Security、Lacework、Prisma Cloud
下游：Splunk / Elastic Security / Google Security Operations（Falco alert 進 SIEM 做 cross-source correlation）
跨類：Trivy / Syft & Grype（image scan + SBOM、跟 runtime detection 構成 supply chain 縱深）、Wiz / CrowdStrike Falcon CS（商業 CNAPP runtime 對照）
跨模組：8 事故處理 vendor 清單（Falco notable alert → IR routing）、Supply Chain Integrity（artifact trust 跟 runtime detection 的縱深關係）
官方：Falco Documentation、Falco Rules Repository

Cilium Tetragon

Mon, 18 May 2026 00:00:00 +0000

Tetragon 是 Cilium 旗下的 eBPF-based runtime security + enforcement 元件、Isovalent 主導、2024 年起在 CNCF 屬 Incubating 階段。跟 Falco 的核心差異在於 偵測 vs 偵測 + 可 enforce — Falco 預設 alert-only、Tetragon 設計支援 kernel-level inline enforcement（直接 kill process、override syscall return value）；對 K8s heavy + 已用 Cilium CNI 的環境、Tetragon 把 network policy + process policy 收進同一個 eBPF 生態。

服務定位

Tetragon 的核心定位是 eBPF 為基底的 runtime observability + enforcement、TracingPolicy CRD 是 first-class concept — 一份 YAML 同時描述 要觀察什麼 syscall / kprobe / tracepoint 跟 觀察到後要不要 enforce。底層 hook 點包括 syscall entry/exit、kprobe（任意 kernel function）、tracepoint（穩定 kernel event）、uprobe（user-space function），enforcement action 包括 Sigkill（kill process）、Override（override syscall return value）、NotifyEnforcer、Post（送 event 出 plane）。

跟 Falco 比、Falco rule 用 Sysdig filter syntax、Tetragon 用 K8s CRD + JSON schema、對 K8s native 模型更貼近；Falco 主走 alert、Tetragon 主走 alert + enforce；Falco 對非 K8s VM-heavy 場景更 mature。跟 Datadog Cloud Workload Security 比、Datadog 是 SaaS-only + per-host 計費、Tetragon 是 OSS Apache 2.0 + 自管 + Isovalent Enterprise 付費版可選。跟 Prisma Cloud Defender 比、Prisma 是 CSPM/CWPP 一體化平台、Tetragon 專注 runtime + 跟 Cilium L3-L7 network policy 同 plane。

關鍵張力：eBPF inline enforcement 的爆炸半徑 ↔ 偵測即時性。在 kernel-level 直接 kill process 比 userspace agent 更難 bypass、但 TracingPolicy 寫錯（match 太寬）可能誤殺合法 workload、且回退路徑只能改 CRD 再 reload。要看清楚自己 能不能承擔 enforcement 規則錯誤的 blast radius、再決定哪些 policy 進 enforce、哪些只 observe。

本章目標

讀完本頁、讀者能判斷：

Tetragon 在 K8s runtime stack 中承擔哪一段（process visibility / file access / network syscall / enforcement）、哪些要外接（Falco for VM-heavy、SIEM for log aggregation）
TracingPolicy 的 ownership 設計（誰寫 CRD、enforcement action 誰簽核、staging vs production rollout）
Observe vs Enforce 的階段化決策、什麼樣的 policy 適合 inline kill、什麼樣的應該停在 alert
何時用 Tetragon、何時走 Falco / Datadog CWS / Prisma Defender 的取捨

最短判讀路徑

判斷 Tetragon deployment 是否健康、最少看四件事：

TracingPolicy 治理：CRD 是否走 Git + PR review、enforcement action（Sigkill / Override）是否需額外簽核、staging cluster 是否先跑 24-48hr 觀察 false positive 才 promote production
跟 Cilium 整合深度：Hubble flow + Tetragon process event 是否同 plane export、Pod identity 是否在 process event 自動 enrich、跟 Cilium NetworkPolicy 是否雙層 enforcement 設計
Enforcement coverage 分層：哪些 policy 處於 observe-only（log JNDI lookup / setuid abuse / unexpected outbound）、哪些升到 enforce（kill known exploit pattern）、升級條件是什麼
Event export pipeline：Tetragon event 是否進 SIEM（OpenTelemetry / JSON log → Splunk / Elastic）、是否跟 Detection Coverage and Signal Governance 邊界一致

四件事任一缺失、就是 runtime security 邊界的待補項目。

日常操作與決策形狀

TracingPolicy CRD：Tetragon 的 first-class concept、一份 YAML 描述 hook 點 + match selector + enforcement action。Hook 點包含 syscall（最穩定但 surface 廣）、kprobe（任意 kernel function、版本相依）、tracepoint（穩定 kernel event、首選）、uprobe（user-space function、低層用）。Match selector 支援 K8s namespace / pod label / container image、process credentials（UID / GID / capabilities）、parent process。Production rule 用 pod label selector + 具體 syscall name + 額外 process credentials 條件、避免 cluster-wide 寬鬆 match 誤殺。

kprobe / tracepoint / syscall hook 的選擇：tracepoint 是 kernel 公開穩定介面、跨版本不變、首選；kprobe 可 hook 任意 kernel function 但跟 kernel build 緊綁、kernel upgrade 後可能要重寫；raw syscall 適合 audit 整類 syscall（如全部 execve）但量大、需要 in-kernel filter 控成本。

Process credentials tracking：Tetragon 從 process exec 開始 track UID / GID / capabilities / namespace、偵測 privilege escalation（setuid abuse、capabilities drift、container escape）是 first-class use case。跟 audit log 比、credentials drift 是 狀態變遷、不是單一事件、更能 surface lateral movement 早期訊號（process 開始時 UID 1000、跑到一半變 0 是異常）。

Pod identity correlation：Tetragon 在 K8s 環境會自動把 process event enrich K8s metadata（namespace / pod name / container image / service account）、不用後處理 join；event schema 跟 Hubble flow 同根、可在 Hubble UI 看 某 Pod 的 network flow + process event 同 timeline。

跟 Cilium NetworkPolicy 雙層 enforcement：Cilium 控 network ingress / egress / L7 HTTP、Tetragon 控 process / syscall / file access。雙層設計的意義是 — network layer 擋不住的（如 process 內部 lateral movement、container escape syscall）由 process layer 補上；process layer 漏的（如合法 process 突然 outbound 異常 destination）由 network layer 補上。對 supply chain 攻擊特別有效、攻擊鏈通常跨 malicious process spawn + outbound C2。

Event export 跟 SIEM 整合：Tetragon event 預設走 JSON log 到 stdout、可走 OpenTelemetry exporter 進 collector pipeline、再 fanout 到 Splunk / Elastic Security / Google Security Operations。在 SIEM 端做跨來源 correlation（process event + IdP audit + cloud control plane）是 production 標配、不可只看 Tetragon 自家視圖。

Observe → Enforce 階段化：TracingPolicy 通常 先進 observe-only、跑 1-2 週收 baseline、確認 false positive 可控、再加 enforcement action 進 staging cluster、staging 觀察 24-48hr 才 promote production。對應 Detection Engineering Lifecycle 的章節原則 — runtime enforcement 不是 console 直改、是 detection content lifecycle。

核心取捨表

取捨維度	Cilium Tetragon	Falco	Datadog CWS	Prisma Cloud Defender
偵測技術	eBPF（kprobe / tracepoint / syscall / uprobe）	eBPF + kernel module 兩種 driver	eBPF agent	eBPF + kernel module
Enforcement	內建（Sigkill / Override syscall return）	預設 alert-only（plugin 可擴 response）	自動 response（kill / isolate、SaaS 控）	內建（block process / file / network）
規則語言	K8s CRD（TracingPolicy YAML）	Sysdig filter syntax（YAML rule）	Datadog Security Rules（JSON / UI）	Prisma Runtime Rules（UI / JSON）
計費 / 授權	OSS Apache 2.0、Isovalent Enterprise 付費	OSS Apache 2.0、Sysdig Secure 付費	SaaS per-host	商業 per-defender
K8s native	強 — Pod identity 自動 enrich、跟 Cilium 同源	中 — K8s metadata 需 audit endpoint	強 — Datadog Agent 已熟	強 — Prisma 平台一體
Network policy	跟 Cilium L3-L7 雙層（同 plane）	無 — 純 process / file	無 — 跟 Datadog Network 分離	內建 micro-segmentation
VM / 非 K8s	弱 — Linux only、K8s-first	強 — VM / bare metal mature	中 — 跨環境同 agent	強 — VM / serverless / container 全覆蓋
部署模型	Self-hosted DaemonSet（K8s）	Self-hosted DaemonSet / VM agent	SaaS	商業 self-hosted + SaaS console
適合場景	K8s heavy + 已用 Cilium + 要 inline enforce	VM-heavy / K8s 混合、需要 mature alert ecosystem	Datadog 已用、要 unified observability	多雲 CSPM/CWPP 一體化、合規驅動
退場成本	中 — TracingPolicy CRD 跨 cluster 可移植	中 — Falco rule 跟 Sigma 可互轉	高 — SaaS lock-in	高 — 商業平台 lock-in

選 Tetragon 的核心訴求：K8s heavy + 已用 Cilium CNI + 想要 kernel-level inline enforcement + OSS 免授權成本、且有 SRE / security team 能維護 TracingPolicy CRD lifecycle。VM-heavy 或 K8s 但用其他 CNI 走 Falco 更划算。

進階主題

Inline enforcement 的 blast radius 設計：Sigkill 直接 kill 觸發 process、Override 改寫 syscall return value（讓 process 以為成功但實際沒做）— 兩者都在 kernel-level、攻擊者很難 bypass、但寫錯規則的 blast radius 是 整個 cluster 內 match 到的 process 全死。實務治理：enforcement action 規則進 GitOps、PR 需 security + SRE 雙簽、staging cluster 跑 namespace-scoped 規則先驗證、production rollout 走 canary namespace 再擴散。

Process credentials drift detection：track UID / GID / capabilities 變遷、偵測 setuid abuse（process 從 uid 1000 變 0）、capabilities 突然新增（特別是 CAP_SYS_ADMIN / CAP_NET_ADMIN）。對 lateral movement 早期警報是 first-class signal — 攻擊者拿到初始 access 後通常要 escalate privilege、credentials drift 是必經訊號。配對 SolarWinds 2020 Sunburst 的 lesson：簽章驗證通過但 runtime 行為異常需 runtime credentials + process behavior 雙重 baseline。

跟 Cilium L3-L7 雙層 enforcement：典型 supply chain 攻擊鏈 — malicious dependency loaded → process spawn → C2 outbound、network layer 擋 outbound（Cilium NetworkPolicy 限制 egress destination）、process layer 擋 process（Tetragon KillerAction kill 異常 spawn）。雙層任一通則攻擊鏈中斷。對應 3CX 2023 Desktop App Supply Chain 的 case shape。

跟 SBOM / image signing 整合 baseline：Tetragon 偵測 runtime 行為偏離 baseline、SBOM / image signing 控 build-time 信任、合在一起是 trusted artifact + verified runtime behavior 雙重保障。runtime 行為 baseline 通常從 SBOM 列出的合法 process / syscall set 出發、deviation 進 alert。

Isovalent Enterprise：商業版加值在 multi-cluster management、policy 集中下發、support SLA、跟 Isovalent Hubble Enterprise / Cilium Service Mesh Enterprise 整合。OSS 版本核心功能完整、Enterprise 主要解 多 cluster 大規模管理 跟 企業 support、不是 feature gating。

排錯與失敗快速判讀

TracingPolicy 誤殺合法 workload：match selector 太寬、cluster-wide 沒加 namespace / pod label 條件 — 改 namespace-scoped + 加 process credentials 額外條件、staging 跑 48hr 再 promote
kprobe rule kernel upgrade 後壞：hook 的 kernel function 改名或 signature 變 — 改用 tracepoint（穩定介面）、kprobe 進 staging 版本相依測試
Event volume 爆炸 / SIEM ingestion cost 飆：raw syscall hook 沒做 in-kernel filter、所有 execve 都進 event — 加 in-kernel filter（按 pod label / process name），讓 filter 在 eBPF 端做、不要事後 drop
Inline enforcement 規則錯誤 blast radius 太大：production 直接上 Sigkill 沒走 staging — enforcement action 規則一律先 observe-only 1 週、staging cluster 24-48hr、canary namespace、才 production
跟 Cilium NetworkPolicy 重疊或衝突：同一個 attack pattern 被 network + process 同時阻擋、log 重複、誤判 — 設計時雙層各管 互補面（network 管 destination、process 管 process spawn）、不重複管同一面
non-K8s workload 進不來：Tetragon DaemonSet 只在 K8s 跑、VM / bare metal 不支援 — VM-heavy 環境改走 Falco、K8s + VM 混合走雙 stack
Pod identity enrich 不全：某些 process event 缺 namespace / pod name — 通常是 process 在 pod sandbox 啟動前 spawn、或 short-lived process 太快結束、調 Tetragon 的 process cache lifetime + K8s API server 連線健康

何時改走其他服務

需求形狀	改走
VM-heavy / 非 K8s 為主	Falco
Datadog observability 已用	Datadog Security（Cloud Workload Security）
多雲 CSPM/CWPP 一體化、合規驅動	Prisma Cloud Defender（商業）
SIEM 偵測為主、不需 inline kill	Splunk / Elastic Security
Endpoint EDR（user laptop / VDI）	CrowdStrike Falcon / Microsoft Defender for Endpoint
偵測覆蓋率治理	7.13 偵測覆蓋率與訊號治理
Incident routing	8 事故處理 vendor 清單

不在本頁內的主題

TracingPolicy CRD 完整欄位 reference 跟 kprobe / tracepoint 寫法 cookbook
Cilium NetworkPolicy 寫法（屬 network 治理、跨章節）
eBPF kernel programming 內部原理跟 verifier 限制
Isovalent Enterprise 跟 Cilium Service Mesh 商業整合細節
Hubble UI 操作（屬 observability 視角、跨章節）

案例回寫

Tetragon 在 07 案例庫沒有直接 vendor-level 事件、但所有 runtime detection + supply chain case 都是 eBPF inline enforcement 的對照：

案例	跟 Tetragon 的關係（對照啟示）
Log4Shell CVE-2021-44228	TracingPolicy 可 hook JNDI lookup 相關 syscall、配 `Sigkill` 直接 kill exploit process、比 userspace WAF 更難 bypass
SolarWinds 2020 Sunburst	process credentials drift detection 對 lateral movement 早期警報、簽章驗證通過但 runtime 行為異常需 runtime baseline 補位
3CX 2023 Desktop App Supply Chain	偵測 desktop app 異常 outbound、Tetragon 抓 process + Cilium NetworkPolicy 同層擋 destination、雙層 enforcement 中斷攻擊鏈
Detection Engineering Lifecycle (section)	TracingPolicy CRD 走 GitOps + PR review + staging tune + canary rollout、inline enforcement 不可 console 直改
Alert Fatigue and Signal Quality (section)	observe-only 階段先收 baseline、in-kernel filter 控 event volume、enforcement 只升給高 confidence pattern、避免 alert / log 雙重 fatigue

下一步路由

上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
平行：Falco、Datadog Security
下游：Splunk / Elastic Security（Tetragon event 進 SIEM 做跨來源 correlation）
跨類：Cloudflare WAF（network edge 擋 + process 層補位）、HashiCorp Vault（credentials drift 配 secret rotation）
跨模組：8 事故處理 vendor 清單（runtime alert → IR routing）、4 observability（Hubble + Tetragon event pipeline 共用）
官方：Tetragon Documentation、Cilium Project