SPIRE、Teleport、IAM Roles Anywhere 与 Vault 对比

一览

四者中有三个讲 SPIFFE。还有一个主要是消费它。

工作负载身份修好了什么——以及它碰都没碰的那一半

真正被解决的那一半

SPIFFE 的机制是证明（attestation），而不是一个存起来的秘密。SPIRE 分两阶段做证明——先证明节点，再证明跑在它上面的工作负载——并据此签发一份 SPIFFE 可验证身份文档，全程不需要预置任何引导秘密。私钥在本地生成，从不传输。X.509 SVID 的默认有效期是一小时，而 agent 会在半衰期前后续签，于是一份不知怎么被截走的凭据，值的是几分钟，而不是一年。对一个智能体进程来说，这严格优于任何「把密钥放进保险库」的安排，单凭这一点就值得做。

没有被解决的那一半

SVID 证明的是一个进程：这个二进制、在这个节点上、在这个命名空间里。它对「智能体此刻在服务的是哪位用户的请求」只字未提，对「本轮的指令是随一份检索到的文档进来的」更是完全无感。这四套系统里的每一个，都会欣然给一个正在执行注入指令的智能体签发一份有效身份，因为从证明层的视角看什么问题也没有——发起调用的确实是那个该发起调用的进程。

那是「被搞糊涂的代理人」，而那是另一个产品。按用户的委托住在同意记录与按任务签发的令牌里；按任务的范围收窄住在你的工具层里；而「上下文里现在是什么」这个问题，住在污点追踪里。工作负载身份是地板。把它当成天花板，团队最后就会拿到一份轮换得极其漂亮、却仍然通向和从前一模一样那个万能角色的凭据。

SPIRE——天花板最高，也是要你自己运维的那个

它做什么

SPIRE 是 SPIFFE 的运行时：一台服务器持有信任域及其注册条目，每个节点上一个 agent 负责节点与工作负载证明，并通过本地的 Workload API socket 提供 SVID。它为 mTLS 签发 X.509-SVID，为做不了 mTLS 的东西签发 JWT-SVID，支持跨信任域联邦，而且是好几套服务网格已经坐在上面的那层底座。

它止步于何处

SPIRE 给你身份，把授权留给你。它的注册条目是一个如今归你所有、并且必须与现实保持同步的策略库——而对智能体集群而言，现实会在某人改了一份部署清单的时候变化。常见的失败不在密码学；而在于一次试点变成了一个比它当初要解决的问题还大的运维项目：一个要跑的数据存储，一堆要回收的条目。

它适合谁

手里不止一朵云、或不止一套编排系统，需要一个厂商中立的信任域，并且已经有平台工程师会把它扛下来的团队。还有任何需要与合作方信任域做联邦的人——这是另外三个都处理得不如它干净的场景。

Teleport——要 SPIFFE，但不要那个注册库

它做什么

Teleport 的 Machine & Workload Identity 通过同样的 Workload API、用同样的信任包，签发同样的 SPIFFE ID 与 SVID，所以标准 SPIFFE SDK 不用改就能用；它也能与 SPIRE 管理的信任域做联邦。差别在策略面：一个 WorkloadIdentity 资源直接映射到 Teleport 既有的基于角色的访问控制，用与其他一切相同的 CLI 和 Terraform provider 管理，不需要再维护一个平行的注册库。

对智能体而言真正要紧的部分

人员访问与工作负载访问跑在同一个控制平面上，落进同一份审计日志。对智能体这摊事来说，这不是便利——这是「『三月份谁或什么碰过这个系统』能用一条查询答出来」与「去连接两个互相对不上的系统」之间的差别。它还支持基于 TPM 的节点证明，并且可以充当 AWS Roles Anywhere 的 CA 信任锚，从而把下面那笔 AWS Private CA 的账去掉。

它适合谁

已经在用 Teleport 管人员访问的组织，以及想要 SPIFFE 平面但不想为它配人的团队。交换很直白：你待在一家厂商的控制平面里，而那套联邦能力，正是让这扇门不至于只能单向通过的东西。

AWS IAM Roles Anywhere——窄、便宜，周五之前就能做完

