零信任对 Kubernetes 意味着什么？

零信任是一种强大安全模型，同时也是一个容易被过度营销的概念。那么，究竟什么是零信任呢？对于 Kubernetes 来说，它的具体含义是什么？在这篇文章中，我们将从工程角度探讨零信任的定义，并通过建立一个基本框架以解析其对 Kubernetes 运维和安全团队的影响。

无论是否用 Kubernetes，但凡是构建现代云计算软件，你大概都听说过“零信任”这个词。零信任模型的安全重要性甚至已经惊动了美国联邦政府。在白宫近日发布的一份备忘录中提出了联邦零信任战略，要求所有美国联邦机构在 2024 财政年度结束前需达到特定的零信任安全标准；美国国防部创建了一个零信任参考框架；国家安全局也发布了一份 Kubernetes 加固指南，特别描述了 Kubernetes 的零信任安全最佳实践。

零信任的热度自然吸引了大量市场上的关注。尽管如此，零信任并不只是一个空洞的术语：它代表了对未来安全性的一些深刻变革的想法。那么，零信任具体是什么，为什么它会突然变得如此重要？零信任对 Kubernetes 用户来说具体意味着什么呢？

什么是零信任？

正如其名，零信任本质上是关于信任的。零信任是为了解决安全的核心问题之一：是否允许 X 访问 Y？换句话说，我们是否信任 X 访问 Y？

当然，零信任中的“零”是有些夸大其词，软件运行还是可以相信某些信息的。因此，零信任并非是要完全消除信任，而是将信任的范围缩减到必要的最低限度（也就是我们熟悉的最小特权原则），并确保其能够在每一点上都得到执行。

这听起来没什么稀奇的，但就和许多技术领域的新想法一样，理解零信任的最好办法是搞清楚它能做些什么。零信任是对“周界系统安全足矣”这一观点的否定。在周界安全模型中，我们在敏感组件周围设置个“硬壳”，如在数据中心周围设置防火墙以阻挡恶意流量和行为者。周界安全亦被称作是“城堡方法”，意义很直观：城堡的墙壁是为防止坏人进入，但如果你在城堡之内，那么你一定是好人。

对于零信任模型来说，周界安全已经不够了。即使在安全周界内，你仍需将用户、系统和网络流量视为不受信任的。美国国防部的参考架构对其有很好的总结：

在安全周界之外或之内运作的任何行为者、系统、网络或者服务都不会被信任。我们必须验证任何试图建立访问的事物。这是我们在确保基础设施、网络和数据的安全在理念上的重大转变，将周界的一次性验证改为不断验证每一个用户、设备、应用程序以及交易。

当然，零信任不意味着我们应该丢弃防火墙，深度防御是任何安全战略的重要组成部分；也不意味着我们可以忽视其他重要的组成部分，如事件记录和供应链管理。零信任只是要求我们将信任检查从“在周界验证一次”转换为“无时不刻且无处不验证”。

要想做到这点，我们需要重新思考关于“信任”的基础假设，什么是“信任”以及如何赢得信任。

身份

零信任最直接的影响之一是它改变了确认和分配身份的方式，尤其是系统身份。

在周界安全模式中，位置即身份。如果在防火墙内，就可以被信任；如果在防火墙外，那就不被信任。因此，基于周界安全的系统可以根据用户的 IP 地址等信息决定其是否可以访问敏感系统。

在零信任的世界里位置信息是不够的。IP 地址只代表了所处的位置，不足以决定是否可以被信任访问特定资源。因此，我们需要另一种形式的身份，另一种与工作负载、用户或系统以某种内在形式绑定的身份，并且这种形式的身份验证本身不应需要网络的信任。

这要求很大，也有很多影响。依赖 IP 地址等网络身份标识，以提供网络安全信赖的系统不足以实现零信任，如 IPSec 或 Wireguard。

策略

在新的身份模型基础上，我们还需要一种能够决定每种身份所能访问信息类型的方式。在前文所提到的周界安全模型中，通常会赋予特定范围内的 IP 地址所有敏感信息的访问权限，比如设置 IP 地址过滤以确保只有防火墙内的 IP 地址可以访问敏感服务。在零信任中，我们必须强制执行最低限度的必要访问：基于身份及其他相关因素，尽可能地限制对资源的访问权。

虽然应用程序可以自行决定这些授权，但我们一般都会在应用之外通过某种策略进行授权。有了明确的策略，我们就可以在不修改应用代码的情况下审计或变更访问权限。

