原文作者：Matthew Yacobucci of F5
转载来源：NGINX 官方网站
面对接二连三的灾难性安全漏洞和勒索软件攻击，2021 年 5 月，拜登政府颁布了一项 行政命令 ，要求改进美国的安全技术，并特别呼吁构建 零信任 (zero trust，即 ZT) 安全模型。
同年 8 月，美国国家标准与技术研究院 (NIST) 发布了一份 白皮书 ，白皮书定义了零信任架构 (ZTA)，并探讨了“零信任可以改善企业整体信息技术安全态势的部署模型和用例”。各个政府机构（包括网络安全和基础设施安全局 (CISA) 以及管理和预算办公室）相继发布零信任实施指导文件，其中包括一个成熟度模型以帮助实施者了解如何分步实现完全零信任部署。
多年来，Kubernetes 社区一直在 讨论如何让零信任 成为端到端加密战略的关键组成部分。service mesh 提供商已经实施了一些关键实践（例如 mTLS 和证书密钥轮换），旨在简化零信任的实施。但即便如此，我们仍处于在大规模应用中实施稳健零信任架构的早期阶段。关于零信任对 Kubernetes 意味着什么以及最佳实践是什么，仍然存在一些争议。相比传统 IT 和基础架构系统，开箱即用的 Kubernetes 给不了解 Kubernetes 网络和安全与前者的区别的团队带来了重大的安全挑战。
什么是零信任？为何零信任很重要？
传统的安全模型在部署环境周围构筑了一个强大的边界，并通过一个集中的“看门人”验证用户身份，且只允许授权用户访问内部的基础架构。随着 微服务 、云和分布式部署的采用，这种模型逐渐被淘汰，因为边界已变得越来越模糊，甚至不确定边界是否还存在。零信任应运而生。
在零信任模型中，几乎没有任何东西或任何人是可信的，包括用户、应用、网络、服务器、服务或 API。每一层的每一个元素都必须经过身份验证和授权测试。当技术资产、应用或服务连接并交换数据时，所有通信都通过指定的代理进行路由，该代理对所有各方进行身份验证并根据访问策略授予他们权限。重要的是，除了明确授权访问特定资源的人以外，零信任系统在每个级别都以最小权限运行，并拒绝所有各方的访问。
零信任具有很多优势——它可以通过以下方式改善安全状况：
零信任对于 云原生 应用和基础架构尤为重要。松散耦合且可移植的云原生应用被设计成在容器中运行，并根据需要改变位置和状态。除了代码、配置和少数必要元素（例如将云原生应用链接到外部世界或内部服务的 IP 地址）之外，一切都是短暂的。东西向流量（环境内部的流量）和南北向流量（进出环境的流量）看起来越来越相似。API 在所有通信（包括应用环境内的通信和与外部客户端的通信）中起中介作用。不断验证权限和身份不仅有用，而且最终还是一种安全需要。
在 Kubernetes 中实施零信任的七条准则
为 Kubernetes 驱动的基础架构和应用部署零信任可能具有一定的挑战性，为此我们提供了一系列实施准则。这些准则可能看起来平淡无奇，但要从零开始实施也不轻松。
准则 1：避免增加 Kubernetes 架构的复杂性
在没有零信任框架的情况下运行 Kubernetes 具有挑战性，而添加零信任会使事情变得更加复杂。对于许多厂商来说，提供额外服务或功能的默认方式是添加新的 sidecar 或 Kubernetes 自定义资源定义 (CRD)。不幸的是，无论添加什么都会增加复杂性。例如，当您添加一个新的 sidecar 来传输可观察性数据时，Kubernetes 必须维护一个甚至两个以上的网络连接。增加的复杂性不仅会降低应用的速度，而且由于需要更大的 pod 来满足应用需求，还会导致基础架构的成本急剧增加。 奥卡姆剃刀 原理适用于此：最简单的零信任路径、最少的 sidecar 和 CRD 通常就是最好的。
准则 2：将开发人员和最终用户的额外开销降至最低
开发人员不想考虑零信任，而且我们也没有理由强迫他们考虑。当零信任的实施迫使开发人员改变其行为或工作流程时，他们可能会抗拒，因为他们认为安全防护会影响开发速度。改变行为或工作流程也显著增加了人为错误的机会 —— 开发人员本身 始终是安全链中的薄弱环节。作为 NetOps 或 SecOps 工程师，如果零信任机制透明到开发人员（以及最终用户和客户）都不知道它们的存在，那么您就成功了。事实上，通过增强安全策略及提高其自动化水平，从理论上来说，零信任甚至可以消除多因素身份验证和许多安全流程中的不便，进而改善最终用户的体验。
准则 3：将零信任规则应用于数据平面和控制平面
虽然数据平面是应用的“活动所在地”，但控制平面通常也同样容易（有时甚至更容易）遭受 供应链攻击 和其他入侵。由于策略引擎以及用于遥测和跟踪的数据收集系统等复杂元素的介入，在控制平面上实施零信任合规要比在数据平面上更复杂。虽然我们很想为数据平面实施零信任，并减少对控制平面及其所有移动部件的担忧，但我们必须确保两者都符合要求，以最大限度发挥零信任的优势。
准则 4：为东西向和南北向流量实施零信任
许多组织开始选择仅将零信任应用到南北向流量，因为来自环境外部的流量似乎不如内部流量可信。这是一种错误的做法。在 Kubernetes 中，东西向流量无论在外观还是行为上都很像南北向流量。Kubernetes 服务、节点和 pod 都通过 API 在 HTTP 或 HTTPS 上进行通信。将相同的零信任策略和流程应用到所有流量会明显提高安全性，并且这样做不会产生更多开销。此外，一开始便在所有位置应用零信任还有一个好处，可避免在南北向零信任实践发生改变后对东西向零信任实践进行修补的风险或麻烦。
准则 5：同时使用 Ingress controller 和 service mesh
虽然不用 Ingress controller 或 service mesh 也可以在 Kubernetes 中构建和运行应用，但如果您想轻松地让零信任成为基础架构中所有元素的默认设置，您就需要用到它们了。Ingress controller 包含了 API 网关和负载均衡器的一些较有用的功能。它的另一项强大优势是可以用作真正的反向代理，能够将流量路由到特定的 Kubernetes pod（与传统的负载均衡器不同）。service mesh 从根本上简化了零信任在东西向流量上的实施、面向审计和验证目的的可观测性和报告。因此，如果您想通过更简单、更清晰的方式实现零信任，那么请在架构设计时同时考虑 Ingress controller 和 service mesh。
准则 6：将 Ingress controller 与 service mesh 集成
该准则与准则 5 密切相关。并非所有 Ingress controller 都可以与所有 service mesh 紧密集成。例如，基于 Istio 的 service mesh 使用与 NGINX Ingress Controller 不同类型的证书管理系统。在设计阶段确保这两个工具能够轻松地紧密集成，可以避免日后出现严重的复杂性和配置问题。有关集成南北向和东西向解决方案的示例，请阅读我们的博文 “如何简化 Kubernetes 出入向流量管理” 。
准则 7：自动化证书的正确处理
对于其他大多数安全的连接形式，证书维护对于在 Kubernetes 中运行用于加密的公钥基础设施 (PKI) 组件至关重要。而对于零信任一致性，证书管理必须是自动化和动态的，这意味着证书需要定期过期和轮换，以确保持续进行身份验证。service mesh 和 Ingress controller 都需要自动进行证书颁发、轮换和到期。如果 Ingress controller 或 service mesh 的本地或最佳集成证书管理工具无法做到这一点，您要不就需要想其他办法，要不就得选择放弃。
想要更及时全面地获取 NGINX 相关的技术干货、互动问答、系列课程、活动资源？
