Trong thế giới container hóa và kiến trúc microservices hiện đại, việc kiểm soát luồng giao tiếp giữa các pod là một yêu cầu sống còn về bảo mật. Network Policy nổi lên như một công cụ then chốt giúp quản trị viên thiết lập các quy tắc tường lửa cho cụm Kubernetes. Nắm vững cách quản lý network policy không chỉ giúp bảo vệ hạ tầng tránh khỏi các truy cập trái phép mà còn tối ưu hiệu năng và tuân thủ các tiêu chuẩn an ninh nghiêm ngặt. Bài viết này sẽ đi sâu vào từng khía cạnh từ khái niệm cơ bản đến các chiến lược vận hành thực tiễn.
Network Policy là gì và tại sao cần quản lý chúng?
Network Policy là một tài nguyên trong Kubernetes (API object) cho phép bạn xác định cách các pod được phép giao tiếp với nhau và với các endpoint mạng khác. Về bản chất, nó hoạt động như một bộ lọc gói tin có chọn lọc, dựa trên các nhãn (labels) và không gian tên (namespaces). Nếu không có network policy, mặc định Kubernetes cho phép tất cả pod giao tiếp với nhau – điều này tạo ra rủi ro bảo mật rất lớn. Quản lý network policy đúng cách đồng nghĩa với việc bạn chủ động thu hẹp bề mặt tấn công, cách ly các môi trường (dev/staging/prod) và kiểm soát truy cập từ bên ngoài cụm.
Network Policy hoạt động dựa trên cơ chế cho phép (allow) – không có khái niệm deny. Một policy chỉ định ra các điều kiện mà kết nối phải thỏa mãn để được phép đi qua. Policy được áp dụng cho các pod được chọn thông qua trường podSelector. Khi có nhiều policy cùng tác động lên một pod, Kubernetes sẽ hợp các quy tắc lại (union) – nghĩa là nếu bất kỳ policy nào cho phép, kết nối sẽ được chấp nhận.
Điều quan trọng cần nhớ: nếu không có policy nào áp dụng cho một pod, pod đó sẽ chấp nhận tất cả traffic (mặc định). Ngược lại, khi có ít nhất một policy chọn pod đó, thì chỉ những traffic khớp với policy mới được phép – tất cả traffic khác đều bị chặn.
Các thành phần cốt lõi trong một Network Policy
podSelector: chọn nhóm pod mà policy sẽ áp dụng (dùng labels).
policyTypes: khai báo hướng traffic mà policy ảnh hưởng (Ingress, Egress hoặc cả hai).
ingress: quy tắc cho traffic đi vào pod được chọn.
egress: quy tắc cho traffic đi ra từ pod được chọn.
from/to: xác định nguồn (source) hoặc đích (destination) dựa trên ipBlock, namespaceSelector, podSelector hoặc kết hợp.
Phân loại các chiến lược quản lý network policy
Có nhiều cách tiếp cận khác nhau để quản lý network policy, tùy thuộc vào quy mô cụm, yêu cầu bảo mật và mức độ tự động hóa.
1. Chiến lược “Deny All” – Khóa chặt mặc định
Đây là cách tiếp cận an toàn nhất: tạo một policy mặc định chặn mọi traffic (cả ingress và egress) cho tất cả pod trong một namespace. Sau đó, bạn từ từ mở các đường dẫn cần thiết bằng các policy cụ thể. Phương pháp này yêu cầu kiểm soát chặt chẽ việc khai báo policy, phù hợp với môi trường production nhạy cảm.
2. Chiến lược “Allow Known Services” – Chỉ cho phép các kết nối đã biết
Thay vì chặn toàn bộ, bạn xác định danh sách các service mà pod cần giao tiếp (ví dụ: database chỉ được phép nhận request từ ứng dụng frontend). Các policy được xây dựng dựa trên labels và namespace, giúp dễ bảo trì hơn khi hệ thống mở rộng.
3. Chiến lược “Least Privilege” – Nguyên tắc đặc quyền tối thiểu
Kết hợp cả hai hướng tiếp cận trên: mỗi pod chỉ có quyền truy cập đúng những gì nó cần để hoạt động. Đây là best practice được khuyến nghị bởi các chuyên gia Kubernetes. Quản lý network policy theo nguyên tắc này đòi hỏi việc lập bản đồ dependency giữa các microservices một cách tỉ mỉ.
Lợi ích và hạn chế của việc quản lý network policy
Lợi ích
Lợi ích
Mô tả
Tăng cường bảo mật
Ngăn chặn truy cập trái phép giữa các pod, giảm thiểu thiệt hại khi một container bị xâm nhập.
Tuân thủ quy định
Đáp ứng các yêu cầu kiểm soát truy cập mạng theo PCI DSS, HIPAA, SOC 2…
Giảm nhiễu mạng
Loại bỏ lưu lượng không cần thiết, giúp mạng ổn định và dễ debug hơn.
Hỗ trợ cách ly môi trường
Phân tách rõ ràng giữa dev, staging, prod ngay trong cùng cụm.
Hạn chế
Phụ thuộc vào CNI plugin hỗ trợ network policy (Calico, Cilium, Weave Net…). Các plugin mặc định như Flannel không hỗ trợ.
Yêu cầu kiến thức sâu về labels và namespace – dễ gây lỗi cấu hình nếu không hiểu rõ.
Không thể tạo policy “deny” trực tiếp – chỉ có thể “allow” hoặc “implicit deny”.
Quản lý số lượng policy lớn có thể trở nên phức tạp nếu không dùng GitOps hoặc công cụ tự động.
So sánh Network Policy với các giải pháp kiểm soát truy cập truyền thống
Tiêu chí
Network Policy (Kubernetes)
Tường lửa truyền thống / Security Group
Phạm vi kiểm soát
Pod (có thể thay đổi theo labels)
IP tĩnh, subnet, VM
Độ linh hoạt
Cao – policy cập nhật động khi pod thay đổi label
Thấp – mỗi lần thay đổi cần cập nhật IP hoặc security group
Tích hợp với container
Có – bản địa trong Kubernetes
Phải thông qua proxy hoặc sidecar
Khả năng giám sát
Phải dùng công cụ bên ngoài (Calico, Cilium)
Có tích hợp sẵn log firewall
Chi phí vận hành
Thấp nếu dùng GitOps, cao nếu manual
Trung bình – quen thuộc với đội network
Cách quản lý network policy từng bước chi tiết
Bước 1: Kiểm tra CNI plugin hỗ trợ network policy
Trước hết, bạn cần chắc chắn cụm Kubernetes của mình đang sử dụng CNI hỗ trợ network policy. Sử dụng lệnh kubectl get nodes và kiểm tra log của các pod trong namespace kube-system. Nếu dùng Calico,
Có. Service chỉ là virtual IP và load balancer, traffic vẫn đi qua mạng pod-to-pod thực tế. Vì vậy, nếu policy chặn traffic giữa pod label A và pod label B, thì service cũng sẽ không hoạt động nếu nó tuyển chọn đúng các pod này. Lưu ý rằng kube-proxy thực hiện DNAT, policy sẽ kiểm tra địa chỉ thực của pod đích sau khi NAT.
Có thể áp dụng network policy cho các pod trong namespace khác nhau không?
Có. Bạn sử dụng namespaceSelector kết hợp với podSelector trong phần from hoặc to. Ví dụ cho phép pod từ namespace “monitoring” gọi đến pod trong namespace “production”. Tuy nhiên, cần lưu ý rằng policy chỉ có effect nếu CNI hỗ trợ cross-namespace policy.
Network policy có thể dùng để chặn traffic ra internet không?
Có. Bạn tạo policy egress với ipBlock hoặc không cho phép bất kỳ đích nào (chặn mọi egress). Tuy nhiên, để cho phép truy cập internet, bạn cần thêm rule egress với ipBlock trỏ đến CIDR của internet (hoặc cụ thể hơn là các IP đích cần thiết).
Có nên dùng network policy cho môi trường development không?
Rất nên. Dù môi trường dev có thể lỏng lẻo hơn, nhưng dùng network policy ngay từ đầu giúp team làm quen và phát hiện sớm các vấn đề thiết kế dependency. Bạn có thể dùng policy với cấu hình nhẹ hơn, chẳng hạn chỉ chặn ingress không cần thiết.
Kết luận
Quản lý network policy là một kỹ năng không thể thiếu đối với bất kỳ quản trị viên Kubernetes nào muốn xây dựng hạ tầng an toàn, tuân thủ và hiệu quả. Từ việc hiểu rõ nguyên lý inplicit deny, lựa chọn CNI plugin phù hợp, thiết kế labels chuẩn xác, đến việc kiểm thử và giám sát liên tục – tất cả đều đóng góp vào một hệ thống vững chắc. Đừng quên áp dụng GitOps, tự động hóa việc triển khai policy và thường xuyên audit để tránh các lỗ hổng bảo mật. Bắt đầu với một policy đơn giản, mở rộng dần dựa trên nhu cầu thực tế, và bạn sẽ nhanh chóng làm chủ cách quản lý network policy một cách chuyên nghiệp.