它做什么

你注册一个信任锚——要么指向 AWS Private CA，要么从你自己的 PKI 上传一张 CA 证书——再注册一个 profile，把这个锚绑定到一个或多个 IAM 角色，并设定会话时长。一个 AWS 之外的工作负载出示自己的证书，就能拿到映射角色的临时 AWS 凭据。服务本身不按请求收费。

它止步于何处

它签发 AWS 凭据，仅此而已。如果你的智能体还要调一个 Postgres 实例、一个内部服务和一个 SaaS API，那 Roles Anywhere 只解决了四分之一的问题，其余部分你又回到了「一个秘密」。它也不是一个通用身份平面：这里没有工作负载证明，只有「持有一张证书」，所以整件事的强度，等于签发这些证书的那个东西的强度。

关于成本的一句话

服务免费，CA 不免费。AWS Private CA 的通用模式约为每月 400 美元，另加按证书计的签发费；短命证书模式大约是它的八分之一——而对智能体来说，你本来要的就是短命证书。换成一个外部 CA（包括由 Teleport 在前面顶着的那种），这条账目就整条消失了。

它适合谁

跑在你自己硬件或另一朵云上、而下游调用压倒性地都是 AWS 的智能体。这是删掉一把静态访问密钥所需的最小工作量，而对很多团队来说，这就是正确的第一步。

Vault——它消费身份比生产身份更在行

它做什么

Vault 干的是身份之后的那一步：把「我是这个工作负载」变成一份会过期的数据库凭据、一张给这条连接用的证书，或一个带撤销路径、带租期的秘密。它的 SPIFFE 认证方法接受并校验由外部权威（比如 SPIRE）签发的 SVID——它自己不生成——而一个 SPIFFE secrets engine 可以铸造 JWT SVID，Vault Enterprise 1.21 则加上了面向非人类工作负载的原生 SPIFFE 身份签发。

这道区分为何要紧

团队们抓起 Vault，以为自己采用了工作负载身份。他们通常拿到的是一个更好的密钥存储，外加把同一个引导问题往下挪了一层：总得有什么东西先向 Vault 证明自己是谁。把它与一个真正的证明来源配对，这个组合非常出色。而如果单独部署它、再把一个 AppRole secret ID 烤进镜像里，你得到的就是一份轮换着的凭据在看守着一份静态凭据。

它适合谁

几乎所有人，作为第二个组件。对「我的智能体需要一个会过期的 Postgres 口令」，它是正确答案；对「证明这是哪个进程」，它是错误答案。

真正拍板的是什么

在这四者之上，那根从不出现在对比表里的轴，是这个身份能打开什么。证明质量确实是一个真实差异——SPIRE 与 Teleport 证明的是「是哪个进程在问」，Roles Anywhere 证明的是「持有一张证书」——但如果 SVID 映射到的是一个什么都能干的角色，这个差异就是二阶的。有用的做法是把你智能体的能力列出来，逐一核对每个身份只打开其中窄窄的一组，也就是戴着 IAM 帽子的爆炸半径问题。

第二根轴是广度。Roles Anywhere 终结于 AWS；Vault 终结于它有 secrets engine 的那些东西；SPIRE 与 Teleport 终结于任何能验证 SVID 的东西，而这在实践中意味着任何同样归你掌控的东西。一个要调三个第三方 SaaS API 的智能体，谁也服务不了它，那部分可达范围仍然留在按用户持有的 OAuth 令牌里。

什么时候选哪个

延伸阅读

本站相关：

• 智能体身份与权限——认证、授权与归属是三个分开的问题。
• 环境权限——任何凭据库都不会列出的那部分可达范围。
• 智能体身份与证明——机制的深入解析。
• 给智能体的受限凭据——收窄这个身份能打开什么。
• 智能体凭据的权限复核——这些授权存在之后该拿它们怎么办。

产品文档：

• SPIFFE 概念与 SPIRE 文档。
• Teleport Workload Identity 与 AWS Roles Anywhere。
• IAM Roles Anywhere 信任模型。
• Vault SPIFFE 认证方法。