防火牆把外面擋住、TLS 把連線加密、image scanner 把已知漏洞抓出來，這些都是容器安全的標準動作。真正難處理的是另一條問題：容器跑起來之後，裡面那支 process 到底做了什麼？讀了哪些檔案、開了哪些 socket、有沒有去動 /etc/shadow 或 nsenter 跳出 namespace？這層可見性在多數 VPS 上仍是黑盒。Tetragon 用 eBPF 把這層補起來，把偵測與阻擋都搬進 Linux 核心，1.7 版在 2026 年 4 月底釋出之後，已經成熟到能單機跑在一臺 VPS 上而不必先架 Kubernetes 叢集。
Tetragon 是 Cilium 旗下的子專案，由 Isovalent 起家、捐進 CNCF，定位是 eBPF-based Security Observability 與 Runtime Enforcement。它跟 Cilium 共用底層機制但完全可以獨立部署，跑在 Debian、Ubuntu 或任何 5.10 以上核心的 Linux 上都行。核心賣點是：傳統 auditd 是事件水龍頭，需要在 user space 大量過濾才看得出名堂；Falco 把規則引擎拉到 user space 處理；Tetragon 把過濾、enrichment、甚至 enforcement 動作全部編譯成 eBPF 程式，直接掛在核心的 kprobe 與 tracepoint 上。
容器內部到底發生什麼，是多數 VPS 的可見性盲區
跑 Docker 的 VPS 管理員多半遇過這種狀況：某天伺服器 CPU 莫名升高，docker stats 顯示某個容器吃滿一顆核心，但裡面到底在做什麼說不清楚。docker logs 只看得到應用程式自己印出的東西，惡意 process 通常不會貼心地寫一行「正在挖礦」。要更深一層，傳統選項只有兩個：在容器裡面裝 strace 或 auditctl 規則。前者效能崩潰，後者吞掉大量 disk I/O 還難解讀。
問題本質是 Linux 把「容器」看成一組 namespace 加 cgroup 的組合，並沒有一個原生的「容器內事件 audit」介面。從主機角度看，容器裡的 process 跟主機上其他 process 沒兩樣，PID 在主機 namespace 裡是另一個數字，syscall 來了就服務。要把「主機 PID 12345 屬於 nginx 容器」這個對應關係加回事件流裡，就需要一個既懂 Linux 又懂容器 runtime 的代理層。
過去這個位置長期被 Falco 佔著。Falco 在 2016 年從 Sysdig 分支出來，2024 年成為 CNCF 畢業專案，產品成熟、規則豐富、社群活躍。它撐起了容器 runtime security 這個類別，沒有理由貶低它。Tetragon 之所以還能切進這個市場，是因為它對「攔截點該放在哪一層」的判斷不一樣。
Falco 不是不夠好，是它把判斷工作交給了 user space
Falco 的架構是：在核心用 eBPF probe（或舊版的 kernel module）抓 syscall 事件，把原始事件透過 ring buffer 送到 user space 的 Falco daemon，daemon 在 user space 跑 rule engine 比對 YAML 規則，命中就觸發 alert。這套設計的好處是規則語言彈性高、寫起來像在寫 SIEM 條件式；代價是高吞吐情境下 user space 要消化大量事件，做不完就丟、或者把 CPU 吃掉一塊。
公開壓測結果差異不小。Falco 自己的 benchmark 在中等工作負載下大約是 1–2% CPU 開銷；獨立第三方測試在高 syscall 吞吐情境下測到 5–10%，主要花在 user space 的解析與規則比對。Tetragon 把這部分搬回核心：用 eBPF map 在核心裡完成 binary 比對、引數過濾、cgroup 限定，事件根本不需要送到 user space 就先被過濾掉。多數公開測試把 Tetragon 的長期 CPU 開銷壓在 1% 以下，2025 年底 SciTePress 的一份比較研究量到 Tetragon 在 CPU 上勝 Falco、在記憶體上略遜於 Falco。
更關鍵的差別在 enforcement。Falco 自身只負責偵測，要做阻擋得搭 Falco Talon 或自己接 webhook 觸發外部動作，反應週期是「偵測 → user space → 外部 process → 做出反應」，整段大概數十毫秒到秒級。Tetragon 可以在 eBPF program 命中規則的當下直接 send SIGKILL 給該 process，或在 syscall 還沒回來之前 override return value 讓那次 syscall 失敗，整個閉環在核心裡完成，延遲在微秒等級。對於攔截「容器裡被植入的程式去讀 /etc/shadow」這類動作，這個差別是「擋下來」跟「事後才知道」的差別。
TracingPolicy 是 Tetragon 學習曲線的重心
Tetragon 暴露給使用者的主要介面叫 TracingPolicy，是一份 YAML，描述要在核心哪個 hook 點掛 eBPF program、要看什麼引數、命中什麼條件、要做什麼動作。一份最小化的 policy 大概長這樣：
1 | apiVersion: cilium.io/v1alpha1 |
這份 policy 的意思是：在 security_file_open 這個 LSM hook 上掛 probe，凡是路徑開頭是 /etc/shadow 或 /root/.ssh/ 的開檔行為，直接送 SIGKILL 給發起者。注意這裡選的是 security_file_open 而不是 openat syscall——後者每秒會被叫上萬次、前者只在真正進到 VFS 開檔流程時觸發，filter 成本低很多。
matchBinaries 可以把這個規則進一步限縮到只對特定執行檔生效；matchNamespaces 可以限定只看某個容器的 PID/UTS namespace；matchCapabilities 可以鎖定只有有 CAP_SYS_ADMIN 的 process 才被攔截。這些 selector 全部編譯進 eBPF program 裡跑，意味著「找出特權容器存取敏感檔的瞬間」可以做到接近零誤報的精準偵測。
實務上的建議是不要從零自己寫 policy。Tetragon 官方倉庫有 examples/tracingpolicy/ 目錄，cilium/tetragon 在 GitHub 上的 policy-library 目錄收錄了監控 sudo 提權、偵測 reverse shell、攔截 kubectl exec 進容器、防止寫入 /proc/sys 等等的範本。直接拿來改、不要自己土法煉鋼是最省時的路。
不靠 Kubernetes 也能跑：單機 VPS 的部署方式
Tetragon 文件大半在講 Kubernetes 安裝，但實際上它可以當成一支獨立 daemon 跑。在一臺裝有 Docker 與 5.10 以上核心的 VPS 上，最低限度的指令是：
1 | docker run --name tetragon --rm -d \ |
--privileged 是必要的，因為要 load eBPF program 並掛上 kprobe。--pid=host 與 --cgroupns=host 讓 Tetragon 看得到主機完整的 process 與 cgroup 拓撲，這樣它才能把事件回填上「這個 PID 屬於哪個容器」的資訊。/sys/kernel/btf/vmlinux 這個 mount 是給 BTF 用的，eBPF program 靠它做 CO-RE（Compile Once, Run Everywhere），不必依賴開發機跟正式機核心完全一致。
policy 直接丟進 /etc/tetragon/tracing-policies/，daemon 啟動時會掃整個目錄載入。要在運行中加新 policy 也可以用 tetra CLI 從 grpc 動態載入。事件預設輸出成 JSON Lines 寫進 /var/log/tetragon/tetragon.log，要轉給 SIEM 直接接 Vector 或 Fluent Bit 把它推到下游就好。
需要留意的是 BPF LSM 相關的 enforcement 動作（例如 file open 攔截）需要核心開啟 CONFIG_BPF_LSM 並在 /etc/default/grub 加 lsm=bpf。Debian 13、Ubuntu 24.04 預設都符合，CentOS Stream 9 系列需要自己啟用。沒有開 BPF LSM 時 Tetragon 仍能做偵測，只是 SIGKILL 之外的精細 enforcement 動作會降級。
適合放進哪一臺機器、不適合放進哪一臺
Tetragon 的甜蜜點是「跑著面向公網應用、又無法完全信任應用程式碼安全的 VPS」。電商後端、Webhook 接收器、表單轉發、社群媒體機器人這類場景一旦被植入 webshell，傳統監控的反應點通常是「奇怪流量被注意到」，而那時已經晚了。把監控 connect() 到非預期 IP、寫入 /tmp/*.sh 後立刻 execve 之類的行為策略掛上去，能在被植入的下一秒就觸發告警甚至直接 KILL。
不適合的是「規模小到不會被當目標」的個人實驗 VPS。Tetragon 本身輕量，但 policy 設計與事件處理需要時間經營，沒有事件需要應對時這套機制是純成本。同樣道理，跑 LAMP + WordPress 又只開 80/443 的個人站，先做好 Fail2ban、CrowdSec、自動更新可能比導入 Tetragon 更划算。
把 Tetragon 想成「容器內的 IDS/IPS」是正確的心智模型。它不取代防火牆、不取代 image scanner、不取代 WAF——它補的是這些工具都看不見的那一層：應用程式自己開始做奇怪事的瞬間。對於把多個容器塞在同一臺 VPS、又跑開放給外部使用者的服務的場景，這個觀察點過去只能靠商業 EDR 取得，現在用一支 open source binary 加幾份 YAML 就能架起來。
正在為一批面向公網的應用挑伺服器、又希望從第零天就把執行期安全納入規劃，可以參考 NCSE Network 的臺灣 VPS 服務——使用 Intel Gold CPU 與 NVMe SSD、機房設在是方電訊，預設核心版本支援 eBPF 完整功能，跑 Tetragon、Cilium 之類的 kernel-level 工具不需要額外調整。
