Kiểm thử Kubernetes NetworkPolicy: default-deny, policy churn và fail-closed

Kubernetes NetworkPolicy diễn tả cách pod được phép giao tiếp, nhưng việc thực thi phụ thuộc network plugin hỗ trợ. Bài đo phải trả lời: flow hợp lệ có đi được không; flow bị cấm có bị chặn không; thay đổi object/label được áp dụng trong bao lâu; và failure của controller/agent/node có tạo fail-open không.

Các NetworkPolicy áp dụng cho một pod có hiệu lực cộng dồn: tập allow là hợp của các rule, không có thứ tự ưu tiên deny. Một kết nối pod–pod cần được cả egress phía nguồn và ingress phía đích cho phép nếu hai hướng bị cô lập. Default-deny không ghi đè một allow policy khác.

Policy test phải gồm positive và negative case. Chỉ kiểm ứng dụng hoạt động sau khi áp policy dễ bỏ qua đường lateral movement ngoài ý muốn. Đồng thời, chỉ quét deny có thể bỏ qua việc policy chặn DNS, health check hoặc dependency hợp lệ.

Tạo ít nhất ba namespace: client, application và shared-services. Trong mỗi namespace có pod với label thay đổi được, service ClusterIP và pod đích trực tiếp. Bổ sung DNS, ingress/egress gateway, external endpoint và một node dành cho fault injection. Traffic generator phải tạo TCP, UDP và kết nối sống lâu.

Khóa Kubernetes version, CNI/plugin version, kube-proxy hoặc dataplane mode, dual-stack, service mesh, hostNetwork và policy API. Lưu manifest, EndpointSlice, labels, routes/rules/eBPF map liên quan cùng thời điểm. Với managed service, ghi rõ tính năng provider và giới hạn tài liệu.

Biến policy gồm policyTypes, podSelector, namespaceSelector, kết hợp selector, ports/protocol, IPBlock và default-deny. Biến workload gồm label churn, pod restart, scale-out, reschedule và connection tracking. Biến platform gồm CNI agent restart, controller outage, node partition, rule capacity và API latency.

Phải chốt xử lý kết nối đã tồn tại khi policy đổi. Một số dataplane có thể giữ established flow khác với new flow. DNS egress cần kiểm UDP/TCP 53 hoặc cơ chế resolver thực tế; không giả định chỉ một transport. Với dual-stack, chạy IPv4 và IPv6 riêng.

Timeout không tự động chứng minh policy drop: có thể do DNS, route hoặc server. Cần correlate counter/log của dataplane và thử control flow. Nếu plugin không cung cấp log, dùng packet capture hai đầu và probe có request ID.

• KPI: Allow success · Phương pháp: Request có ID · Bằng chứng: App log + client result
• KPI: Deny efficacy · Phương pháp: New/established flow · Bằng chứng: Timeout/reset/drop counter
• KPI: Enforcement delay · Phương pháp: Policy/label timestamp đến flow state · Bằng chứng: API audit + probe timeline
• KPI: Leakage window · Phương pháp: Số flow trái policy sau thay đổi · Bằng chứng: Per-flow event log
• KPI: Dataplane health · Phương pháp: Agent/rule/map metrics · Bằng chứng: Node/CNI diagnostics
• KPI: Recovery · Phương pháp: Fault clear đến matrix đúng · Bằng chứng: Continuous probes
• KPI: Scale impact · Phương pháp: Policy/pod/rule tăng dần · Bằng chứng: CPU, memory, latency, drops

IPBlock với NAT/Service có thể thấy địa chỉ khác tại enforcement point. Phải quan sát actual source/destination theo dataplane. Policy cho service CIDR không chắc tương đương pod CIDR; kiểm cả ClusterIP và direct pod IP nếu use case có.

• Case: Không policy chọn pod cho hướng đang xét · Kỳ vọng: NetworkPolicy không cô lập hướng đó; ghi thêm kiểm soát ngoài API chuẩn
• Case: Default-deny ingress · Kỳ vọng: New inbound flow bị chặn
• Case: Default-deny egress · Kỳ vọng: DNS/external bị chặn trừ allow rõ
• Case: Namespace + pod selector trong cùng một phần tử from/to · Kỳ vọng: Chọn giao của hai selector; tách thành hai phần tử là phép OR
• Case: Port-specific allow · Kỳ vọng: Port khác vẫn bị chặn
• Case: Label đổi allow→deny · Kỳ vọng: Enforcement trong SLO
• Case: Pod reschedule sang node khác · Kỳ vọng: Matrix không đổi
• Case: CNI agent/controller lỗi · Kỳ vọng: Fail mode theo thiết kế, không âm thầm mở

Pha A lập ma trận không policy và xác nhận reachability. Pha B áp default-deny ingress/egress, sau đó thêm allow tối thiểu cho DNS và dependency. Pha C kiểm selector, ports, protocol, IPv4/IPv6 và connection established. Pha D thay label/policy/pod liên tục trong khi probe chạy.

Pha E tăng số policy, rule và pod để đo propagation/CPU/memory. Pha F restart CNI agent/controller, partition node và reschedule workload. Pha G nâng version CNI/cluster, chạy regression cùng ma trận. Mỗi case phải có expected new-flow và established-flow riêng.

• Ghi Kubernetes, CNI và dataplane version/mode.
• Tạo ma trận nguồn–đích–port–protocol–IP family.
• Có positive, negative và control flow cho mỗi policy.
• Kiểm DNS thực tế, bao gồm fallback transport nếu có.
• Tách new connection và established connection.
• Đo enforcement delay khi policy/label/pod thay đổi.
• Kiểm ClusterIP, pod IP và external egress theo use case.
• Chèn CNI/controller/node failure; xác nhận fail mode.
• Theo dõi rule capacity, CPU, memory và packet drop.
• Lưu YAML, audit log, probe result và dataplane diagnostics.

NetworkPolicy không thay thế authentication, authorization, encryption hoặc application-layer policy. Hành vi phụ thuộc CNI và version; kết quả của một cluster không đại diện plugin khác. Pod không tự chặn được loopback hoặc traffic từ node nơi nó đang chạy bằng API này. HostNetwork, service mesh và managed load balancer cần kiểm riêng. Fail-closed và thời gian enforcement là tiêu chí triển khai, không phải bảo đảm chung của API NetworkPolicy.

Pass/fail chỉ có giá trị với manifest, topology, dataplane mode và scale đã đo. Không gọi “microsegmentation hoàn chỉnh” nếu chưa kiểm east-west, north-south, DNS, IPv6 và failure mode.

• NetworkPolicy: API mô tả traffic được phép tới/từ pod.
• Default-deny: policy chọn pod nhưng không cho flow ngoài rule rõ.
• Selector: chọn pod/namespace theo label.
• IPBlock: rule dựa trên CIDR.
• CNI: giao diện/plugin mạng container.
• Policy churn: thay đổi policy/label/pod với tốc độ cao.
• Fail-closed: lỗi hệ thống không tự mở quyền truy cập.