这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
确保准入控制器的安全
作者: Rory McCune (Aqua Security)
准入控制和认证、授权都是 Kubernetes 安全性的关键部分。 Webhook 准入控制器被广泛用于以多种方式帮助提高 Kubernetes 集群的安全性， 包括限制工作负载权限和确保部署到集群的镜像满足组织安全要求。
然而，与添加到集群中的任何其他组件一样，安全风险也会随之出现。 一个安全风险示例是没有正确处理准入控制器的部署和管理。 为了帮助准入控制器用户和设计人员适当地管理这些风险， SIG Security 的安全文档小组 花费了一些时间来开发一个准入控制器威胁模型。 这种威胁模型着眼于由于不正确使用准入控制器而产生的可能的风险，可能允许绕过安全策略，甚至允许攻击者未经授权访问集群。
基于这个威胁模型，我们开发了一套安全最佳实践。 你应该采用这些实践来确保集群操作员可以获得准入控制器带来的安全优势，同时避免使用它们带来的任何风险。
准入控制器和安全的良好做法
基于这个威胁模型，围绕着如何确保准入控制器的安全性出现了几个主题。
安全的 webhook 配置
确保集群中的任何安全组件都配置良好是很重要的，在这里准入控制器也并不例外。 使用准入控制器时需要考虑几个安全最佳实践：
- 为所有 webhook 流量正确配置了 TLS。 API 服务器和准入控制器 webhook 之间的通信应该经过身份验证和加密，以确保处于网络中查看或修改此流量的攻击者无法查看或修改。 要实现此访问，API 服务器和 webhook 必须使用来自受信任的证书颁发机构的证书，以便它们可以验证相互的身份。
- 只允许经过身份验证的访问。 如果攻击者可以向准入控制器发送大量请求，他们可能会压垮服务导致其失败。 确保所有访问都需要强身份验证可以降低这种风险。
- 准入控制器关闭失败。 这是一种需要权衡的安全实践，集群操作员是否要对其进行配置取决于集群的威胁模型。 如果一个准入控制器关闭失败，当 API 服务器无法从它得到响应时，所有的部署都会失败。 这可以阻止攻击者通过禁用准入控制器绕过准入控制器，但可能会破坏集群的运行。 由于集群可以有多个 webhook，因此一种折中的方法是对关键控制允许故障关闭， 并允许不太关键的控制进行故障打开。
- 定期审查 webhook 配置。 配置错误可能导致安全问题，因此检查准入控制器 webhook 配置以确保设置正确非常重要。 这种审查可以由基础设施即代码扫描程序自动完成，也可以由管理员手动完成。
为准入控制保护集群配置
在大多数情况下，集群使用的准入控制器 webhook 将作为工作负载安装在集群中。 因此，确保正确配置了可能影响其操作的 Kubernetes 安全特性非常重要。
- 限制 RBAC 权限。 任何有权修改 webhook 对象的配置或准入控制器使用的工作负载的用户都可以破坏其运行。 因此，确保只有集群管理员拥有这些权限非常重要。
- 防止特权工作负载。 容器系统的一个现实是，如果工作负载被赋予某些特权， 则有可能逃逸到下层的集群节点并影响该节点上的其他容器。 如果准入控制器服务在它们所保护的集群上运行， 一定要确保对特权工作负载的所有请求都要经过仔细审查并尽可能地加以限制。
- 严格控制外部系统访问。 作为集群中的安全服务，准入控制器系统将有权访问敏感信息，如凭证。 为了降低此信息被发送到集群外的风险， 应使用网络策略 来限制准入控制器服务对外部网络的访问。
- 每个集群都有一个专用的 webhook。 虽然可能让准入控制器 webhook 服务于多个集群的， 但在使用该模型时存在对 webhook 服务的攻击会对共享它的地方产生更大影响的风险。 此外，在多个集群使用准入控制器的情况下，复杂性和访问要求也会增加，从而更难保护其安全。
准入控制器规则
对于用于 Kubernetes 安全的所有准入控制器而言，一个关键元素是它使用的规则库。 规则需要能够准确地满足其目标，避免假阳性和假阴性结果。
- 定期测试和审查规则。 需要测试准入控制器规则以确保其准确性。 还需要定期审查，因为 Kubernetes API 会随着每个新版本而改变， 并且需要在每个 Kubernetes 版本中评估规则，以了解使他们保持最新版本所需要做的任何改变。