在 Kubernetes 中实施零信任的七条准则

原文作者：Matthew Yacobucci of F5

原文链接： 在 Kubernetes 中实施零信任的七条准则 - NGINX

转载来源：NGINX 官方网站

---

​
NGINX唯一中文官方社区 ，尽在 nginx.org.cn

面对接二连三的灾难性安全漏洞和勒索软件攻击，2021 年 5 月，拜登政府颁布了一项 行政命令 ，要求改进美国的安全技术，并特别呼吁构建 零信任 (zero trust，即 ZT) 安全模型。

同年 8 月，美国国家标准与技术研究院 (NIST) 发布了一份 白皮书 ，白皮书定义了零信任架构 (ZTA)，并探讨了“零信任可以改善企业整体信息技术安全态势的部署模型和用例”。各个政府机构（包括网络安全和基础设施安全局 (CISA) 以及管理和预算办公室）相继发布零信任实施指导文件，其中包括一个成熟度模型以帮助实施者了解如何分步实现完全零信任部署。

多年来，Kubernetes 社区一直在 讨论如何让零信任 成为端到端加密战略的关键组成部分。service mesh 提供商已经实施了一些关键实践（例如 mTLS 和证书密钥轮换），旨在简化零信任的实施。但即便如此，我们仍处于在大规模应用中实施稳健零信任架构的早期阶段。关于零信任对 Kubernetes 意味着什么以及最佳实践是什么，仍然存在一些争议。相比传统 IT 和基础架构系统，开箱即用的 Kubernetes 给不了解 Kubernetes 网络和安全与前者的区别的团队带来了重大的安全挑战。

什么是零信任？为何零信任很重要？

传统的安全模型在部署环境周围构筑了一个强大的边界，并通过一个集中的“看门人”验证用户身份，且只允许授权用户访问内部的基础架构。随着 微服务 、云和分布式部署的采用，这种模型逐渐被淘汰，因为边界已变得越来越模糊，甚至不确定边界是否还存在。零信任应运而生。

在零信任模型中，几乎没有任何东西或任何人是可信的，包括用户、应用、网络、服务器、服务或 API。每一层的每一个元素都必须经过身份验证和授权测试。当技术资产、应用或服务连接并交换数据时，所有通信都通过指定的代理进行路由，该代理对所有各方进行身份验证并根据访问策略授予他们权限。重要的是，除了明确授权访问特定资源的人以外，零信任系统在每个级别都以最小权限运行，并拒绝所有各方的访问。

零信任具有很多优势——它可以通过以下方式改善安全状况：

• 自动阻止未经授权的活动

• 通过访问控制减少可访问的攻击面

• 快速检测行为异常和危害指标（Indicator of Compromise）

• 通过实时最小权限策略限制访问时间

• 使安全性独立于其他所有变量，包括环境和地理

• 通过持续的认证和身份验证拦截正在进行的攻击

零信任对于 云原生 应用和基础架构尤为重要。松散耦合且可移植的云原生应用被设计成在容器中运行，并根据需要改变位置和状态。除了代码、配置和少数必要元素（例如将云原生应用链接到外部世界或内部服务的 IP 地址）之外，一切都是短暂的。东西向流量（环境内部的流量）和南北向流量（进出环境的流量）看起来越来越相似。API 在所有通信（包括应用环境内的通信和与外部客户端的通信）中起中介作用。不断验证权限和身份不仅有用，而且最终还是一种安全需要。

在 Kubernetes 中实施零信任的七条准则

为 Kubernetes 驱动的基础架构和应用部署零信任可能具有一定的挑战性，为此我们提供了一系列实施准则。这些准则可能看起来平淡无奇，但要从零开始实施也不轻松。

准则 1：避免增加 Kubernetes 架构的复杂性

在没有零信任框架的情况下运行 Kubernetes 具有挑战性，而添加零信任会使事情变得更加复杂。对于许多厂商来说，提供额外服务或功能的默认方式是添加新的 sidecar 或 Kubernetes 自定义资源定义 (CRD)。不幸的是，无论添加什么都会增加复杂性。例如，当您添加一个新的 sidecar 来传输可观察性数据时，Kubernetes 必须维护一个甚至两个以上的网络连接。增加的复杂性不仅会降低应用的速度，而且由于需要更大的 pod 来满足应用需求，还会导致基础架构的成本急剧增加。 奥卡姆剃刀 原理适用于此：最简单的零信任路径、最少的 sidecar 和 CRD 通常就是最好的。

准则 2：将开发人员和最终用户的额外开销降至最低

开发人员不想考虑零信任，而且我们也没有理由强迫他们考虑。当零信任的实施迫使开发人员改变其行为或工作流程时，他们可能会抗拒，因为他们认为安全防护会影响开发速度。改变行为或工作流程也显著增加了人为错误的机会 —— 开发人员本身 始终是安全链中的薄弱环节。作为 NetOps 或 SecOps 工程师，如果零信任机制透明到开发人员（以及最终用户和客户）都不知道它们的存在，那么您就成功了。事实上，通过增强安全策略及提高其自动化水平，从理论上来说，零信任甚至可以消除多因素身份验证和许多安全流程中的不便，进而改善最终用户的体验。

准则 3：将零信任规则应用于数据平面和控制平面

虽然数据平面是应用的“活动所在地”，但控制平面通常也同样容易（有时甚至更容易）遭受 供应链攻击 和其他入侵。由于策略引擎以及用于遥测和跟踪的数据收集系统等复杂元素的介入，在控制平面上实施零信任合规要比在数据平面上更复杂。虽然我们很想为数据平面实施零信任，并减少对控制平面及其所有移动部件的担忧，但我们必须确保两者都符合要求，以最大限度发挥零信任的优势。

准则 4：为东西向和南北向流量实施零信任

关于该准则的详细内容，您可以点击文章《在 Kubernetes 中实施零信任的七条准则》阅读查看。

准则 5：同时使用 Ingress controller 和 service mesh

关于该准则的详细内容，您可以点击文章《在 Kubernetes 中实施零信任的七条准则》阅读查看。

准则 6：将 Ingress controller 与 service mesh 集成

关于该准则的详细内容，您可以点击文章《在 Kubernetes 中实施零信任的七条准则》阅读查看。

准则 7：自动化证书的正确处理

对于其他大多数安全的连接形式，证书维护对于在 Kubernetes 中运行用于加密的公钥基础设施 (PKI) 组件至关重要。而对于零信任一致性，证书管理必须是自动化和动态的，这意味着证书需要定期过期和轮换，以确保持续进行身份验证。service mesh 和 Ingress controller 都需要自动进行证书颁发、轮换和到期。如果 Ingress controller 或 service mesh 的本地或最佳集成证书管理工具无法做到这一点，您要不就需要想其他办法，要不就得选择放弃。

---

更多资源

NGINX唯一中文官方社区 ，尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源：

开源社区官网：开源Web服务提供商 - NGINX开源社区
微信公众号：NGINX郑重宣布对开源社区的全新承诺