保护准入控制器

准入控制 (Admission control) 是 Kubernetes 安全的关键部分，与认证 (authentication) 和授权 (authorization) 并列。Webhook 准入控制器被广泛用于以多种方式帮助提高 Kubernetes 集群的安全性，包括限制工作负载的权限以及确保部署到集群的镜像符合组织的安全要求。

然而，正如添加到集群中的任何附加组件一样，也会出现安全风险。一个安全风险的例子是如果准入控制器的部署和管理处理不当。为了帮助准入控制器的用户和设计者妥善管理这些风险，SIG Security 的 安全文档 子小组花费了一些时间开发了准入控制器的威胁模型。这个威胁模型着眼于因不正确使用准入控制器而可能出现的潜在风险，这些风险可能允许绕过安全策略，甚至允许攻击者获得对集群的未经授权访问。

基于威胁模型，我们开发了一套安全最佳实践，应该予以采纳，以确保集群运维人员在获得准入控制器安全优势的同时，避免使用它们带来的任何风险。

准入控制器与安全最佳实践

基于威胁模型，围绕如何确保准入控制器的安全，出现了几个主题。

安全的 Webhook 配置

确保集群中的任何安全组件都配置良好非常重要，准入控制器也不例外。使用准入控制器时需要考虑以下几个安全最佳实践：

• 为所有 Webhook 流量正确配置 TLS。API 服务器和准入控制器 Webhook 之间的通信应进行身份验证和加密，以确保处于网络位置可能查看或修改此流量的攻击者无法进行此类操作。为此，API 服务器和 Webhook 必须使用来自受信任证书颁发机构的证书，以便它们可以验证相互的身份。
• 仅允许经过身份验证的访问。如果攻击者可以向准入控制器发送大量请求，他们可能会使服务过载导致其失败。确保所有访问都需要强身份验证应该可以减轻这种风险。
• 准入控制器故障关闭 (fails closed)。这是一个有权衡的安全实践，是否配置它取决于集群的威胁模型。如果准入控制器故障关闭，当 API 服务器无法从中获得响应时，所有部署都将失败。这阻止了攻击者通过禁用准入控制器来绕过它，但这会中断集群的运行。由于集群可以有多个 Webhook，一种折中的方法可能是将关键控制配置为故障关闭，而不太关键的控制允许故障打开。
• 定期审查 Webhook 配置。配置错误可能导致安全问题，因此检查准入控制器 Webhook 配置以确保设置正确非常重要。这种审查可以通过基础设施即代码 (IaC) 扫描器自动完成，也可以由管理员手动进行。

准入控制的安全集群配置

在大多数情况下，集群使用的准入控制器 Webhook 将作为工作负载安装在集群中。因此，确保可能影响其运行的 Kubernetes 安全功能配置良好非常重要。

• 限制 RBAC 权限。任何有权修改 Webhook 对象配置或准入控制器所用工作负载的用户都可能扰乱其运行。因此，确保只有集群管理员拥有这些权限非常重要。
• 防止特权工作负载。容器系统的一个现实是，如果一个工作负载被赋予某些特权，它就有可能逃逸到底层的集群节点并影响该节点上的其他容器。当准入控制器服务运行在它所保护的集群中时，确保对特权工作负载的任何要求都经过仔细审查并尽可能限制，这一点非常重要。
• 严格控制外部系统访问。作为集群中的安全服务，准入控制器系统将访问凭据等敏感信息。为了降低将此信息发送到集群外部的风险，应使用网络策略限制准入控制器服务对外部网络的访问。
• 每个集群拥有专用的 Webhook。虽然可以有服务于多个集群的准入控制器 Webhook，但使用这种模型存在风险，即对 Webhook 服务的攻击会在共享时产生更大的影响。此外，当多个集群使用同一个准入控制器时，复杂性和访问要求会增加，从而使其更难得到安全保障。

准入控制器规则

用于 Kubernetes 安全的任何准入控制器的关键要素是其使用的规则库。这些规则需要能够准确地实现其目标，避免误报和漏报。

• 定期测试和审查规则。需要对准入控制器规则进行测试以确保其准确性。由于 Kubernetes API 会随新版本而变化，因此还需要定期审查这些规则，并在每个 Kubernetes 发布版本时对其进行评估，以了解可能需要进行的任何更改，从而保持其更新。

• ←上一篇
• 下一篇→