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道客博客 » SPIFFE 和 SPIRE：云安全身份验证的标准和实现