# 由 SPIRE 替代 workload-sts

| 项目 | 内容 |
| --- | --- |
| 状态 | Accepted |
| 日期 | 2026-09-13 |
| 影响 | 停止 workload-sts 开发，不部署现有 PoC |

## 决策

停止实现和部署 workload-sts。workload identity 的签发、轮换、workload attestation 与
OIDC/JWKS federation 改由 SPIRE 提供；OpenBao 继续负责 secret、policy、动态凭据和
自身 token 生命周期。

仓库保留为设计和 PoC 历史，不删除代码，但不再接受功能开发。若未来出现 SPIRE 和目标
Resource Server 无法表达的、已经确认的 token transformation 或 credential
materialization 需求，应基于实际用例重新立项，而不是恢复本规格。

## 原因

workload-sts 原计划自行实现：

```text
验证 Kubernetes 或其他 workload credential
  -> workload principal 映射
  -> audience/scope 策略
  -> 短期 JWT 签发
  -> OIDC metadata/JWKS
```

SPIRE 已原生提供其中决定系统安全性的部分：

- SPIRE Agent 和 Server 执行 node attestation 与 workload attestation；
- Kubernetes workload 可按 namespace、ServiceAccount 等 selector 注册 SPIFFE ID；
- Linux、VM 和容器 workload 可使用 Unix、systemd、Docker 及相应 node attestor；
- workload 通过 SPIFFE Workload API 获取自动轮换的 X.509-SVID 或指定 audience 的
  JWT-SVID；
- SPIRE OIDC Discovery Provider 发布 discovery document 和 JWKS，使支持 OIDC/JWT 的
  Resource Server 可以直接信任 JWT-SVID；
- SPIFFE federation 与 OIDC federation 覆盖后续跨环境信任。

继续开发 workload-sts 会重复实现 attestation 后的身份签发、密钥轮换和 federation，
同时引入新的数据库、策略、签名服务和高价值网络端点，安全收益为负。

## 替代架构

面向 OpenBao 的基本流程为：

```text
workload
  -> local SPIRE Agent Workload API
  -> JWT-SVID (sub = SPIFFE ID, aud = OpenBao audience)
  -> OpenBao JWT auth
  -> OpenBao client token
```

OpenBao 直接按受信 issuer、`sub`、audience 和 bound claims 映射 role/policy。本系统不再
需要 OAuth Token Exchange、内部 principal UUID、Transit JWT signing key 或自己的
JWKS endpoint。

Kubernetes、长期 Linux 主机、PVE VM 和 microVM 的具体 node/workload attestation 由
新的 SPIRE 基础设施项目设计。PVE/microVM 生命周期和 vsock metadata 仍属于平台项目，
不进入身份控制面。

## 不再保留的需求

OAuth `scope` 和集中式 CEL 策略原本作为未来扩展点，但当前没有必须由中间 STS 统一
表达的实际授权需求。OpenBao policy、Kubernetes RBAC 和各 Resource Server 继续负责
最终授权。

如果以后出现下列具体需求，再单独评估小型 broker：

- Resource Server 无法直接验证 JWT-SVID；
- 必须进行跨 trust domain 的 claim/token transformation；
- 必须返回非 JWT 凭据，且 OpenBao 或目标平台不能原生签发；
- 已有明确消费者需要 OAuth RFC 8693，而不能直接使用 Workload API。

仅有“未来可能需要 scope”不足以恢复 workload-sts。

## 后续工作

新的 SPIRE 项目需要决定：

1. SPIFFE trust domain 与 SPIFFE ID 命名规范；
2. SPIRE Server/Agent 的部署和高可用边界；
3. Kubernetes、长期主机及 VM 的 node/workload attestor；
4. registration entry 的声明式管理方式；
5. OIDC Discovery Provider 的稳定 HTTPS issuer；
6. OpenBao JWT auth role、audience 和 SPIFFE ID 映射；
7. SVID TTL、key rotation、federation 与灾难恢复。

## 参考资料

- [SPIRE Use Cases](https://spiffe.io/docs/latest/spire-about/use-cases/)
- [SPIRE Concepts](https://spiffe.io/docs/latest/spire-about/spire-concepts/)
- [Configuring SPIRE](https://spiffe.io/docs/latest/deploying/configuring/)
- [SPIRE OIDC federation and scaling](https://spiffe.io/docs/latest/planning/scaling_spire/)
- [Using SPIRE JWT-SVIDs to authenticate to Vault](https://spiffe.io/docs/latest/keyless/vault/readme/)