在 Rainbond 叢集中,每個團隊對應於底層 Kubernetes 的一個 Namespace ,由於之前使用的底層網路無法進行 Namespace 級別的網路管理,所以在 Rainbond 同一叢集下的不同團隊間,所以元件可以自由的進行互相訪問,使用者無法對此做出任何限制,這也導致了底層網路的安全隱患一直存在。現在由 cilium 提供網路服務的 Kubernetes 叢集可以很好的解決這一問題,使用者可以根據自己的需求,制定針對每個團隊、每個元件的網路策略,加強底層網路管理,實現網路層的安全把控。
使用 cilium 作為 Kubernetes 網路服務
使用從主機安裝時,修改 network.plugin 值為 none
- 安裝 helm
wget https://goodrain-pkg.oss-cn-shanghai.aliyuncs.com/pkg/helm && chmod +x helm && mv helm /usr/local/bin/
- 部署 cilium
helm repo add cilium https://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 https://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
- 測試效果