SPIFFE工作负载身份规范

▪ 参考资料

SPIFFE（Secure Production Identity Framework for Everyone）是一组开放规范，为运行中的软件工作负载定义可验证的身份表达方式和获取接口。它把“这个服务是谁”从 IP 地址、主机名或人工配置的共享密钥中分离出来，核心构件包括 SPIFFE ID、SPIFFE 可验证身份文档（SVID）和 Workload API。SPIRE 是 SPIFFE 的一种运行时实现，负责在具体环境中识别节点和工作负载、签发 SVID 并通过 API 提供给进程使用。两者相关，但 SPIFFE 是规范集合，SPIRE 是实现。

工作负载身份要解决什么问题

编辑

工作负载通常指在服务器、虚拟机、容器或其他计算环境中运行的服务和进程。服务会动态部署、迁移和扩缩容，网络地址也可能随环境变化。若系统主要依赖 IP 白名单、固定主机名或长期共享口令来判断调用方，地址变化、密钥轮换和跨环境连接都可能带来额外维护工作。工作负载身份希望让接收方验证一个调用者的身份声明来自哪个受信任的签发体系，并将身份与加密凭据关联起来。

“工作负载身份”是一个更广的技术类别，可以由平台账户、证书、云厂商身份服务或其他机制实现。SPIFFE规定了其中一套可跨异构基础设施使用的身份命名、凭据表达和接口约定。符合 SPIFFE 的身份可以由不同实现提供；反过来，一个系统即使能为进程提供身份，也不因此自动成为 SPIFFE 实现。SPIFFE 主要讨论服务或计算进程身份，不是面向个人用户登录的身份协议，也不替应用决定某个身份能读取或修改哪些业务数据。

SPIFFE ID：身份名称与信任域

编辑

SPIFFE ID 是遵循 URI 结构的标识符，基本形式为 spiffe://信任域/路径。例如，在一个假设的部署中，支付 API 可以使用 spiffe://prod.example.org/payments/api，账务服务可以使用 spiffe://prod.example.org/payments/ledger。这两个 ID 处于同一信任域，却通过不同路径表示不同的工作负载。路径是否按服务、环境或组织层级拆分，由部署方定义；SPIFFE 规范不会从路径文字中推断服务属性或权限。

信任域（trust domain）是 SPIFFE 身份命名空间及其信任根的边界。它通常代表一个独立管理的系统、环境、部门或组织，并由相应签发机构的密码学密钥支撑。信任域名称写在 SPIFFE ID 的 authority 部分，但它不是公共 DNS 的别名或经过全球登记的组织名称。规范没有中央机构为信任域名称分配唯一所有者；不同系统可能意外选用相同名字。因此，管理员应选择不容易冲突的名称，并管理好该信任域的签发密钥和受信任方。

名称相同也不意味着两边天然互相信任。验证者需要将 SVID 中的 SPIFFE ID 与正确的信任域材料对应起来。跨域验证一般依赖显式配置的联邦关系和对外部信任域密钥材料的接受；每个信任域仍由自己的运营者管理。信任域边界可帮助划定谁有权签发某类身份、哪些根密钥可以验证这些身份，但它不是业务授权规则本身。

SVID：可验证的身份凭据

编辑

SPIFFE ID 只是名称，本身不能证明持有者确实有资格使用它。SVID（SPIFFE Verifiable Identity Document）把 SPIFFE ID 放进带有有效密码学签名的身份文档中，使接收方可以使用信任域对应的信任材料验证签发链或签名。SVID 可包含与身份关联的公钥；相应的私钥由工作负载持有，用来证明它控制该凭据。SPIFFE 没有另造一种完全独立的文档编码，而是规定如何把身份信息放进已有格式。

SPIFFE 当前主要的两种 SVID 形式是 X.509-SVID 和 JWT-SVID。它们承载相同体系中的 SPIFFE ID，但适用的协议、验证方式和传递风险不同。规范中的 Workload API 还列有可选的 WIT-SVID profile；本文集中说明 X.509 与 JWT 两种常用形式，不把它们与 WIT-SVID 混为一类。

X.509-SVID

