设计统一 IAM、workload identity 与类 STS 凭据交换层 #45

New Issue

2026-09-10T15:47:17Z

panxiao81 commented

2026-09-10 15:47:17 +00:00

背景

当前执行环境包括 Kubernetes workload、Gitea Actions runner、PVE 临时 VM、未来的 AI Agent、长期非云主机和人工运维。它们已有不同的初始身份证明方式，但尚缺统一的 service account、token exchange、授权与审计抽象。如果继续让 OpenBao 直接承担所有身份建模，容易逐渐演变成以 secret backend 代替 IAM。

已有相关记录：

infrastructure/proxmox/README.md 中的 PVE workload identity 设想
docs/cicd.md 中的 Kubernetes auth、AppRole 与公有云 OIDC federation
OpenBao 继续作为机密、动态凭据和 PKI 后端，而非完整 IAM 控制面

目标

设计一层面向 workload 的统一 IAM/STS 接口：验证不同执行环境提供的初始证明，映射到平台 service account，并签发短期、限定 audience 和 capability 的凭据。既能信任 Kubernetes ServiceAccount，也能向非 Kubernetes workload 注入平台身份。

需要覆盖的身份来源

Kubernetes ServiceAccount JWT
GitHub Actions OIDC JWT；Gitea 暂无等价原生 OIDC issuer，需要独立 bootstrap 路径
公有云 Managed/Instance Identity 或云 STS
PVE 临时 VM 的一次性 wrapped token，未来可评估可信 metadata/vsock
长期主机的 mTLS certificate
人工运维的 OIDC + MFA
无法联合的旧系统 AppRole SecretID

安全边界

初始身份证明只用于交换短期 token，不直接授予业务权限
token 必须限定 issuer、subject、audience、TTL、job/instance generation 与 capability
CI job、runner host、AI Agent、controller 使用不同 service account
不可信代码和模型执行环境不应持有向 Gitea merge、发布评论或读取基础设施 secret 的权限
OpenBao 负责 secret、PKI、动态凭据和审计；IAM 层负责主体、信任关系、授权与 token exchange
保留 break-glass 人工路径，不能让 IAM 自身依赖唯一的 k3s 集群

待决策

service account、role、policy、audience 与 delegation 的数据模型
自建 OIDC issuer/STS，还是采用现有 IAM 产品作为信任核心
OpenBao JWT auth、Kubernetes auth、cert auth 和 AppRole 的边界
Gitea Actions 在没有原生 workload OIDC 时的 bootstrap 方式
controller 代操作与 Agent 自主操作的 capability 划分
token 撤销、轮换、审计事件和异常回收模型

第一阶段交付

写出 threat model 和身份交换时序图
定义最小 service account 与短期 token claims schema
打通 Kubernetes SA JWT -> 平台身份 -> OpenBao 短期凭据
打通 PVE ephemeral runner 的单次 bootstrap
为 Gitea 回写、S3、数据库和 VM/Job 创建分别定义 audience 与最小权限

本 issue 仅记录设计与 PoC，不在第一阶段替换现有 OpenBao 或人工管理入口。

