Archived
99 lines
3.9 KiB
Markdown
99 lines
3.9 KiB
Markdown
# 由 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/)
|