在 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/

• 部署 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 '' | 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
  /¯¯<br /> /¯¯__/¯¯\ 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

• 测试效果