From c33389c97422189f6b77d0b9c069d4200e8d4063 Mon Sep 17 00:00:00 2001 From: twilight0620 Date: Wed, 30 Mar 2022 16:26:59 +0800 Subject: [PATCH] [zh] Translate blog Securing-Admission-Controllers-2022.1.19 --- ...22-01-19-Securing-Admission-Controllers.md | 137 ++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 content/zh/blog/_posts/2022-01-19-Securing-Admission-Controllers.md diff --git a/content/zh/blog/_posts/2022-01-19-Securing-Admission-Controllers.md b/content/zh/blog/_posts/2022-01-19-Securing-Admission-Controllers.md new file mode 100644 index 0000000000..cf710ca3db --- /dev/null +++ b/content/zh/blog/_posts/2022-01-19-Securing-Admission-Controllers.md @@ -0,0 +1,137 @@ +--- +layout: blog +title: "确保准入控制器的安全" +date: 2022-01-19 +slug: secure-your-admission-controllers-and-webhooks +--- + + + + + +**作者:** Rory McCune (Aqua Security) + + + +[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/)和认证、授权都是 Kubernetes 安全性的关键部分。 +Webhook 准入控制器被广泛用于以多种方式帮助提高 Kubernetes 集群的安全性, +包括限制工作负载权限和确保部署到集群的镜像满足组织安全要求。 + +然而,与添加到集群中的任何其他组件一样,安全风险也会随之出现。 +一个安全风险示例是没有正确处理准入控制器的部署和管理。 +为了帮助准入控制器用户和设计人员适当地管理这些风险, +SIG 安全小组[安全文档](https://github.com/kubernetes/community/tree/master/sig-security#security-docs) +花费了一些时间来开发一个[准入控制器威胁模型](https://github.com/kubernetes/sig-security/tree/main/sig-security-docs/papers/admission-control)。 +这种威胁模型着眼于由于不正确使用准入控制器而产生的可能的风险,可能允许绕过安全策略,甚至允许攻击者未经授权访问集群。 + +从威胁模型中,我们开发了一套安全最佳实践,应该采用这些实践来确保集群操作员可以获得准入控制器带来的安全优势,同时避免使用它们带来的任何风险。 + + + +## 准入控制器和安全的良好做法 + +从威胁模型中,围绕如何确保准入控制器的安全性出现了几个主题。 + + + +### 安全的 webhook 配置 + +确保集群中的任何安全组件都配置良好并且准入控制器在这里没有什么不同是很重要的。 +使用准入控制器时需要考虑几个安全最佳实践 + +* **为所有 webhook 流量正确配置了 TLS**。 + API 服务器和准入控制器 webhook 之间的通信应该经过身份验证和加密,以确保处于网络中查看或修改此流量的攻击者无法查看或修改。 + 要实现此访问,API 服务器和 webhook 必须使用来自受信任的证书颁发机构的证书,以便它们可以验证相互的身份。 +* **只允许经过身份验证的访问**。 +如果攻击者可以向准入控制器发送大量请求,他们可能会压倒服务导致其失败。 +确保所有访问都需要强身份验证可以降低这种风险。 +* **准入控制器关闭失败**。 + 这是一种需要权衡的安全实践,集群操作员是否要对其进行配置取决于集群的威胁模型。 + 如果一个准入控制器关闭失败,当 API 服务器无法从它得到响应时,所有的部署都会失败。 + 这可以阻止攻击者通过禁用准入控制器绕过准入控制器,但可能会破坏集群的运行。 + 由于集群可以有多个 webhook,因此达到中间立场的一种方法是对故障关闭设置进行关键控制,并允许不太关键的控制进行故障打开。 +* **定期审查 webhook 配置**。 +配置错误可能导致安全问题,因此检查准入控制器 webhook 配置以确保设置正确非常重要。 +这种审查可以由基础设施即代码扫描程序自动完成,也可以由管理员手动完成。 + + + +### 准入控制的安全集群配置 + +在大多数情况下,集群使用的准入控制器 webhook 将作为工作负载安装在集群中。 +因此,确保正确配置了可能影响其操作的 Kubernetes 安全特性非常重要。 + +* **限制 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 权限**。 +任何有权修改 webhook 对象的配置或准入控制器使用的工作负载的用户都可能会中断其操作。 +因此,确保只有集群管理员拥有这些权限非常重要。 +* **防止特权工作负载**。 +容器系统的一个现实是,如果工作负载被赋予某些特权, +则有可能突破到底层集群节点并影响该节点上的其他容器。 +如果准入控制器服务在它们所保护的集群上运行, +一定要确保对特权工作负载的任何要求都要经过仔细审查并尽可能地加以限制。 +* **严格控制外部系统访问**。 +作为集群准入控制器系统中的安全服务,将有权访问敏感信息,如凭证。 +为了降低此信息被发送到集群外的风险, +应使用[网络策略](/zh/docs/concepts/services-networking/network-policies/) +来限制准入控制器服务对外部网络的访问。 +* **每个集群都有一个专用的 webhook**。 +虽然可能有服务于多个集群的准入控制器 webhook, +但在使用该模型时存在对 webhook 服务的攻击会对共享它的地方产生更大影响的风险。 +此外,在多个集群使用准入控制器的情况下,复杂性和访问要求也会增加,从而更难保护其安全。 + + + +### 准入控制器规则 + +任何用于 Kubernetes 安全的准入控制器的一个关键元素是它使用的规则库。 +规则需要能够准确地满足其目标,避免误报和误报结果。 + +* **定期测试和审查规则**。 +需要测试准入控制器规则以确保其准确性。 +还需要定期审查,因为 Kubernetes API 会随着每个新版本而改变, +并且需要在每个 Kubernetes 版本中评估规则,以了解使他们保持最新版本所需要做的任何改变。 \ No newline at end of file