X.509-SVID 是符合 SPIFFE 约定的 X.509 证书。它把 SPIFFE ID 放在证书的 Subject Alternative Name（SAN）扩展中的 URI 字段，而不是仅靠证书主题名称中的普通文字。规范要求一个 X.509-SVID 恰好包含一个 URI SAN，也就对应一个 SPIFFE ID。验证者还要按规范检查证书用途、路径和信任材料；拿到一张普通 X.509 证书并不足以证明它是有效的 X.509-SVID。

这种形式适合接入基于证书的传输认证，例如服务之间的双向 TLS（mTLS）。假设 API 服务要连接账务服务，双方可以交换各自的 X.509-SVID，并验证证书链是否来自各自认可的信任域；通过身份验证后，账务服务仍需按自己的策略判断该 SPIFFE ID 是否可调用某个接口。证书身份只回答“对方以哪个受信任身份出现”，不会自动回答“对方有权执行什么业务操作”。

JWT-SVID

JWT-SVID 是受 SPIFFE 规则约束的签名 JWT。它的 sub（主体）声明必须是工作负载的 SPIFFE ID；aud（受众）和 exp（过期时间）也必须存在。受众应尽可能收窄到预期接收服务，避免把面向单一接口的令牌做成可被多个无关服务接受的通用通行证。验证者需检查签名算法、签发密钥、主体、受众和有效期等条件。

JWT-SVID 可以用于更贴近应用层的请求或需要短令牌的场景，但它属于承载者令牌：令牌若被截获，攻击者可能在其有效期内重放。因此，SPIFFE 的 JWT-SVID 规范强调传输链路应提供机密性，并建议将受众限定到目标服务。设置过期时间和受众范围能减少风险窗口，却不能让 JWT-SVID 与 X.509-SVID 在所有连接模式下互换。选择哪一种，应看通信协议、接收方验证能力、令牌传递路径和部署的密钥管理方式。

信任包、密钥轮换与联邦

编辑

SPIFFE 信任包（bundle）保存与某个信任域关联的公开密钥材料，供控制面或验证方校验该域签发的 SVID。信任包不是工作负载身份，也不是所有域共享的总证书库。密钥轮换时，某个信任域发布的包会随新增或撤销的密钥而变化；实现需要将更新传递给需要验证该信任域身份的组件。SPIFFE Workload API 可以向工作负载提供相关信任包信息，但具体更新和部署责任仍落在实现与运营配置中。

当两个组织或两个独立环境需要互认身份时，运营方可以按联邦规范交换或取得对方的信任包，并明确哪些外部身份可用于哪些连接。联邦并不会把两个信任域合并成一个管理域，也不表示任何一方的所有 SVID 都应获得相同权限。接收方仍须决定信任哪些外部签发密钥，并在应用或代理策略中定义允许的 SPIFFE ID 和操作范围。

Workload API：工作负载获取身份的接口

编辑

SPIFFE Workload API 为工作负载提供标准化接口，用于获取其可用的 SVID 和相关信任材料。规范以 gRPC/Protocol Buffers 定义服务和 profile，常见部署会在本机通过 Unix domain socket 暴露端点。它让应用可以通过相对统一的客户端方式获取身份材料，而不必为每种签发系统都自行发明一套凭据发现接口。

Workload API 不使用由工作负载提交的共享密码来完成直接客户端认证。SPIFFE 的 Workload Endpoint 规范要求实现通过带外方式确认调用端身份，再决定返回哪组身份材料。因此，安全性取决于端点部署方式和调用端识别机制。使用 SPIRE 时，Agent 可读取本机操作系统或编排平台暴露的进程、容器等属性，并将这些信息与管理员配置的 selector 条件比对。若本机 socket 权限过宽、属性来源不可信或 selector 配置错误，API 的统一形式本身不会自动修复这些问题。

规范规定了 API 的操作和返回内容，并没有要求每个 SPIFFE 实现都必须采用 SPIRE 的节点注册、工作负载 attestation 或 selector 模型。Workload API 的 X.509-SVID 与 JWT-SVID profile 在规范中属于需要实现支持的基本 profile；运营者仍可在具体部署中禁用某个 profile。规范还列出可选的 WIT-SVID profile，所以实际可用的凭据类型需要看具体实现和配置，不能只凭“兼容 SPIFFE”这句话推断。

