登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

SPIFFE 与 SPIRE 怎样配合工作负载身份

来源:17golang原创

时间:2026-10-26 03:13:14 310浏览 收藏

在云原生环境里,工作负载需要证明“自己是谁”,但这个身份不应该绑定某台机器的固定密钥。SPIFFE 负责定义可移植的工作负载身份规范,SPIRE 则负责在运行环境中完成节点证明、工作负载证明和 SVID 签发。两者不是并列的两个身份产品,而是“规范 + 实现”的关系。

官方地址:https://spiffe.io/docs/latest/spire-about/spire-concepts/

记住一条主线:SPIFFE 规定身份长什么样、怎样被取用和验证;SPIRE 根据平台和进程属性判断工作负载,按注册条件发出短期身份凭据。

先分清 SPIFFE 和 SPIRE 各自负责什么

SPIFFE 是一套面向工作负载的身份框架,核心对象包括 SPIFFE ID、SVID 和 Workload API。SPIFFE ID 是身份名称,通常表现为 URI;SVID 是携带该身份并可被验证的凭据;Workload API 是工作负载取得身份材料的标准接口。

SPIRE 是 SPIFFE API 的一种生产级实现。它由 SPIRE Server 和部署在节点上的 SPIRE Agent 组成:Server 保存注册条件并负责签发,Agent 在本机暴露 Workload API,工作负载通过它取得自己的身份材料。这样,应用不必直接管理长期私钥,也不必把云平台或编排系统的身份细节写进业务代码。

SPIFFE规范对象、SPIRE运行时和工作负载之间的职责边界说明图
图1:职责边界说明图,展示 SPIFFE 的规范对象与 SPIRE 运行组件如何连接到工作负载。

身份链要看四个关键检查点

第一是 registration entry。它把一个 SPIFFE ID 与一组 selector 绑定起来,selector 描述“什么属性的工作负载可以得到这个身份”。因此,登记的不是一个随意字符串,而是身份和匹配条件的组合。

第二是 node attestation。SPIRE Agent 第一次连接 Server 时,需要证明自己运行在哪个可信节点上。证明材料可以来自云平台实例文档、Kubernetes Service Account token、一次性 join token 或其他平台凭据。成功后,Agent 会获得自己的 SPIFFE ID,并成为其负责工作负载的父身份。

第三是 workload attestation。工作负载调用本机 Workload API 时,Agent 会结合操作系统内核、kubelet 等本地信息判断调用进程的属性,再与注册条件中的 selector 比较。节点可信,不代表节点上任意进程都能获得任意工作负载身份。

第四是 SVID 和 trust bundle。匹配成功后,工作负载可以从 Workload API 获得 X.509-SVID、JWT-SVID 以及验证对方身份所需的信任包。X.509-SVID 常用于 mTLS,JWT-SVID 适合需要令牌形式的场景;两者都是 SPIFFE 身份的承载方式,不是 SPIRE 自创的另一套命名体系。

registration entry、selector、两阶段证明和SVID输出之间关系的身份链结构说明图
图2:身份链结构说明图,展示注册条件、两阶段证明与工作负载凭据之间的关系。

出现身份不匹配时怎样分层判断

如果 Agent 无法加入 Server,先看节点证明和 bootstrap bundle;这属于 node attestation 层,不要先修改工作负载 selector。如果 Agent 已经被信任,但工作负载拿不到 SVID,再看调用 Workload API 的进程属性、Agent 的 workload attestor 以及 registration entry 是否覆盖该节点。

如果工作负载拿到了自己的 SVID,但 mTLS 仍失败,检查对端是否信任对应 trust bundle、SPIFFE ID 是否被授权,以及证书是否已经轮换。拿到 SVID 只说明“身份签发成功”,不自动等于业务授权成功;访问控制仍要由服务或网格策略决定。

一份可落地的检查清单

检查项应该看到的结果不能推出的结论
SPIFFE ID名称空间清晰且能代表工作负载不代表已经完成授权
registration entry身份与 selector 的绑定明确不代表任意同节点进程都能匹配
node attestationAgent 获得节点身份不代表工作负载身份已签发
workload attestation调用进程属性与 selector 相符不代表对端一定信任该身份
SVID 与 trust bundle凭据和验证材料可被工作负载取用不代表业务策略已经放行

把这五项按层次记录下来,通常比只查看“有没有证书文件”更容易定位问题。尤其要分别记录 Agent 的节点身份、工作负载的 selector 匹配结果和对端的授权策略。

常见问题

SPIFFE 能不能脱离 SPIRE 使用?

可以。SPIFFE 是规范框架,SPIRE 只是实现之一;只要其他身份提供者遵循 SPIFFE 的 ID、SVID 和 Workload API 约定,就能承担相应角色。实际选型时要单独确认节点证明、工作负载证明和凭据轮换能力。

SPIRE Agent 为什么要部署在每个节点?

因为 Workload API 通常由本地端点提供,Agent 还需要读取调用进程的本地属性来完成工作负载证明。把 Agent 只放在中心节点,会失去“本地识别调用进程”这一关键条件。

总结

SPIFFE 解决的是工作负载身份的统一表达和取用方式,SPIRE 解决的是在具体平台上如何证明节点与进程、如何按注册条件签发身份。排查时按“注册条件—节点证明—工作负载证明—SVID 与信任包—业务授权”逐层判断,就能看清两者如何配合,也能避免把身份签发误认为权限放行。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>