零信任是一种强大安全模型,同时也是一个容易被过度营销的概念。那么,究竟什么是零信任呢?对于 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 负责处理进出应用程序的流量,它完全有能力达成零信任的条件:
工作负载身份可以从 Kubernetes 中 pod 的身份上获取,而非从 IP 地址中取得。
认证可以通过将连接打包到共同的 TLS 中完成。这是 TLS 的另一种形式,通过加密证明验证连接双方的身份。
授权策略可以以 Kubernetes 所认可的方式进行,举例来说,通过 CRD 明确策略并将其从应用中解耦。
最重要的是,实施可以在栈中以 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?
相关阅读:
评论