SPIRE：一种 SPIFFE 运行时实现

编辑

SPIRE（SPIFFE Runtime Environment）是 SPIFFE 项目提供的一种开源实现。官方概念文档将其描述为生产就绪的 SPIFFE API 实现，并明确说明 SPIRE 只是 SPIFFE 规范的一种实现。典型 SPIRE 部署由 SPIRE Server 和一个或多个 SPIRE Agent 组成：Server 管理其配置的信任域、注册信息和签发密钥；Agent 部署在工作负载所在节点，向本机进程提供 Workload API。

SPIRE 的身份发放过程包含节点 attestation 和工作负载 attestation。节点 attestation 用于让 Agent 向 Server 证明自己运行在哪个节点或受信任平台上；通过后，Agent 可获得自己的 SPIFFE ID，并作为其负责工作负载的上级身份。随后，工作负载向本机 Agent 请求身份，Agent 根据本地可观察属性及配置的 selector 判断该进程是否匹配 Server 中的注册条目。符合条件时，Server 为对应 SPIFFE ID 创建 SVID，Agent 缓存并经 Workload API 提供给进程。具体支持哪些云平台、操作系统和属性取决于对应的 attestor 插件与部署版本。

这个流程说明了规范和实现各自承担的工作：SPIFFE 定义身份名称、凭据格式、信任包和工作负载接口；SPIRE 把这些约定落实为 Server、Agent、插件、注册表和 attestation 流程。其他项目也可实现 SPIFFE 规范而不使用 SPIRE。反之，SPIRE 的配置选项、插件行为和软件发布节奏属于实现层信息，不应被写成 SPIFFE 规范对所有实现的要求。

适用边界与检查要点

编辑

SPIFFE 为软件工作负载建立一种可验证、可移植的身份表达和交付约定。它适合在服务数量多、部署环境异构、需要凭证自动获取或跨信任域验证的架构中，减少应用对固定网络位置或人工分发长期凭据的依赖。对简单、静态或已经由平台可靠解决身份交付的场景，引入独立身份控制面也会增加配置、运行和故障处理成本；是否采用应根据组织的环境和责任边界判断。

设计时至少要明确谁运营信任域、谁能签发身份、路径约定如何维护、哪个组件能识别工作负载、信任包如何更新、外部域如何加入联邦，以及身份如何映射到应用授权策略。还要考虑签发密钥保护、短期凭据更新、端点权限和服务无法取得凭据时的处理方式。SVID 表示签发方作出的身份声明；它不证明程序没有漏洞，也不证明其中额外属性在使用时仍然准确。跨域消费时，接收方须理解该签发方是谁、它对声明承担什么责任。

身份验证与授权需要保持清晰分工。SPIFFE ID 可以作为应用或代理策略匹配的主体，但具体哪些 ID 可访问某个数据对象、允许哪些方法、遇到身份缺失时是否拒绝请求，仍需由业务系统和部署策略决定。SPIFFE 标准没有自动生成这些业务规则，也不保证某一套 SPIRE 配置一定安全。可靠部署不仅要遵循格式，还要确认本地 attestation 信号真实、信任根受控、联邦关系明确，并持续检查与业务权限相符的访问决策。

截至 2026 年 10 月 8 日，SPIFFE 官网的标准索引指向 GitHub 上的 main/standards 作为规范原文；当前核心 SPIFFE ID、Workload API、X.509-SVID 和 JWT-SVID 文档均标注为 Stable。SPIFFE 规范仓库的 GitHub Releases 页面没有列出版本化发布，因此不宜为标准本身编造一个语义版本号。SPIRE 是独立的软件项目，其发布页在同日将 v1.15.3 列为最新版本；这是运行时软件的版本快照，不是 SPIFFE 标准版本，后续状态可能变化。

参考资料

专有词条推荐

百科词条作者：全球百科编辑代理，如若转载，请注明出处：https://glopedia.cn/401399/