## 背景当前执行环境包括 Kubernetes workload、Gitea Actions runner、PVE 临时 VM、未来的 AI Agent、长期非云主机和人工运维。它们已有不同的初始身份证明方式，但尚缺统一的 service account、token exchange、授权与审计抽象。如果继续让 OpenBao 直接承担所有身份建模，容易逐渐演变成以 secret backend 代替 IAM。已有相关记录： - `infrastructure/proxmox/README.md` 中的 PVE workload identity 设想 - `docs/cicd.md` 中的 Kubernetes auth、AppRole 与公有云 OIDC federation - OpenBao 继续作为机密、动态凭据和 PKI 后端，而非完整 IAM 控制面 ## 目标设计一层面向 workload 的统一 IAM/STS 接口：验证不同执行环境提供的初始证明，映射到平台 service account，并签发短期、限定 audience 和 capability 的凭据。既能信任 Kubernetes ServiceAccount，也能向非 Kubernetes workload 注入平台身份。 ## 需要覆盖的身份来源 - Kubernetes ServiceAccount JWT - GitHub Actions OIDC JWT；Gitea 暂无等价原生 OIDC issuer，需要独立 bootstrap 路径 - 公有云 Managed/Instance Identity 或云 STS - PVE 临时 VM 的一次性 wrapped token，未来可评估可信 metadata/vsock - 长期主机的 mTLS certificate - 人工运维的 OIDC + MFA - 无法联合的旧系统 AppRole SecretID ## 安全边界 - 初始身份证明只用于交换短期 token，不直接授予业务权限 - token 必须限定 issuer、subject、audience、TTL、job/instance generation 与 capability - CI job、runner host、AI Agent、controller 使用不同 service account - 不可信代码和模型执行环境不应持有向 Gitea merge、发布评论或读取基础设施 secret 的权限 - OpenBao 负责 secret、PKI、动态凭据和审计；IAM 层负责主体、信任关系、授权与 token exchange - 保留 break-glass 人工路径，不能让 IAM 自身依赖唯一的 k3s 集群 ## 待决策 - service account、role、policy、audience 与 delegation 的数据模型 - 自建 OIDC issuer/STS，还是采用现有 IAM 产品作为信任核心 - OpenBao JWT auth、Kubernetes auth、cert auth 和 AppRole 的边界 - Gitea Actions 在没有原生 workload OIDC 时的 bootstrap 方式 - controller 代操作与 Agent 自主操作的 capability 划分 - token 撤销、轮换、审计事件和异常回收模型 ## 第一阶段交付 - 写出 threat model 和身份交换时序图 - 定义最小 service account 与短期 token claims schema - 打通 Kubernetes SA JWT -> 平台身份 -> OpenBao 短期凭据 - 打通 PVE ephemeral runner 的单次 bootstrap - 为 Gitea 回写、S3、数据库和 VM/Job 创建分别定义 audience 与最小权限本 issue 仅记录设计与 PoC，不在第一阶段替换现有 OpenBao 或人工管理入口。

panxiao81 commented

2026-09-10 16:40:29 +00:00

设计讨论已收敛，并已拆分为独立项目：panxiao81/workload-sts。

当前确定的边界：

实现标准 OAuth 2.0 Token Exchange 语义，优先复用现有 OAuth2/JWT 库；
验证 Kubernetes ServiceAccount JWT、SPIFFE SVID 等上游 workload 身份；
将身份规范化并按 audience、scope/token profile 与策略条件判断是否允许签发；
签发短期、限定 audience 的 JWT assertion；例如 CI workload 用该 JWT 登录 OpenBao，再由 OpenBao 签发和管理自己的 client token；
OpenBao 继续负责机密、PKI、动态凭据、policy、lease、token renewal/revocation 与审计；
PVE/microVM 的 vsock metadata、attestation 和实例生命周期由独立项目负责，只需向 workload-sts 提供标准 subject token、mTLS 或 SPIFFE 身份；
Gitea Actions 不在本项目中建模：运行于 Kubernetes 时使用 projected ServiceAccount JWT，运行于 VM/microVM 时使用对应环境提供的 workload identity；
workload-sts 自身是无状态 HTTP 服务加数据库，部署位置不是架构边界。

暂定名称和协议身份：

项目：workload-sts
OAuth issuer：identity.ad.ddupan.top
SPIFFE trust domain：homelab.ddupan.top

后续设计、PoC 与实现转移到新仓库，本 issue 关闭。

设计讨论已收敛，并已拆分为独立项目：[panxiao81/workload-sts](https://git.ddupan.top/panxiao81/workload-sts)。当前确定的边界： - 实现标准 OAuth 2.0 Token Exchange 语义，优先复用现有 OAuth2/JWT 库； - 验证 Kubernetes ServiceAccount JWT、SPIFFE SVID 等上游 workload 身份； - 将身份规范化并按 audience、scope/token profile 与策略条件判断是否允许签发； - 签发短期、限定 audience 的 JWT assertion；例如 CI workload 用该 JWT 登录 OpenBao，再由 OpenBao 签发和管理自己的 client token； - OpenBao 继续负责机密、PKI、动态凭据、policy、lease、token renewal/revocation 与审计； - PVE/microVM 的 vsock metadata、attestation 和实例生命周期由独立项目负责，只需向 workload-sts 提供标准 subject token、mTLS 或 SPIFFE 身份； - Gitea Actions 不在本项目中建模：运行于 Kubernetes 时使用 projected ServiceAccount JWT，运行于 VM/microVM 时使用对应环境提供的 workload identity； - workload-sts 自身是无状态 HTTP 服务加数据库，部署位置不是架构边界。暂定名称和协议身份： - 项目：workload-sts - OAuth issuer：identity.ad.ddupan.top - SPIFFE trust domain：homelab.ddupan.top 后续设计、PoC 与实现转移到新仓库，本 issue 关闭。

panxiao81 closed this issue

2026-09-10 16:40:32 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: panxiao81/homelab-infra#45