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