关于istio:使用CNI插件增强Istio服务网格安全性

52次阅读

共计 1839 个字符，预计需要花费 5 分钟才能阅读完成。

为了使服务网格失常工作，Istio 须要在网格中的每个 Pod 中注入一个 Envoy 代理，而后必须通过 iptables 规定操纵 Pod 的流量，从而应用程序进出站的流量劫持到 Envoy 代理。因为每个 Pod 的 iptables 规定都是网络命名空间级别的，因而更改不会影响节点上的其余 Pod。

默认状况下，Istio 应用名为 istio-init 的 initContainer 来创立必要的 iptables 规定，而后再启动 Pod 中的其余容器。这就要求网格中的 Pod 具足够的部署 [NET_ADMIN 容器](https://zhuanlan.zhihu.com/p/%3C/code%3Ehttps://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) 的 Kubernetes RBAC 权限。NET_ADMIN capabilities 是容许重新配置网络的内核性能。

通常，咱们要防止为应用程序 Pod 提供此 capabilities，因为 Istio 用户权限的晋升，对于某些组织的平安政策来说，可能是难以承受的。

解决此问题的一种办法是应用 CNI 插件将 iptables 的规定配置从 pod 中移除。

CNI，它的全称是 Container Network Interface，即容器网络的 API 接口。
它是 K8s 中规范的一个调用网络实现的接口。Kubelet 通过这个规范的 API 来调用不同的网络插件以实现不同的网络配置形式，实现了这个接口的就是 CNI 插件，它实现了一系列的 CNI API 接口。常见的 CNI 插件包含 Calico、flannel、Terway、Weave Net 以及 Contiv。

Istio CNI 插件会在 Kubernetes pod 生命周期的网络设置阶段实现 Istio 网格的 pod 流量转发设置工作，因而用户在部署 pods 到 Istio 网格中时，不再须要配置 [NET_ADMIN](https://link.zhihu.com/?target=https%3A//istio.io/latest/zh/docs/ops/deployment/requirements/) capabilities 了。Istio CNI 插件代替了istio-init 容器所实现的性能。

前提条件

装置反对 CNI 的 Kubernetes 集群，并且 kubelet 应用 --network-plugin=cni 参数启用 CNI 插件。

AWS EKS、Azure AKS 和 IBM Cloud IKS 集群具备这一性能。
Google Cloud GKE 集群须要启用网络策略性能，以让 Kubernetes 配置为 network-plugin=cni。
OpenShift 默认启用了 CNI。
Kubernetes 须要启用 ServiceAccount 准入控制器。
Kubernetes 文档中强烈建议所有应用 ServiceAccounts 的 Kubernetes 装置实例都启用该控制器。

装置

确认 Kubernetes 环境的 CNI 插件的 --cni-bin-dir 和 --cni-conf-dir 设置。任何非默认设置都须要参考托管 Kubernetes 设置。
应用 istioctl 装置 Istio CNI 和 Istio。参考 Istio 装置的阐明，并设置 --set components.cni.enabled=true 和 --set cni.components.cni.enabled=true 选项。在上一步中，如果 istio-cni 不是依照默认设置装置的，还须要设置 --set values.cni.cniBinDir=... 和 --set values.cni.cniConfDir=... 选项。

须要流量重定向的 Pod

Istio CNI 插件通过依据以下条件列表进行查看来查找须要重定向流量的 Pod：