今天會介紹在 pod 與 pod 之間的溝通,主要會介紹兩個服務(1) Istio 以及 (2) Cilium,Istio 主要是透過 mesh 並在各個 pod 中安裝 side car container 的形式控管各個 pod之間是否可以溝通, Cilium 主要提供更進階的 Network Policy,原生的 Network Policy 僅能提供 Layer 3 及 Layer 4 的規則,而 Cilium 則是可以再進一步提供 Layer 7 的規則。
TLS 像是去銀行時,你檢查銀行的招牌和證照(確認這是真的銀行),但銀行不一定檢查你的身份就讓你進門。
mTLS 像是進入高安全機構時,你要檢查警衛的證件確認他是真的員工,同時警衛也要檢查你的身份證明確認你有權限進入。這也是目前提倡的零信任架構
傳統的 TLS
客戶端 → 驗證服務端憑證 → 服務端
← 加密通訊 ←
mTLS(雙向驗證)
客戶端 ↔ 互相驗證憑證 ↔ 服務端
↔ 加密通訊 ↔
基於 mTLS 建立的 mesh ,當 當有啟用時該 namespace 會有 label istio-injection=enabled
時建立 pod 就會自動建立 sidecar container ,多的 container 會叫做 istio-proxy。
為什麼會自動建立呢?原理如下
1. 用戶建立 Pod → 2. kube-apiserver 收到請求
↓
3. 檢查 namespace label → 4. 呼叫 Istio webhook
↓
5. Webhook 修改 Pod spec → 6. 加入 istio-proxy 容器
↓
7. 最終的 Pod 包含 sidecar
小結
Pod Level: 每個 Pod 獨特憑證
Service Account Level: 相同身份的 Pod 群組
Namespace Level: 政策和信任邊界
Cluster Level: 共同的 Root CA
簡單說:每個 Pod 都有自己的"身份證"(憑證),但同一個服務的多個 Pod 會有相同的"身份"!
Cilium 是一個開源的雲原生解決方案,用於提供、保護和監控工作負載間的網路連線,採用革命性的內核技術 eBPF 驅動。
# 標準 K8s NetworkPolicy(基本)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
# Cilium NetworkPolicy(進階)
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: l7-policy
spec:
endpointSelector:
matchLabels:
app: api-server
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "80"
protocol: TCP
rules:
http:
- method: "GET"
path: "/api/v1/.*"
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: http-policy
spec:
endpointSelector:
matchLabels:
app: web-server
ingress:
- fromEndpoints:
- matchLabels:
app: client
toPorts:
- ports:
- port: "80"
rules:
http:
- method: "GET"
- method: "POST"
path: "/api/safe/.*"
# 只允許特定 HTTP 方法和路徑