我们经常在 Kubernetes 中使用Pod 安全策略(PSP) 来确保 Pod 仅以受限权限运行。 在这篇文章中，我们将讨论如何使用受限 PSP 和开源Banzai Cloud Istio 操作符以尽可能少的权限运行 Istio 的控制平面组件。 介绍 为了完成我们在这里要做的事情——保证 Istio 控制平面组件使用尽可能少的权限——我们建议使用Istio CNI插件。为了强制执行相关的受限权限，我们建议您使用Pod 安全策略。 在开始之前，我们先简单概述一下这两个概念：Istio CNI和Pod 安全策略： Istio CNI 问题 默认情况下，Istio 使用注入的 initContainer 调用 istio-init 来创建 iptables 规则，然后 pod 中的其他容器才能启动。
这要求在网格中部署 Pod 的用户或服务帐户拥有 足够的 权限来部署具有 功能的容器 - 允许重新配置网络的内核功能。一般来说，我们希望避免为应用程序 Pod 提供此功能。NET_ADMIN 不使用 CNI 插件的 Istio POD 初始化 解决方案 缓解此问题的一种方法 电话号码列表 是使用 CNI 插件将 iptables 的规则配置从 pod 中取出。 CNI （容器网络接口）是一个云原生计算基金会项目，由用于编写在 Linux 容器中配置网络接口的插件的规范和库以及许多受支持的插件组成。 Istio CNI 插件取代 了 istio-init 容器，它提供了相同的功能，但不需要 Istio 用户启用提升的权限。它在 Kubernetes Pod 生命周期的设置阶段执行流量重定向，从而消除了 NET_ADMIN 用户将 Pod 部署到网格的能力要求。
插件 有关 Istio CNI 工作原理的更详细说明，请查看我们的使用 CNI 插件增强 Istio 服务网格安全性博客文章。 Pod 安全策略 Pod 安全策略为 Pod 创建提供细粒度的授权。 让我们尝试快速总结一下它们的工作原理： 注意：您必须在 Kubernetes 集群中启用 PSP 准入控制器才能使用 PSP。 缺少 Pod 安全策略 如果您尝试创建一个没有将 PSP 资源附加到其服务帐户的 Pod（通过使用 Role 和 RoleBinding），则准入控制器将拒绝该 Pod 的创建。