Egress mặc định từ chối ở tầng mạng

Bài trước cho một bản vá đúng ở tầng ứng dụng. Nó có một điểm yếu chung với mọi bản vá ở tầng đó: nó chỉ bảo vệ chỗ có người gọi nó. Một HttpClient mới tạo ở một service khác, một thư viện gọi ra ngoài, một job nền, hay chính một payload từ bài m6-challenge — không cái nào đi qua ConnectCallback của bạn.

Đây là cùng quan hệ giữa mệnh đề WHERE và RLS ở module 2, và bài này là RLS của SSRF: một lớp ở tầng thấp hơn, không cần ai nhớ gì, và áp cho mọi kết nối bất kể ai mở nó.

Cơ chế: Kubernetes NetworkPolicy mặc định là cho phép tất cả, và điều quan trọng nhất phải hiểu về nó là cách mặc định đó bị đảo: ngay khi một pod bị bất kỳ policy nào chọn với policyTypes: [Egress], pod đó chuyển sang từ chối mọi egress trừ những gì được cho phép tường minh. Không có luật "deny" — chỉ có "chọn pod này và cho phép những thứ sau".

Hai cái bẫy làm policy trông đúng mà không hoạt động:

(1) CNI không thực thi NetworkPolicy. Đây là cái bẫy tệ nhất vì nó im lặng hoàn toàn: kubectl apply thành công, kubectl describe hiện policy đầy đủ, và không gì được thực thi. Flannel không hỗ trợ NetworkPolicy; Calico, Cilium và các CNI của cloud provider thì có. Đây là cùng chế độ lỗi với RLS trên bảng do owner truy cập ở bài rls-second-layer.

(2) Chặn egress mà quên DNS. DNS là egress. Chặn hết egress thì pod không resolve được hostname nào, nên mọi lời gọi thất bại theo cách khó chẩn đoán — và người ta sẽ nới policy thành to: [{}] để "cho nó chạy". Cho phép UDP/TCP 53 tới kube-system là dòng bắt buộc.