在 Rainbond 集群中,每个团队对应于底层 Kubernetes 的一个 Namespace ,由于之前使用的底层网络无法进行 Namespace 级别的网络管理,所以在 Rainbond 同一集群下的不同团队间,所以组件可以自由的进行互相访问,用户无法对此做出任何限制,这也导致了底层网络的安全隐患一直存在。现在由 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/helm repo add cilium https://helm.cilium.io/helm install cilium cilium/cilium --version 1.11.2 --namespace kube-system --set operator.replicas=1kubectl 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 命令行工具
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.sha256sumsudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/binrm 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/2Deployment cilium-operator Desired: 2, Ready: 2/2, Available: 2/2Containers: cilium-operator Running: 2cilium Running: 2Image versions cilium quay.io/cilium/cilium:v1.9.5: 2cilium-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 集合创建网络策略后,除策略中允许的访问地址外,其它请求都会被拒绝。
前期准备
不做任何限制
在不做限制的情况下,各个团队之间的所有服务均可以自由通信,不受任何特殊限制


限制只允许本团队内组件互相访问,隔绝其它团队访问
在实际生产中,一个集群内部可能会同时部署开发、测试、生产等多个团队,基于安全性的考虑,需要对每个的团队做出网络隔离,禁止其它团队可以对其进行访问,下面以开发团队为例说明如何限制不允许其它团队对其访问。

apiVersion: "cilium.io/v2"kind: CiliumNetworkPolicymetadata:name: "dev-namespace-ingress"spec:endpointSelector:matchLabels:"k8s:io.kubernetes.pod.namespace": devingress:- fromEndpoints:- matchLabels:"k8s:io.kubernetes.pod.namespace": devkubectl create -f dev-ingress.yaml -n dev$ kubectl get CiliumNetworkPolicy -ANAMESPACE NAME AGEdev dev-namespace-ingress 39s

设置开发团队下的 nginx-dev 组件只允许测试团队下的组件访问
在某些情况下,一些组件的安全要求会更为严格,可能只会允许本团队内符合要求的部分组件进行访问,下面以 nginx-dev 为例说明如何限制仅允许部分组件进行访问。

apiVersion: "cilium.io/v2"kind: CiliumNetworkPolicymetadata:name: "nginx-dev-ingress"spec:endpointSelector:matchLabels:name: grc156cbingress:- fromEndpoints:- matchLabels:name: kubectl create -f nginx-dev-ingress0.yaml -n dev$ kubectl get CiliumNetworkPolicy -ANAMESPACE NAME AGEdev nginx-dev-ingress0 85s

设置开发团队允许本团队下组件访问的同时,允许开发团队下的 nginx-dev 组件被测试团队中任意组件访问
在设置了团队网络隔离的情况下,有时候需要临时开放一些组件给其它团队访问以便进行调试,下面以 nginx-dev 组件为例说明如何在设置网络隔离的情况下开放外部团队的访问权限。

apiVersion: "cilium.io/v2"kind: CiliumNetworkPolicymetadata:name: "nginx-dev-ingress1"spec:endpointSelector:matchLabels:name: grc156cbingress:- fromEndpoints:- matchLabels:"k8s:io.kubernetes.pod.namespace": testkubectl create -f dev-ingress.yaml -n devkubectl create -f nginx-dev-ingress.yaml -n dev$ kubectl get CiliumNetworkPolicy -ANAMESPACE NAME AGEdev dev-namespace-ingress 19sdev nginx-dev-ingress1 12s
