SPIFFE 和 SPIRE:云安全身份验证的标准和实现

01 背景

已过时的网络边界安全模型

在容器化、微服务、公有云和私有云流行起来之前,基于边界的网络模型已经在传统企业内使用了 20 多年。这种安全模型将网络划分为不同的隔离区,不同区域之间又通过防火墙进行隔离,它假设同一隔离区内的任何人都是可信的,隔离区外的任何人都是不可信的。这一模型在近 10 年间暴露出了很多缺陷:

1. 同一隔离区内的网络流量缺乏管控

2. 在动态调度和弹性扩展的云环境下,采用防火墙规则来建立安全边界的方式过于静态,与动态的云环境已完全脱轨。

零信任势在必行

什么是零信任安全模型?其核心概念是 “除非经过验证,否则不相信任何人。” 通过身份验证、权限和访问控制,可以消除对网络和资源的直接访问,建立更精细的访问控制机制。而身份认证这一步骤在零信任中扮演着重要角色,没有完善的身份认证机制,权限和访问控制就无从谈起,这就让我们很容易联想到最传统的身份认证方式:用户名密码和 Bearer token 。在当下,这两种访问凭证不仅很容易被泄露,且通常处于静态或者很久才会更换一次,如果我们想要修改和轮换它们,实施成本往往会很高。

02 SPIFFE:零信任安全模型的基石

SPIFFE 基本概念

受 Netflix、Google、Facebook 等公司的生产基础设施启发,SPIFFE 和 SPIRE 项目提供了一个生产级别的身份认证框架。

SPIFFE ( Secure Production Identity Framework For Everyone ):是一套开源标准,用于在动态和异构环境中安全地识别软件系统。

SPIRE ( SPIFFE Runtime Environment ):是 SPIFFE 标准的一套生产就绪实现,它执行节点证明和工作负载证明,可以安全地向服务颁发身份凭证,并根据预定义的条件集合验证其他服务的身份。

SPIFFE 包含四部分

SPIFFE ID :专门用于标识信任域中工作负载的字符串,也是统一的资源标志符 ( URI )。

SVID ( SPIFFE Verifiable Identity Document ):是工作负载向资源验证自己身份的一个文档,SVID 包含一个 SPIFFE ID ,它能将 SPIFFE ID 编码在一个可加密验证的文件中。

Trust Bundle : 可用于验证 SVID 的公钥包,对 X.509 来说是一堆证书,对 JWT 来说就是一个公钥。

Workload API :工作负载可以使用它来获取自己的 SPIFFE ID 、SVID 和 trust bundle ,并在有更新时收到通知。

图源:https://www.hpe.com/psnow/doc/a50004027enw

SPIFFE 设计目标:

提供一套与平台无关的加密身份验证机制:SPIFFE 是一套标准协议,即任何节点或工作负载都可以通过接入 SPIFFE 协议,跨组织、跨平台,无缝地建立起一个统一的身份认证系统。

自动化管理 SVID 的生命周期:SPIRE 自动颁发、续订短期身份凭证,整个过程无需人工干预即可完成,显著降低了凭证管理相关操作的开销。

短暂可用的身份凭证:SPIRE 可以配置其颁发的身份凭证的有效时间。这样,可以缩小身份凭证泄露后造成的影响范围,并且当身份凭证被弃用时,不需要主动去销毁它。

基于 API 的身份管理机制:SPIFFE 定义了一组标准的工作负载 API ,工作负载可以通过此 API 来获取自己的身份,通过标准化的 API 屏蔽了不同供应商具体实现之间差异,并提升了身份管理的可扩展性。

拓展性:SPIRE 提供了丰富的插件机制,允许运营商和开发人员轻松地接入 SPIRE 。

03 SPIRE 的工作原理

SPIRE 框架

SPIRE 是 SPIFFE 标准的参考实现。SPIRE 由两个组件组成:SPIRE Server (负责创建 SVID 和 trust bundle ) 以及许多 SPIRE Agent 实例 ( 负责向工作负载提供身份 )。

图源:https://spiffe.io/docs/latest/spire-about/spire-concepts/

Server 启动过程

当 Spire Server 启动时,Server 会使用自己的私钥生成一个自签名证书 ( 也可通过上游 CA 机构的插件去请求证书 ),此证书会被用来为信任域中的所有工作负载签发 SVID 。与此同时,如果 Spire Server 是第一次启动,它会生成 Trust Bundle ( 每次签名密钥对轮换时,server 都会更新 trust bundle ),将其存储在数据库中,并通过公开的 API 将其暴露出去,以供 Agent 去访问。然后 Spire Server 会开放注册接口,允许管理员向其发起工作负载注册请求。

注册工作负载的过程

在注册工作负载之前,需要先向 Spire Server 中添加注册条目, Server 中维护着一张注册表,每个注册条目都包含三个字段:

1. SPIFFE ID

2. Parent ID

3. Selector :一组选择器,可以理解为一组标签。

在工作负载证明期间,agent 将会用工作负载的标签与注册条目中的标签做匹配,以确定注册条目,并签发相应的 SVID。

在开始介绍节点证明过程与工作负载证明过程之前,简单回顾一下节点与工作负载的定义:

  • 节点:在计算机系统上下文中运行计算工作负载的逻辑或物理实体,节点是运行工作负载的基础计算系统。
  • 工作负载:是正在运行的应用程序,一般使用特定配置部署同一任务,该配置可以由多个正在运行的实例组成。在云计算里是用来承载计算的工作节点,包括公有云私有云主机系统、Docker 容器节点以及微服务等。

