网站公司的未来,老鹰网站建设,如何免费做网页,哪一个景区网站做的最成熟这篇是 Buoyant 的创始人 William Morgan 文章《# What Does Zero Trust Mean for Kubernetes?》[1]的翻译#xff0c;文章很好的解释了什么是零信任、为什么要实施零信任#xff0c;以及服务网格如何以最小的代码实现零信任。零信任是营销炒作#xff0c;还是新的机会文章很好的解释了什么是零信任、为什么要实施零信任以及服务网格如何以最小的代码实现零信任。零信任是营销炒作还是新的机会各位看官你怎么看要点零信任是一种被大量炒作的安全模型但尽管存在营销噪音但它对于具有安全意识的组织具有一些具体而直接的价值。零信任的核心是将授权从“在边界验证一次”转变为“随时随地验证”。为此零信任要求我们重新思考身份的概念并摆脱基于位置的身份例如 IP 地址。Kubernetes 采用者在网络层实现零信任时具有明显的优势这要归功于基于 Sidecar 的服务网格它提供无需更改应用程序就可实现的最细粒度的身份验证和授权。虽然服务网格可以提供帮助但 Kubernetes 安全性仍然是一个复杂而微妙的话题需要从多个层次进行了解。零信任[2]是一种位于现代安全实践前沿的强大的安全模型。这也是一个容易引起轰动和炒作的术语因此很难消除噪音。那么究竟什么是零信任对于 Kubernetes它究竟意味着什么在本文中我们将从工程的角度探讨什么是零信任并构建一个基本框架来理解它对 Kubernetes 运维和安全团队等的影响。介绍如果你正在构建现代云软件无论是采用 Kubernetes 还是其他软件可能都听说过“零信任”一词。零信任的安全模式变得如此重要以至于美国联邦政府已经注意到白宫最近发布了一份联邦零信任战略的备忘录[3]要求所有美国联邦机构在年底前满足特定的零信任安全标准。2024财年国防部创建了[零信任参考架构](https://dodcio.defense.gov/Portals/0/Documents/Library/(U 零信任参考架构)ZT_RA_v1.1(U)_Mar21.pdf)美国国家安全局发布了一份Kubernetes 强化指南[4]专门描述了 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 用户能够采用服务网格并从纯粹基于边界的网络安全转变为“对每个用户、设备、应用程序和交易的持续验证”那么他们至少有很大的优势。关于作者William MorganWilliam Morgan是 Buoyant 的联合创始人兼首席执行官Linkerd 的创建者。在加入 Buoyant 之前他是 Twitter 的一名基础架构工程师在那里他帮助将 Twitter 从单体架构转变为微服务。他是 Powerset、Microsoft 和 Adap.tv 的软件工程师以及 MITRE 的研究科学家。参考资料[1] 《# What Does Zero Trust Mean for Kubernetes?》: https://www.infoq.com/articles/zero-trust-k8s/[2] 零信任: https://en.wikipedia.org/wiki/Zero_trust_security_model[3] 发布了一份联邦零信任战略的备忘录: https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf[4]Kubernetes强化指南: https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/0/CTR_Kubernetes_Hardening_Guidance_1.1_20220315.PDF[5] Linkerd: https://linkerd.io/[6] Cloud Native Computing Foundation: https://www.cncf.io/
