eBPF Cilium實戰(1) – 基於團隊的網絡隔離
- 2022 年 4 月 6 日
- 筆記
在 Rainbond 集群中，每個團隊對應於底層 Kubernetes 的一個 Namespace ，由於之前使用的底層網絡無法進行 Namespace 級別的網絡管理，所以在 Rainbond 同一集群下的不同團隊間，所以組件可以自由的進行互相訪問，用戶無法對此做出任何限制，這也導致了底層網絡的安全隱患一直存在。現在由 cilium 提供網絡服務的 Kubernetes 集群可以很好的解決這一問題，用戶可以根據自己的需求，制定針對每個團隊、每個組件的網絡策略，加強底層網絡管理，實現網絡層的安全把控。
使用 cilium 作為 Kubernetes 網絡服務
-
使用從主機安裝時，修改 network.plugin 值為 none
-
安裝 helm
wget //goodrain-pkg.oss-cn-shanghai.aliyuncs.com/pkg/helm && chmod +x helm && mv helm /usr/local/bin/
- 部署 cilium
helm repo add cilium //helm.cilium.io/
helm install cilium cilium/cilium --version 1.11.2 --namespace kube-system --set operator.replicas=1
kubectl get pods --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HOSTNETWORK:.spec.hostNetwork --no-headers=true | grep '<none>' | awk '{print "-n "$1" "$2}' | xargs -L 1 -r kubectl delete pod
- 驗證 cilium
下載 cilium 命令行工具
curl -L --remote-name-all //github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-amd64.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz{,.sha256sum}
- 確認狀態
$ cilium status --wait
/¯¯\
/¯¯\__/¯¯\ Cilium: OK
\__/¯¯\__/ Operator: OK
/¯¯\__/¯¯\ Hubble: disabled
\__/¯¯\__/ ClusterMesh: disabled
\__/
DaemonSet cilium Desired: 2, Ready: 2/2, Available: 2/2
Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2
Containers: cilium-operator Running: 2
cilium Running: 2
Image versions cilium quay.io/cilium/cilium:v1.9.5: 2
cilium-operator quay.io/cilium/operator-generic:v1.9.5: 2
- 測試網絡聯通性（國內服務器測試時，涉及到外部網絡的測試可能會失敗，不影響正常使用）
$ cilium connectivity test
ℹ️ Monitor aggregation detected, will skip some flow validation steps
✨ [k8s-cluster] Creating namespace for connectivity check...
(...)
---------------------------------------------------------------------------------------------------------------------
📋 Test Report
---------------------------------------------------------------------------------------------------------------------
✅ 69/69 tests successful (0 warnings)
設置團隊網絡隔離
Cilium 的網絡隔離策略遵循白名單機制，在不創建網絡策略的情況下，對於網絡不作任何限制，在為指定類型的 pod 集合創建網絡策略後，除策略中允許的訪問地址外，其它請求都會被拒絕。
-
前期準備
- 創建兩個開發團隊和測試團隊，英文名稱設置為 dev 和 test
- 在開發團隊和測試團隊下創建 nginx-dev 和 nginx-test 組件，開啟對內端口，內部域名分別設置為 nginx-dev 和 nginx-test
- 在開發和測試團隊下創建客戶端組件
-
不做任何限制
在不做限制的情況下，各個團隊之間的所有服務均可以自由通信，不受任何特殊限制
-
限制只允許本團隊內組件互相訪問，隔絕其它團隊訪問
在實際生產中，一個集群內部可能會同時部署開發、測試、生產等多個團隊，基於安全性的考慮，需要對每個的團隊做出網絡隔離，禁止其它團隊可以對其進行訪問，下面以開發團隊為例說明如何限制不允許其它團隊對其訪問。
- Cilium 網絡策略文件(dev-ingress.yaml)
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "dev-namespace-ingress"
spec:
endpointSelector:
matchLabels:
"k8s:io.kubernetes.pod.namespace": dev
ingress:
- fromEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": dev
- 創建策略
kubectl create -f dev-ingress.yaml -n dev
- 確認策略
$ kubectl get CiliumNetworkPolicy -A
NAMESPACE NAME AGE
dev dev-namespace-ingress 39s
- 測試效果
-
設置開發團隊下的 nginx-dev 組件只允許測試團隊下的組件訪問
在某些情況下，一些組件的安全要求會更為嚴格，可能只會允許本團隊內符合要求的部分組件進行訪問，下面以 nginx-dev 為例說明如何限制僅允許部分組件進行訪問。
- Cilium 網絡策略文件(nginx-dev-ingress0.yaml)
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "nginx-dev-ingress"
spec:
endpointSelector:
matchLabels:
name: grc156cb
ingress:
- fromEndpoints:
- matchLabels:
name:
- 創建策略
kubectl create -f nginx-dev-ingress0.yaml -n dev
- 確認策略
$ kubectl get CiliumNetworkPolicy -A
NAMESPACE NAME AGE
dev nginx-dev-ingress0 85s
- 測試效果
-
設置開發團隊允許本團隊下組件訪問的同時，允許開發團隊下的 nginx-dev 組件被測試團隊中任意組件訪問
在設置了團隊網絡隔離的情況下，有時候需要臨時開放一些組件給其它團隊訪問以便進行調試，下面以 nginx-dev 組件為例說明如何在設置網絡隔離的情況下開放外部團隊的訪問權限。
- Cilium 網絡策略文件(nginx-dev-ingress1.yaml)
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "nginx-dev-ingress1"
spec:
endpointSelector:
matchLabels:
name: grc156cb
ingress:
- fromEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": test
- 創建策略
kubectl create -f dev-ingress.yaml -n dev
kubectl create -f nginx-dev-ingress.yaml -n dev
- 確認策略
$ kubectl get CiliumNetworkPolicy -A
NAMESPACE NAME AGE
dev dev-namespace-ingress 19s
dev nginx-dev-ingress1 12s
- 測試效果