这些策略在零信任的目标下可以变得十分繁复。举例来说，我们可以将策略调整为只允许必要的调用任务访问某项服务（如，双方都使用工作负责模式），进一步细化后，我们可以限制只允许外部访问该服务的部分接口（HTTP 路由或 gRPC 方法，），再进一步细化，可以根据发出请求的用户身份来限制访问。任何情况下，我们的目标都是最小特权：系统和数据只有在绝对必要的情况下才可被访问。

实施

最后，零信任还需要我们最小颗粒度地执行认证（身份确认）和授权（验证策略是否允许当前行为）。所有可以授权数据或计算访问的系统都应设置一个安全边界，上至系统外围下至单个组件。

与策略类似，理想状态下全栈上下应统一执行。与其让每个组件使用自定义代码，不如通过一个统一的执行层审计，让应用程序的开发者、运维或安全团队得以关注各自的工作。

Kubernetes 上的零信任

现在，我们必须从第一原则重新思考身份、重新定义信任、用新的执行机制渗透基础设施的所有层面，这么多事情下经历恐慌是正常的。另外，别忘了这些都要在 2024 财年之前完成。

好消息是零信任策略对 Kubernetes 用户在一定程度上会简单很多。尽管 Kubernetes 本身的复杂性和各种缺点，但它是一个范围明确的平台，有着明确的安全模型和明确的扩展机制。这让 Kubernetes 成为实施零信任策略颇具成效的领域。

在 Kubernetes 中实现零信任网络最直接的方法之一是通过 Service Mesh（服务网格）。服务网格利用 Kubernetes 中强大的 sidecar（从容器），将平台容器可以在部署时与应用容器一起动态插入，作为一种后期绑定操作功能的方式。

Service Mesh 的 sidecar 方式可以在运行时将代理添加到程序 pod 中，并将这些代理连接起来以处理所有传入和传出的流量，Service Mesh 以一种与应用程序代码解耦的形式提供功能。应用程序与平台分离是 Service Mesh 价值的核心所在；这些功能当然也可以直接在程序内实现，但将二者分离后，安全团队与开发团队都可在彼此独立迭代的同时，保障程序的安全与功能完备。

由于 Service Mesh 负责处理进出应用程序的流量，它完全有能力达成零信任的条件：

1. 工作负载身份可以从 Kubernetes 中 pod 的身份上获取，而非从 IP 地址中取得。

2. 认证可以通过将连接打包到共同的 TLS 中完成。这是 TLS 的另一种形式，通过加密证明验证连接双方的身份。

3. 授权策略可以以 Kubernetes 所认可的方式进行，举例来说，通过 CRD 明确策略并将其从应用中解耦。

4. 最重要的是，实施可以在栈中以 pod 为单位统一执行。每个 pod 都负责其各自的认证和授权，这意味着网络永远不会被信任。

目前为止，我们实现了零信任大部分的目标（至少对 Kubernetes 集群来说）。我们选择了工作负载的身份而非网络身份，在最低颗粒度级别执行（pod），在不更改程序的前提下实现了应用认证和授权的一致性。

在基本架构内，不同的 Service Mesh 也有其各自的优缺点。例如，开源服务网格同时也是云原生计算基金会的毕业项目，Linkerd 是一个以简洁为最优先目标的实现，直接从 Kubernetes 的服务账户中获取负载身份，通过共同的 TLS 默认实现“零配置”。同样，Linkerd 还通过基于 Rust 的微代理提供最小化实施，达到了零信任的要求。

当然，仅仅是将 Service Mesh 添加到集群中并不能解决问题。在添加完成后，所有的定义、更新以及评估授权策略的工作也都应提上日程。集群的运维人员需要仔细确保所有新增 pod 都能够匹配 sidecar 组件。同时，和集群中所有软件一样，Service Mesh 自身也须维护、监控并保持最新状态。虽然不是万能药，但 Service Mesh 确实提供了一种转变，从集群内默认的不加密非认证的流量传输，转变为默认加密、认证的流量传输、强大的负载身份和丰富的授权系统，我们向零信任的标准迈出了一大步。

结论

零信任是时代安全实践前沿的安全模型，如果我们可以剔除市场上营销的噪音，就能够发现采用这种模式所带来的好处。虽然零信任要求我们彻底改变身份等核心理念，但对于 Kubernetes 用户来说，采用 Service Mesh 具有很大优势，它将纯粹的基于周界网络的安全模式转变为对所有用户、设备、应用程序以及交易进行持续验证的模式。

原文链接：

Article: What Does Zero Trust Mean for Kubernetes?

相关阅读：

利用零信任原则保障 Kubernetes 环境访问安全

一篇文章讲清楚“零信任模型”