介绍
如果你正在构建现代云软件，无论是采用 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 强大的“sidecar”概念，其中平台容器（译者注：此处指 sidecar 代理容器）可以在部署时以后期绑定操作功能的形式，与应用程序容器动态注入到一起，。
服务网格使用这种 sidecar 方法在运行时将代理添加到应用程序 pod 中，并连接这些代理以处理所有传入和传出流量。这允许服务网格以与应用程序代码解耦的方式交付功能。应用程序和平台之间的关注点分离是服务网格主张的核心价值：当然，这些功能可以直接在应用程序中实现，但是通过解耦，我们允许安全团队和开发人员相互独立地迭代，同时仍然努力实现安全但功能齐全的应用程序的共同目标。
由于服务网格处理进出应用程序之间的默认网络，因此它可以很好地处理零信任问题：
- 工作负载身份可以从 Kubernetes 中的 pod 身份而不是其 IP 地址中获取。
- 可以通过在双向 TLS 中包装连接来执行身份验证，这是 TLS 的一种变体，其使用加密信息在连接的两端进行验证。
- 授权策略可以用 Kubernetes 术语表示，例如，通过自定义资源定义 (CRD)，明确策略并并与应用程序解耦。
- 最重要的是，策略在跨技术栈的单个 pod 级别统一执行。每个 pod 都有自己的身份验证和授权，这意味着网络永远不受信任。
所有这些共同实现了我们的大部分零信任目标（至少对于 Kubernetes 集群而言！）。我们使用工作负载身份而不是网络身份；在最细粒度级别（pod）上执行，以及在技术栈中以一致且统一的方式应用身份验证和授权的，而无需更改应用程序。
在基本框架内，不同的服务网格实现提供了不同的权衡。例如， Linkerd[5]是一个开源、Cloud Native Computing Foundation[6] 毕业的服务网格项目，它提供了一个以简单性为目标和重点的实现，直接从 Kubernetes ServiceAccounts 提取工作负载标识来达到“零配置”，默认开启双向 TLS。同样，Linkerd 的基于 Rust 的微代理提供了一个极简的零信任实现。
当然，仅仅在集群中添加一个服务网格并不是万能的。安装后，必须完成定义、更新和评估授权策略的工作。集群运维人员必须小心确保所有新创建的 pod 都与它们的 sidecar 组件配对。当然，服务网格本身必须像集群上的任何软件一样进行维护、监控和迭代。然而，不管是不是灵丹妙药，服务网格确实提供了从集群中默认的未加密、未经身份验证的流量转变为具有强大工作负载身份和丰富授权系统的默认加密、经过身份验证的流量——这是朝着零信任迈出的一大步。
总结
零信任是一种强大的安全模型，处于现代安全实践的前沿。如果可以消除围绕它的营销噪音，那么采用零信任有一些深刻而重要的好处。虽然零信任需要对身份等核心理念进行一些根本性的改变，但如果 Kubernetes 用户能够采用服务网格并从纯粹基于边界的网络安全转变为“对每个用户、设备、应用程序和交易的持续验证”，那么他们至少有很大的优势。
