一个后端服务半夜要去连数据库、调另一个内部服务,它凭什么证明“我就是那个有权限的服务”?很多团队的答案是:把身份隐式绑在云厂商的 IAM 角色和一大坨长期密钥上。这套做法能跑,但把身份、密钥、云、权限死死焊在一起,越长越重。本文是“工作负载身份”系列第一篇,讲清楚问题出在哪,以及业界标准解法 SPIFFE / SVID 到底给了我们什么。

微服务各管一套权限，最后往往没人说得清谁能调用谁。本文给出统一授权中心的分层架构、协议选择、典型实例与演进路线，重点讲清身份、决策和执行如何分工。

如果要用开源组件搭一个 AWS IAM 风格的授权系统，不能只靠 OpenFGA 或 OPA。更合理的组合是 Keycloak/Dex 做用户身份，SPIFFE/SPIRE 做工作负载身份，STS 服务签发短期角色会话，OpenFGA 表达 trust/resource relationship，OPA 表达 permission policy、condition 和 explicit deny，再由 API Gateway 或服务中间件作为 PEP 执行决策。

SPIRE 系列第四篇：用一个迷你 Python 实验把 Workload Identity 落地，用 JWT-SVID 替代应用侧数据库密码分发，并串起 SPIFFE、SPIRE、Zero Trust 的完整链路。

SPIRE 系列第三篇：从信任链、攻击面、JWT-SVID 风险、Server/Agent 加固和事件响应角度，分析如何把 SPIFFE/SPIRE 用成真正的 Zero Trust 身份层。

SPIRE 系列第二篇：在理解 Workload Identity 与 Zero Trust 目标之后，拆开 SPIRE Server、Agent、Registration Entry、Workload API、部署模式与插件体系。

SPIRE 系列第一篇：从为什么需要 Workload Identity 开始，解释 SPIFFE/SPIRE 的核心概念、落地路径、部署模式和资源成本，为后续架构、安全与实战 Lab 打基础。