Một node production điển hình năm 2024 trông thế này: auditd ghi syscall theo yêu cầu compliance, Falco chạy DaemonSet bắn alert lên Slack, thêm một agent EDR thương mại do team security cắm vào. Ba agent cùng hook syscall, ba định dạng event, ba pipeline log. Khi CPU node tăng bất thường, việc đầu tiên phải làm là... tắt bớt agent để xem thằng nào gây ra.
Nếu team bạn đang ở tình cảnh đó, câu hỏi hợp nhất về một agent eBPF không còn là "có nên thử" mà là "chuyển thế nào cho đỡ đau". Bài này đánh giá thẳng phương án Tetragon — kèm phần chi phí dữ liệu mà các bài giới thiệu thường lờ đi.
2026: eBPF hết là đồ chơi thử nghiệm
Hai mốc đáng chú ý. Một, AWS EKS chọn Cilium làm CNI mặc định từ 2025 — khi cloud provider lớn nhất đặt eBPF vào đường mặc định của managed Kubernetes, tranh luận "eBPF có production-ready không" coi như khép lại. Hai, Tetragon 1.4 (tháng 2/2026) hoàn thiện mảng policy authoring — điểm yếu lớn nhất của nó so với bộ rule trưởng thành của Falco.
Điều đó nghĩa là bài toán không còn là công nghệ, mà là vận hành: một agent Tetragon có thay được cả Falco (detection) lẫn auditd (audit trail) không, và đổi lại bạn phải trả gì.
Falco quan sát, Tetragon chặn
Khác biệt cốt lõi không nằm ở "eBPF hay không" — Falco từ lâu cũng có driver eBPF. Khác biệt nằm ở vị trí đứng trong luồng thực thi:
| Falco | Tetragon | |
|---|---|---|
| Cơ chế | Quan sát syscall stream, đánh giá rule ở userspace | Hook trực tiếp trong kernel (kprobe/tracepoint), lọc và enforce in-kernel |
| Khi phát hiện vi phạm | Bắn alert, việc xử lý là của hệ thống khác | Có thể SIGKILL process trước khi syscall thực thi |
| Rủi ro bỏ sót | Event có thể bị drop khi tải cao, alert đến sau khi việc đã xảy ra | Enforce inline, không có khoảng trễ detect-rồi-mới-phản-ứng |
| Vai trò tự nhiên | Detection + alerting | Detection + enforcement + audit trail |
Nói gọn: Falco là camera an ninh, Tetragon là camera kiêm cửa khóa. Với auditd, Tetragon phủ luôn phần audit trail — process exec, file access, network connection — với ngữ cảnh Kubernetes (pod, namespace, label) mà auditd không bao giờ có. Đó là lý do một agent thay được hai.
Cái giá của enforce inline: policy sai thì kill nhầm process production, ngay trong kernel, không có chỗ để "review alert rồi tính". Quy trình đúng là chạy policy ở chế độ observe vài tuần, xem event, rồi mới bật Sigkill.
Viết TracingPolicy thực tế
Ba tình huống hay gặp nhất. Thứ nhất, bắt (và chặn) shell exec trong container production — kịch bản kinh điển của reverse shell:
apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
name: block-shell-exec
namespace: production
spec:
kprobes:
- call: "sys_execve"
syscall: true
args:
- index: 0
type: "string"
selectors:
- matchArgs:
- index: 0
operator: "Postfix"
values: ["/bin/sh", "/bin/bash", "/bin/dash"]
matchActions:
- action: Sigkill
Process gọi execve với /bin/bash trong namespace production bị kill trước khi shell kịp chạy. Không phải alert sau 2 giây — là không bao giờ chạy.
Thứ hai, chặn ghi file vào /etc (bảo vệ /etc/passwd, /etc/shadow, cấu hình sudo): hook security_file_permission với selector Prefix: /etc và điều kiện quyền ghi. Thứ ba, phát hiện kết nối ra ngoài bất thường: hook tcp_connect, dùng selector NotDAddr loại trừ dải IP nội bộ và các endpoint hợp lệ — mọi kết nối ra IP lạ từ workload không được phép egress sẽ hiện nguyên hình, kèm tên pod và binary khởi tạo.
Điểm mạnh của mô hình selector: lọc xảy ra trong kernel. Event không khớp bị vứt ngay tại chỗ, không tốn công serialize lên userspace. Đây chính là chìa khóa cho phần tiếp theo.
Chi phí thật: 180GB event mỗi ngày
Đây là phần các bài "getting started" không nói. Một hệ thống thực tế cỡ 4.200 node sinh khoảng ~180GB event mỗi ngày — sau khi đã dedup. Nhân với retention 90 ngày cho compliance, bạn đang nhìn vào ~16TB dữ liệu nóng chỉ riêng runtime security. Chi phí lưu trữ và pipeline, chứ không phải CPU overhead của eBPF, mới là rủi ro chính của việc hợp nhất.
Ba nguyên tắc rút ra:
- Filter từ trong kernel, không phải ở collector. Mặc định Tetragon có thể xuất toàn bộ process exec event — trên node chạy nhiều cron job hay CI runner, đó là thác lũ. Dùng selector trong TracingPolicy và cấu hình
--enable-process-cred/export filter để chỉ đẩy lên thứ bạn thật sự sẽ đọc. - Tách hai loại dữ liệu ngay từ đầu. Security alert (ít, quý, giữ lâu) đi một đường; audit trail (nhiều, rẻ, truy vấn hiếm) đi đường khác — object storage, nén, lifecycle policy. Đổ chung vào một index Elasticsearch là cách nhanh nhất để hóa đơn nổ.
- Thiết kế retention trước khi bật agent, không phải sau. "Log hết rồi tính sau" với runtime event là quyết định trị giá nhiều nghìn đô mỗi tháng. Ngồi với team compliance chốt: cái gì cần 90 ngày, cái gì 7 ngày là đủ.
Kiến trúc tham chiếu: một stack eBPF, một đường ra
Khi đã có Cilium làm CNI, mảnh ghép hợp lý là gom cả ba lớp observability về cùng họ eBPF, đổ về một điểm:
flowchart LR
subgraph Node["Mỗi node"]
C[Cilium / Hubble<br/>network flows] --> OC
T[Tetragon<br/>runtime security] --> OC
B[Beyla / OBI<br/>app tracing] --> OC[OTel Collector<br/>DaemonSet]
end
OC -->|alert| S[SIEM / Alerting]
OC -->|audit trail| O[Object storage<br/>rẻ, nén, retention dài]
OC -->|trace + flow| BE[Observability backend]
OpenTelemetry Collector đứng giữa làm tầng filter, routing và fan-out — nơi bạn thực thi ba nguyên tắc ở trên mà không phải sửa từng agent. Một node, một họ công nghệ, một pipeline. So với cảnh ba agent giẫm chân nhau đầu bài, riêng phần giảm surface để debug đã đáng tiền.
Vậy có nên bỏ Falco?
Nếu bạn đã chạy Cilium và đang nuôi cả Falco lẫn auditd: có, lộ trình hợp nhất về Tetragon là hợp lý, miễn là đi qua giai đoạn observe-mode đủ dài và làm bài toán dữ liệu trước. Nếu bạn không dùng Cilium và đầu tư của team vào bộ rule Falco đã sâu, giá trị chuyển đổi mỏng hơn nhiều — Falco vẫn là công cụ detection tốt.
Nhưng đừng tự lừa mình về bản chất quyết định. Chọn Tetragon không phải là chọn một Falco nhanh hơn — mà là chuyển từ triết lý "phát hiện rồi phản ứng" sang "chặn tại chỗ trong kernel". Công cụ nào cũng học được; thứ cần thay đổi là thói quen coi runtime security như một luồng alert để đọc sáng thứ Hai.