关键点零信任是一种被大肆宣传的安全模型，但尽管存在营销噪音，但它对具有安全意识的组织具有一些具体和直接的价值。零信任的核心是将授权从“边境一次验证”转变为“随时随地验证”。为此，零信任要求我们重新思考身份的概念，摆脱基于位置的身份，例如IP地址。Kubernetes采用者在网络层实现零信任时具有明显的优势，这要归功于基于sidecar的服务网格，它提供了无需更改应用程序即可实现的最细粒度的身份验证和授权。虽然服务网格可以提供帮助，但Kubernetes安全性仍然是一个复杂而微妙的话题，需要在多个层面上加以理解。零信任是一种强大的安全模型，处于现代安全实践的前沿。这也是一个容易引起轰动和炒作的术语，因此很难消除噪音。那么，零信任到底是什么，它对Kubernetes意味着什么？在本文中，我们将从工程角度探讨什么是零信任，并构建一个基本框架以了解其对Kubernetes运营和安全团队等的影响。简介如果您正在构建现代云软件，无论是使用Kubernetes还是其他方式，您可能听说过“零信任”一词。零信任安全模型变得如此重要，以至于美国联邦政府已经注意到：白宫最近发布了一份联邦零信任战略备忘录，要求所有美国联邦机构在年底前达到特定的零信任安全标准的一年。2024财年；国防部创建[零信任参考架构]；NSA发布了Kubernetes强化指南，专门描述了Kubernetes中零信任安全的最佳实践。伴随着这股喧嚣，零信任无疑吸引了大量营销关注。但尽管有噪音，零信任不仅仅是一个空洞的术语——它代表了一些关于安全未来的深刻和变革性的想法。那么具体来说，什么是零信任，为什么它突然变得如此重要？零信任对Kubernetes用户意味着什么？什么是零信任？正如所料，零信任从根本上讲是关于信任的。它是一个解决安全核心问题之一的模型：是否允许X访问Y？换句话说，我们是否相信X可以访问Y？当然，零信任中的“零”有点夸张。要使软件正常工作，显然某些东西需要信任其他东西。因此，零信任并不是要完全消除信任，而是要将信任降低到最低限度（称为最小特权原则）并确保它在每一点都得到执行。这听起来像是常识。但与许多新的技术理念一样，了解零信任的最佳方式是了解它的反应。零信任摒弃了边界安全的概念。在边界安全模型中，“装甲”围绕敏感组件实施。例如，数据中心周围可能有防火墙，其作用是将有问题的流量和参与者拒之门外。这个模型有时被称为城堡策略，具有直观的意义：城堡的围墙是用来防止坏人进入的。如果你在城堡里，那么你就是个好人。零信任模型表明边界安全不再足够。根据零信任原则，用户、系统和网络流量仍然必须被视为不受信任，即使在安全范围内也是如此。DoD参考架构很好地总结了这一点：“在安全边界之外或之内运行的任何参与者、系统、网络或服务都是不可信任的。相反，我们必须对任何事物进行身份验证。从每边界一次验证到每一个边界的连续验证用户、设备、应用程序和交易，这是我们保护基础设施、网络和数据的理念的巨大范式转变。”当然，零信任并不意味着扔掉防火墙——纵深防御是任何安全策略的重要组成部分。这也不意味着我们可以忽略所有其他重要的安全组件，例如事件日志记录和供应链管理。零信任只是要求我们将信任检查从“一次在外围”转移到“随时随地”。然而，要正确地做到这一点，我们需要重新考虑一些关于“信任”的含义以及我们如何获取它的基本假设。其中之一身份零信任最直接的影响是它改变了我们思考和分配身份的方式，尤其是系统身份。在边界模型中，位置实际上就是身份。如果你在防火墙内，你是可信的；如果你在外面，你不在外面。因此，基于边界的系统可以允许访问基于客户端IP地址等信息的敏感系统。在零信任世界中，这已经不够了。IP地址只是用于指示位置，所以我t不再足以确定是否可以访问特定资源。相反，我们需要另一种形式的身份：一种以某种方式与工作负载、用户或系统有内在联系的身份。该身份需要以一种本身不需要信任网络的方式进行验证。这是一个具有丰富含义的重大要求。提供网络安全但依赖网络标识符（如IP地址）的系统（如IPSec或Wireguard）不足以实现零信任。策略使用新的身份模型，我们现在需要一种方法来捕获每个身份的访问类型。在上面的边界场景中，一系列IP地址通常被授予对敏感资源的完全访问权限。例如，我们可能会设置IP地址过滤，确保只有防火墙内的IP地址才能访问敏感服务。在零信任的情况下，我们反而需要强制执行必要的最低访问级别。应根据身份和任何其他相关因素尽可能限制对资源的访问。虽然我们的应用程序代码可以自己做出这些授权决定，但我们通常使用在应用程序外部指定的某种形式的策略来捕获它。拥有明确的策略允许我们在不修改应用程序代码的情况下审核和更改访问权限。为了实现我们的零信任目标，这些策略可能非常复杂。我们可能有一个策略，将对服务的访问限制为只有那些需要访问它的服务调用者（即，在双方都使用工作负载身份）。我们可能会更进一步，只允许访问服务上的某些接口（HTTP路由、gRPC方法）。更进一步，根据请求用户身份限制访问。在所有情况下，目标都是最小权限——仅在绝对必要时访问系统和数据。实施最后，零信任要求我们在最细粒度的级别上执行身份验证（确认身份）和授权（验证策略是否允许该操作）。每个授予数据或计算访问权限的系统都应设置从边界到各个组件的安全边界。与策略一样，这种强制执行最好在整个堆栈中统一完成。不是每个组件都使用自己的自定义执行代码，而是使用统一的执行层来促进审计并将应用程序开发人员的关注点与运营和安全团队的关注点分开。Kubernetes零信任我们必须从第一原则重新思考身份，以任意表达策略的形式具体化信任，并将新的执行机制渗透到基础设施的所有层。面对这些需求，我们不可避免地会经历短暂的恐慌。你之前有没有提到它需要在2024财年之前实现？好消息是，至少对于Kubernetes用户来说，采用零信任的某些方面要容易得多。尽管存在缺陷和复杂性，但Kubernetes是一个具有明确范围、定义明确的安全模型和清晰的扩展机制的平台。这使其成为零信任实施的成功领域。在Kubernetes中解决零信任网络问题的最直接方法之一是使用服务网格。ServiceMesh利用了Kubernetes强大的“sidecar”概念，平台容器（译者注：这里指sidecar代理容器）可以在部署时以后期绑定操作函数的形式动态注入应用容器，.服务网格使用这种sidecar方法在运行时向应用程序pod添加代理，并连接这些代理来处理所有传入和传出流量。这允许服务网格以与应用程序代码分离的方式提供功能。应用程序和平台的关注点分离是服务网格命题的一个核心价值：当然，这些功能可以直接在应用程序中实现，但是通过解耦我们允许安全团队和开发人员相互独立迭代，同时仍然朝着安全但功能齐全的应用程序的共同目标。由于服务网格处理应用程序进出的默认网络，它可以很好地处理零信任问题：工作负载身份可以从Kubernetes中的pod身份而不是它们的IP地址派生。身份验证可以通过将连接包装在双向TLS中来执行，双向TLS是一种使用加密信息在连接两端进行身份验证的TLS变体。授权策略可以用Kubernetes术语表达，例如，通过自定义资源定义(CRD)，使策略明确并与应用程序分离。最重要的是，策略在整个技术堆栈的单个pod级别统一执行。每个pod都有自己的身份验证和授权，这意味着网络永远无法信任。所有这些共同实现了我们的大部分零信任目标（至少对于Kubernetes集群而言！）。我们使用工作负载身份而不是网络身份；在最精细的级别(pod)执行，并在整个技术堆栈中以一致和统一的方式应用身份验证和授权，而无需更改应用程序。在基本框架内，不同的服务网格实现提供不同的权衡。例如，Linkerd[5]，一个开源的、CloudNativeComputingFoundation[6]毕业的服务网格项目，提供了一个以简单为目标和专注的实现，直接从KubernetesServiceAccounts中提取工作负载身份以实现“零配置”，相互TLS是默认情况下启用。同样，Linkerd的基于Rust的微代理提供了极简的零信任实现。当然，仅向集群添加服务网格并不是万能的。安装后，定义、更新和评估授权策略的工作必须完成。集群操作员必须注意确保所有新创建的pod与其sidecar组件配对。当然，服务网格本身必须像集群上的任何软件一样进行维护、监控和迭代。然而，灵丹妙药与否，服务网格确实提供了从集群中默认的未加密、未经身份验证的流量到默认的加密、经过身份验证的流量的转变g工作负载身份和丰富的授权系统——这是迈向零信任的一大步。结论零信任是一种强大的安全模型，处于现代安全实践的前沿。如果您能够消除围绕它的营销噪音，那么采用零信任有一些深刻而重要的好处。虽然零信任需要对身份等核心概念进行一些根本性的改变，但如果Kubernetes用户可以采用服务网格并从纯粹基于边界的网络安全转移到“对每个用户、设备、应用程序和事务进行持续验证”，那么他们至少有很大的优势。
