You might question yourself, why the switch to the Istio CNI plugin might be useful?
Istio uses, and other services meshes too, an init container to adjust the iptables rules for redirecting network traffic to/from the sidecar proxy container. The init container uses NET_ADMIN and NET_RAW capabilities to do the iptables changes and thus has more capabilities than per default. Exactly one capability more, cause NET_RAW is a default capability in Kubernetes.
When you are using PSPs or Gatekeeper (Open Policy Agent) to prohibit NET_ADMIN for instance, then you need to define exceptions for it that apply to all namespaces you deploy your applications with the Istio sidecar proxy enabled to.
Here comes the Istio CNI plugin into play. As a cluster admin you just deploy Istio with the CNI plugin enabled. Then you only have one running Istio CNI pod per node as the Istio CNI plugin operates as a DaemonSet. Setting up the network traffic redirection is now handled by the Istio CNI plugin. So, you only need to exclude the istio-system namespace from Gatekeeper or define a separate PSP for it instead of lowering your security restrictions. This in the end reduces the security risk and makes your application deployments more secure.
You can switch a running Istio deployment from the default configuration with an init container to the CNI plugin.
Just add the following additional lines to the YAML template according to the Istio documentation.
apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec: addonComponents: grafana: enabled: true tracing: enabled: true kiali: enabled: true prometheus: enabled: true components: cni: enabled: true ...
You should exclude the standard system namespaces like kube-system, kube-node-lease, kube-public and istio-system as well from the Istio CNI plugin.
apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec: addonComponents: grafana: enabled: true tracing: enabled: true kiali: enabled: true prometheus: enabled: true components: cni: enabled: true ... values: ... cni: excludeNamespaces: - istio-system - kube-system - kube-node-lease - kube-public ...
istioctl manifest apply -f install-istio.yaml to apply the changes. The final step is rotating your application pods to rollout the changes for the Istio sidecar proxies. You can use the
kubectl rollout restart deployment <deployment name> command to do so.