节点证明过程

SPIRE agent 必须伴随着工作负载一起运行。通常来讲,每个裸机服务器、 VM 实例都会运行一个 Spire Agent 实例。

图源:
https://www.hpe.com/psnow/doc/a50004027enw

当 SPIRE agent 启动时,它会首先检索 SPIRE server 之前发布的 trust bundle 。基于 trust bundle ,SPIRE agent 连接到 SPIRE server 并验证 server 的身份。

SPIRE agent 向 SPIRE server 证明其身份的过程称就是“节点证明”。在云实例或 K8s 上,SPIRE agent 可以使用特定于每个云提供商的机制向 server 证明实例的身份。对于裸机实例或 VM,agent 支持其他方法来证明其身份,包括引导 ( Bootstrap ) 证书、字符串连接令牌等。

工作负载证明过程

当工作负载启动时,并不知道自己的 SPIFFE ID 是什么,或者说不知道自己的身份是什么,它需要询问运行在同一个节点上的 Spire Agent “我是谁?”。而 Spire Agent 为了确认工作负载的身份,需要先获取工作负载的 Selector。

这取决于工作负载的运行环境,agent 获取工作负载 Selector 信息的方式略有不同。例如

1. 在 K8s 中,agent 可通过 kubelet 获取到工作负载的 image name、pod name、pod label 等信息

2. 对于直接运行在 unix 域中的进程,agent 可通过插件获取到工作负载的

  • ounix :user 工作负载启动时使用的用户 ( eg : unix : user : nginx )
  • ounix : path 工作负载启动时使用的二进制文件路径 ( eg: /usr/bin/nginx )
  • ounix : sha256 工作负载二进制启动文件的 SHA256 摘要

3. 对于运行在 docker 中的容器,agent 可获取容器的 docker : label 、 docker : env 、 docker : iamge_id 等信息

图源:https://www.hpe.com/psnow/doc/a50004027enw

Agent 会使用这些选择器与 server 中登记的注册条目中的 selector 做匹配,匹配到的条目就是该工作负载的 SVID,例如:

1. 如果一个工作负载在具有 PostgreSQL 标签的云实例上运行,并且其二进制文件与 PostgreSQL 的 SHA256 摘要相同,则为其分配 PostgreSQL 服务的 SPIFFE ID。

2. 如果 K8s 中的一个 pod 具有 front-end 的标签,并且运行在 test namespace 中,则为其分配测试环境 front-end 的 SPIFFE ID ,如:
spiffe://foo.io/test/frontend

值得提出的是,在大规模的集群中,频繁的签发与轮换SVID并不会消耗过多的服务器资源,因为所有的 SVID 都是在 SPIRE 服务器上生成并签名,通过注册条目表中的 SPIFFE ID 与 Parent Id 可以判断出运行 Agent 的节点需要访问哪些 SVID ,Server 只会推送必要的 SVID 至 SPIRE agent ,换句话说,SPIRE agent 永远不会收到他们不需要的的 SVID ,这样可以有效的提升性能,同时规避 SVID 大规模泄露的情况。

04 采用 SPIFFE和 SPIRE 的优势

1. 因为任何工作负载之间的访问都必须经过身份认证,所以当工作负载受到攻击时,可以通过快速锁定身份的攻击源,减小被进一步攻击的可能性。

2. 降级运维工作的复杂程度,通过一致的、自动化的身份管理,有效降低运维成本。

3. 完善了安全方面的可观测性,相互通信的工作负载双方都明确知道对方的身份,所以日志和审计工作将会变得更加轻松。

05 总结

随着新兴基础架构技术的发展,云安全模型也在不断发展。SPIFFE 和 SPIRE 通过使用现代标准化的安全身份验证方式,解决了云原生工作负载安全方面的问题,且可以与多种云原生技术进行集成,包括 Istio 、 Envoy、gRPC 和 Open Policy Agent ( OPA ) 等。从长远来看,SPIFFE 的明确规范形式将改变应用程序的安全性,在实现更安全的云原生生态系统方面,发挥关键作用。


本文作者

程锐

云原生研究院产品经理


参考链接:

https://spiffe.io/docs/latest/spiffe-about/overview/

DaoCloud 公司简介:「DaoCloud 道客」云原生领域的创新领导者,成立于 2014 年底,拥有自主知识产权的核心技术,致力于打造开放的云原生操作系统为企业数字化转型赋能。产品能力覆盖云原生应用的开发、交付、运维全生命周期,并提供公有云、私有云和混合云等多种交付方式。成立迄今,公司已在金融科技、先进制造、智能汽车、零售网点、城市大脑等多个领域深耕,标杆客户包括交通银行、浦发银行、上汽集团、东风汽车、海尔集团、屈臣氏、金拱门(麦当劳)等。目前,公司已完成了 D 轮超亿元融资,被誉为科技领域准独角兽企业。公司在北京、武汉、深圳、成都设立多家分公司及合资公司,总员工人数超过 400 人,是上海市高新技术企业、上海市“科技小巨人”企业和上海市“专精特新”企业,并入选了科创板培育企业名单。

未经允许不得转载:DaoCloud道客博客 » SPIFFE 和 SPIRE:云安全身份验证的标准和实现

申请试用