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