
Mục lục bài viết 9 phần
NetworkPolicy manifest được apply thành công chưa chứng minh traffic đã bị chặn đúng. Kết quả còn phụ thuộc CNI, selector, direction, DNS và thời điểm policy được lập trình. Bài đo cần corpus allow/deny hai chiều, quan sát endpoint thực và kiểm tra propagation khi pod hoặc label thay đổi.
Bài viết giúp bạn
- NetworkPolicy cần chứng minh điều gì?
- Topology và trust boundary
- Semantics và biến số phải kiểm soát
NetworkPolicy cần chứng minh điều gì?
#Kubernetes NetworkPolicy mô tả cách pod được phép giao tiếp với network entity. Policy là additive; một connection cần được phép ở phía egress của source và ingress của destination khi cả hai phía bị isolate. Một manifest “allow” không có thứ tự ưu tiên kiểu firewall rule truyền thống.
Kubernetes API chấp nhận NetworkPolicy không bảo đảm cluster networking plugin thực thi nó. Tài liệu Kubernetes yêu cầu network plugin hỗ trợ NetworkPolicy. Vì vậy test phải xác nhận CNI/version/capability, không chỉ kubectl get networkpolicy.
Câu hỏi trọng tâm: traffic bắt buộc có qua; traffic ngoài ý định có bị chặn; policy có áp đúng pod mới/label mới; DNS và control dependency có còn hoạt động; và data plane có hội tụ trong ngân sách khi policy thay đổi.
Topology và trust boundary
#Tạo ít nhất ba namespace: client, app và restricted; mỗi namespace có pod được label rõ và pod đối chứng. Thêm CoreDNS, external service lab, service ClusterIP/headless và node khác nhau. Với multi-cluster hoặc service mesh, tách NetworkPolicy L3/L4 khỏi mTLS/authorization layer.
Đặt probe ở source pod, destination pod và node/CNI telemetry. Gắn request ID, source identity và destination marker. Nếu dùng service, kiểm tra cả service IP và pod IP để phân biệt kube-proxy/eBPF load balancing với policy enforcement.
Không dùng production namespace làm nơi thử deny đầu tiên. Lab phải có đường quản trị độc lập và cơ chế rollback; NetworkPolicy không bảo vệ host network, node traffic hoặc mọi loại entity giống nhau trên mọi CNI.

Semantics và biến số phải kiểm soát
#Khóa Kubernetes version, CNI/version, dataplane mode, kube-proxy mode, IPv4/IPv6, node OS và policy API. Ghi podSelector, namespaceSelector, ipBlock, ports, protocol và policyTypes. Label là input bảo mật; đổi label có thể đưa pod vào hoặc ra khỏi phạm vi.
Empty selector có nghĩa rộng tùy trường. podSelector: {} trong policy chọn mọi pod trong namespace của policy; namespace selector rỗng có phạm vi khác. YAML indentation sai có thể biến kết hợp AND/OR. Review object đã được API server lưu, không chỉ file nguồn.
DNS là dependency thường bị quên khi bật egress default-deny. Cho phép UDP/53 chưa đủ nếu cluster dùng TCP fallback, DoT/DoH nội bộ hoặc DNS ở port/address khác. Kiểm tra cả query/response, timeout và policy đối với CoreDNS endpoints thực.
KPI và chuỗi bằng chứng
#KPI enforcement gồm allow success, deny success, false allow, false deny, propagation delay, stale rule duration và policy error. KPI service gồm DNS latency, connect latency, transaction success, packet loss và restart impact. Với scale, thêm controller/agent CPU, rule count và update backlog.
KPI · Phương pháp · Bằng chứng Allow accuracy · Positive corpus · Request log + capture Deny accuracy · Negative corpus · Timeout/reject + CNI log Propagation delay · Timestamp apply → verdict đổi · API watch + probes Label convergence · Relabel/recreate pod · Endpoint identity + probe DNS continuity · A/AAAA, UDP/TCP query · DNS log + client timing Stale enforcement · Delete policy/pod · Rule/map state + traffic Scale stability · Policy/pod churn · Queue, CPU, p99 convergence
Chuỗi bằng chứng nên nối Git/manifest digest, API object resourceVersion, CNI policy state, endpoint identity, packet outcome và application log. Một timeout ở client không chứng minh policy đã drop; có thể destination down hoặc DNS lỗi.
Ma trận allow/deny thực hành
#Tạo corpus theo source namespace/pod, destination, port, protocol và direction. Mỗi allow cần một near-miss negative: label khác, namespace khác, port sát bên hoặc IPv6 nếu dual-stack.
Source → Destination · Policy intent · Kỳ vọng · Negative control frontend → app:443 · Allow ingress/egress · Transaction pass · frontend → app:8443 deny app → db:5432 · Allow selected labels · Query pass · pod không label deny app → CoreDNS · Allow DNS · UDP/TCP query pass · DNS server ngoài scope deny restricted → Internet · Default deny egress · Không kết nối · Approved proxy allow monitoring → app metrics · Allow namespace+port · Scrape pass · namespace giả deny hostNetwork → pod · CNI-specific · Ghi behavior · Không suy diễn IPv6 pod → IPv6 pod · Theo dual-stack scope · Verdict đúng · IPv4 pass không đủ
Đo TCP, UDP và giao thức thực. ICMP behavior có thể khác và không được NetworkPolicy API mô tả đồng nhất. Không dùng ping pass/fail làm đại diện duy nhất cho application port.
Test propagation, churn và failure
#Apply policy trong khi probe liên tục với sequence ID; đo packet/request cuối cùng trước deny và đầu tiên sau allow. Lặp khi tạo pod mới, relabel, reschedule sang node khác và rolling update CNI. Kiểm tra stale endpoint/rule khi pod IP được tái sử dụng.
Tăng số namespace, pod, policy và label update theo profile production. Không chỉ đo steady state; policy storm trong deployment hoặc GitOps reconciliation có thể làm queue tăng. Gây restart controller/agent và node reconnect trong lab, đo whether fail-open, fail-closed hoặc giữ state cũ theo implementation.
Mọi behavior fail-open/fail-closed phải lấy từ tài liệu CNI/version và được kiểm thử. Không mặc định tất cả plugin giống nhau.

