# 🚦 NetworkPolicy và luồng traffic giữa các Pod
## Mục tiêu học tập
- Giải thích được mô hình mạng phẳng: mỗi Pod có IP riêng và mặc định gọi được tới mọi Pod khác.
- Đọc hiểu manifest NetworkPolicy: `podSelector`, `policyTypes`, `ingress`/`egress`, `from`/`to`, `ports`.
- Phân biệt đúng AND (cùng một phần tử trong list) và OR (nhiều phần tử trong list).
- Viết được bộ policy default-deny + allow theo label mà không tự khóa mình ra ngoài.
- Nhận ra cạm bẫy lớn nhất: CNI không hỗ trợ NetworkPolicy thì policy tạo ra mà không có tác dụng gì.
## Ôn tập nhanh
Ở bài Service và Ingress, bạn đã dùng `selector` trên label để Service tìm ra endpoint. NetworkPolicy dùng đúng cơ chế label đó, nhưng mục đích ngược lại: không phải để mở đường mà để giới hạn đường. Nếu bạn còn nhớ `kubectl get pods --show-labels`, bài này sẽ rất nhanh.
## Lý thuyết
### 1. Mạng phẳng: mặc định ai cũng nói chuyện được với ai
Trong cluster, mỗi Pod có một IP riêng và mọi Pod định tuyến được tới Pod khác mà không qua NAT. Không có tường lửa mặc định ở tầng Pod. Cluster vừa dựng xong thì Pod ở namespace `frontend` gọi thẳng IP của Pod trong namespace `db` được, và ngược lại.
NetworkPolicy là resource **namespaced** dùng để thay đổi mặc định đó. Nó chọn Pod mục tiêu bằng label, rồi khai báo danh sách traffic được phép vào (`ingress`) và ra (`egress`).
### 2. Ba nguyên tắc không được quên
- Không có policy nào chọn Pod: mọi chiều đều **allow all**.
- Có ít nhất một policy chọn Pod và `policyTypes` gồm `Ingress`: Pod bị **isolate** chiều đó, chỉ traffic khớp rule mới vào được.
- Nhiều policy cùng chọn một Pod: **cộng dồn (union)**, không có thứ tự ưu tiên, không có rule deny.
Nói cách khác, bạn không viết "chặn A". Bạn viết "mở B" và phần còn lại tự bị chặn một khi đã có policy. Đây là lý do NetworkPolicy được gọi là **allow-list**.
```mermaid
flowchart TD
A["📦 Pod nhận traffic"] --> B{"Có policy nào chọn Pod này
với policyTypes Ingress?"}
B -->|Không| C["✅ Allow all"]
B -->|Có| D["🔒 Isolated"]
D --> E["Chỉ hợp các rule được liệt kê
không có deny, không có thứ tự"]
```
`policyTypes` nếu bỏ trống sẽ được suy ra: có `ingress:` thì thêm `Ingress`, có `egress:` thì thêm `Egress`. Cẩn thận: muốn chặn sạch egress thì phải khai `policyTypes: [Egress]` với `egress: []`. Nếu chỉ khai `[Ingress]`, chiều ra vẫn mở toang.
### 3. AND và OR trong `from` / `to`
Đây là chỗ người mới sai nhiều nhất. Quy tắc: **cùng một phần tử list = AND, khác phần tử = OR**.
```yaml
ingress:
- from:
- namespaceSelector: # AND: phải ở namespace monitoring
matchLabels:
kubernetes.io/metadata.name: monitoring
podSelector: # VÀ có label app=prometheus
matchLabels:
app: prometheus
```
```yaml
ingress:
- from:
- podSelector: {matchLabels: {app: frontend}} # OR: frontend cùng namespace
- namespaceSelector: # HOẶC bất kỳ Pod nào
matchLabels: # trong namespace monitoring
kubernetes.io/metadata.name: monitoring
```
Label `kubernetes.io/metadata.name` được gắn tự động bằng tên namespace (từ Kubernetes 1.21), nên không cần tự label namespace nữa.
### 4. Cạm bẫy số một: CNI
NetworkPolicy chỉ là ý định khai báo. Việc thực thi nằm ở CNI plugin. Calico, Cilium, Antrea làm được. Flannel bản mặc định **không** làm được: `kubectl apply` vẫn báo thành công, `kubectl get netpol` vẫn liệt kê policy, nhưng traffic không hề bị chặn. Luôn kiểm tra CNI trước khi tin vào policy của bạn.
> [!WARNING]
> Trước khi kết luận "policy sai", hãy xác nhận CNI của cluster có hỗ trợ NetworkPolicy. Nếu không, mọi thứ bạn viết chỉ là tài liệu trang trí.
## Ví dụ có hướng dẫn
### Ví dụ 1: default-deny ingress cho cả namespace
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: shop
spec:
podSelector: {}
policyTypes:
- Ingress
```
`podSelector: {}` chọn **tất cả** Pod trong namespace `shop`. Không có rule `ingress` nào nghĩa là không ai vào được. Đây là policy đầu tiên bạn nên apply ở mọi namespace mới.
### Ví dụ 2: mở đúng một đường
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-api
namespace: shop
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
```
Đọc theo thứ tự: Pod `app=api` nhận traffic từ Pod `app=frontend` cùng namespace, trên port 8080 của container. Vì chỉ có một rule, mọi port khác của `api` cũng bị chặn. Lưu ý `port` ở đây là **container port**, không phải port của Service.
### Ví dụ 3: egress và cái bẫy DNS
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: api-egress
namespace: shop
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
app: db
ports:
- protocol: TCP
port: 5432
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
```
Rule thứ hai là DNS. Bỏ nó đi thì `api` vẫn "nói chuyện" được với IP của `db`, nhưng không resolve được `db.shop.svc.cluster.local`, và mọi lời gọi bằng hostname sẽ chết với lỗi trông rất giống lỗi policy.
## Thực hành có hướng dẫn
### Bài 1: Đọc policy
Với policy `allow-frontend-to-api` ở trên, Pod `app=api` còn nhận được traffic từ đâu nữa không? Trả lời trước khi mở đáp án.
Xem đáp án
Không còn nguồn nào khác. Pod `api` đã bị isolate chiều ingress, và chỉ một rule duy nhất được khai. Traffic từ Ingress controller, từ Pod test, hay từ chính bạn gọi thẳng IP Pod đều bị chặn, trừ khi nguồn đó có label `app=frontend` trong namespace `shop`.
Xem hướng dẫn
`bad address` là lỗi resolve DNS, không phải lỗi kết nối. Egress đã bị isolate và bạn chưa allow port 53. Thêm rule DNS như Ví dụ 3, hoặc test nhanh bằng IP của Pod `db` (`kubectl get pod -l app=db -o wide`) để xác nhận đường 5432 đã thông. Cách kiểm tra tổng quát: chạy một Pod tạm trong namespace để test từ cả hai phía.
```bash
kubectl run nettest --rm -it -n shop --image=nicolaka/netshoot -- bash
# trong Pod: nc -zv api 8080 ; nslookup db
```