Kubernetes Admission Policy & Runtime Defense với Kyverno và Falco

Image scan và threat model bảo vệ trước khi deploy. Admission policy bảo vệ tại moment of truth khi workload vào cluster. Runtime monitor là camera giám sát cho mọi việc xảy ra sau đó.

Ba lớp bảo vệ trong cluster

Lớp	Vai trò	Tool
Pre-admission	Lint, scan image, sign verify	Trivy, Cosign
Admission	Chặn workload vi phạm policy	Kyverno, OPA Gatekeeper
Runtime	Phát hiện hành vi bất thường, network policy	Falco, Cilium Tetragon, NetworkPolicy

Kyverno vs OPA Gatekeeper — chọn cái nào?

• Kyverno: viết policy bằng YAML thuần, ngắn, dễ học. Hỗ trợ mutate, generate, verifyImages keyless. Phù hợp đa số trường hợp.
• OPA Gatekeeper: viết bằng Rego, mạnh cho logic phức tạp. Phù hợp khi đã có hệ sinh thái OPA (API gateway, microservice authz).

Khuyến nghị: bắt đầu Kyverno cho cluster mới. Migration giữa hai cái sau này không quá khó vì policy chính là declarative.

Baseline policy nên có

1. Apply Pod Security Standards: restricted ở namespace ứng dụng.
2. Chặn pod chạy với privileged: true, hostNetwork, hostPID.
3. Yêu cầu image từ registry nội bộ (allowlist).
4. Yêu cầu resources.requests/limits cho mọi container.
5. Yêu cầu label chuẩn (team, env, cost-center) cho cost tracking và IR.
6. Verify Cosign signature trên image production.

Triển khai an toàn: Audit → Fix → Enforce

Đừng bao giờ apply validationFailureAction: Enforce ngay lập tức trên cluster đang chạy. Quy trình tham khảo:

1. Apply policy với validationFailureAction: Audit.
2. Đo violation qua Kyverno PolicyReport CRD trong 1-2 tuần.
3. Tạo ticket fix cho từng workload vi phạm, có owner.
4. Khi violation = 0 trên môi trường staging, đổi sang Enforce ở dev → staging → prod.

Có quy trình exception rõ ràng: workload đặc biệt (vd: privileged debug pod) phải có annotation lý do, hết hạn, owner.

Network policy default-deny

Mỗi namespace ứng dụng nên bắt đầu với một policy "deny all", sau đó mở dần theo nhu cầu thật:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

Sau đó mở từng kết nối cần: app → DB, app → service mesh, egress đến API external qua egress gateway. Với Cilium, có thể policy ở L7 (HTTP path, gRPC method, Kafka topic) — mạnh hơn nhiều so với chỉ port/IP.

Falco: runtime detection cho container

Falco hook vào kernel (eBPF hoặc kernel module) để quan sát syscall. Một số rule giá trị nhất:

• Shell trong container: shell_in_container. Production hiếm khi có lý do hợp lệ để có shell.
• Sửa file binary trong runtime image (sign of compromise).
• Outbound connection bất thường tới IP/domain ngoài allowlist.
• Đọc file nhạy cảm như /etc/shadow, kubeconfig.
• Mount sensitive path như /var/run/docker.sock, /proc.

Stream Falco event sang Slack/PagerDuty cho rule severity cao và sang SIEM cho phân tích sau.

Cilium Tetragon: hardware-assisted, low-overhead

Tetragon dùng eBPF tương tự nhưng tối ưu hiệu năng cho cluster lớn, có thể enforce chứ không chỉ detect (vd: kill process khi syscall vi phạm). Phù hợp khi cần in-kernel response time.

Khi alert kêu — workflow IR ngắn

1. Triage trong 15 phút: phân loại true/false positive theo severity.
2. Cô lập pod bằng NetworkPolicy chặn egress, KHÔNG xoá ngay (mất evidence).
3. Lấy snapshot: kubectl debug, dump memory, copy log, xuất audit trail.
4. Rotate credential mà pod có thể đã chạm: ServiceAccount token, secret mount.
5. Sau khi điều tra: viết post-mortem blameless, thêm Falco rule mới nếu cần.

Kết luận

Bảo vệ Kubernetes không phải chỉ là RBAC và firewall. Cần ba lớp: pre-admission (image scan, sign), admission (Kyverno), runtime (Falco/Tetragon, NetworkPolicy). Bắt đầu với baseline policy ở chế độ audit, dần enforce, kết hợp Falco với SIEM — đó là cấu hình đủ chắc cho phần lớn cluster production năm 2026.