Runbook triển khai default-deny
#Bắt đầu bằng inventory flow và observe-only nếu nền tảng hỗ trợ. Tạo default-deny ingress/egress ở namespace lab, sau đó mở DNS, telemetry và dependency tối thiểu. Apply từng service, chạy positive/negative corpus rồi mới mở rộng. Giữ break-glass namespace hoặc access path đã kiểm thử.
Pass/fail phải yêu cầu không false allow ngoài policy, không false deny luồng bắt buộc, propagation trong budget và visibility đủ để điều tra. Với security-critical path, ưu tiên false allow; với availability-critical path, phải đánh giá trade-off rõ ràng.
- Xác nhận CNI hỗ trợ NetworkPolicy và phiên bản hiện tại.
- Xuất flow inventory, namespace/label/port dependency.
- Chụp baseline DNS, service và external egress.
- Apply default-deny trong namespace lab.
- Mở DNS cả UDP/TCP và dependency bắt buộc.
- Chạy allow corpus và near-miss deny corpus.
- Relabel, recreate và reschedule pod; đo convergence.
- Thử service IP, pod IP, IPv4/IPv6 và external endpoint.
- Theo dõi CNI controller/agent, rule/map và drop log.
- Lưu manifest digest, raw probe, timeline và rollback evidence.
Giới hạn kết luận
#NetworkPolicy là L3/L4 và không thay thế application authorization, service-mesh policy, ingress/WAF hoặc cloud security group. Nó không mặc định lọc mọi traffic node/hostNetwork/control-plane. ipBlock và NAT ordering có thể khác theo plugin/cloud.
Kết quả chỉ áp dụng cho Kubernetes, CNI, kernel, dataplane mode, address family và scale đã thử. Một policy pass trên single-node không chứng minh cross-node hoặc multi-cluster. Không gọi “zero trust” chỉ vì có default-deny.
Khái niệm cần nhớ
#- NetworkPolicy: Kubernetes API object mô tả L3/L4 traffic được phép cho pod.
- Default-deny: Policy cô lập pod khi chưa có allow phù hợp.
- CNI: Plugin/network interface triển khai kết nối và có thể thực thi policy.
- Pod selector: Chọn pod dựa trên label trong namespace của policy.
- Namespace selector: Chọn namespace dựa trên label.
- Additive policy: Nhiều policy hợp lại; không có rule order deny-over-allow chung.
- Propagation delay: Thời gian từ thay đổi control plane tới verdict data plane.
Khái niệm cần nhớ
- DUT / SUT
- Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
- Steady state
- Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
- Pass / fail
- Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo3 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
