维度企业做法我们评价部署凭据OIDC 联合身份无长期密钥长期 ed25519 forced command⚠️ 落后但裸 VPS 无IAM 可联合镜像引用digest 钉死digest 钉死✅ 很多团队还在部署 :latest镜像可信cosign 签名 SLSA 溯源 准入控制拒绝未签名仅 Trivy 扫描❌ 最值得补的一项密钥管理Vault / Secrets Manager可轮换可审计服务器上一个 600 的明文文件❌ 最弱环节审批变更管理 职责分离作者不能批自己的必需审批人同一人单人项目的固有限制发布策略金丝雀/蓝绿 SLO 自动回滚up -d 硬切换单节点单用户金丝雀无意义版本可追溯部署标记打进 APM构建→标签→healthz→metrics→部署后核验✅ 比多数小团队做得好数据库迁移独立步骤 expand-contract容器启动时 alembic upgrade head❌ 公认反模式IAM联合是什么文章目录IAM 联合OIDC FederationIAMIdentity and Access ManagementOIDC 联合OpenID Connect Federation为什么这比我们好为什么我们暂时不这么做IAM 联合OIDC Federation这是企业级部署中解决CI 怎么安全地拿到部署权限的标准做法。拆开来说IAMIdentity and Access Management云厂商提供的身份与权限管理系统。核心能力创建角色Role一组权限比如可以拉镜像、“可以部署到 K8s 集群”临时凭证Temporary Credentials不是长期密钥而是有效期很短比如 15 分钟的 token策略Policy精确控制谁能做什么OIDC 联合OpenID Connect Federation让 CI 平台如 GitHub Actions和云平台的 IAM 互相信任不需要给 CI 发任何密钥。工作流程1. GitHub Actions 运行 workflow ↓ 2. GitHub 发一个 OIDC token 给 workflow token 里写着这个 job 来自 repo X 的 branch Y由 workflow Z 触发 ↓ 3. Workflow 拿着这个 token 去找云平台的 IAM ↓ 4. IAM 验证 token 的签名信任 GitHub 是合法的 token 发行方 ↓ 5. IAM 检查repo X 的 branch Y 是否被允许扮演角色 R ↓ 6. 如果允许 → 发放临时凭证有效期 15 分钟 ↓ 7. Workflow 用临时凭证执行部署 ↓ 8. 凭证自动过期即使泄露也无法使用为什么这比我们好OIDC 联合企业我们的做法凭证类型临时 token自动过期长期 ed25519 密钥泄露后果最多 15 分钟有效永久有效直到手动轮换权限粒度可以限制到只有 main 分支的这条 workflow 能部署密钥要么能用要么不能用密钥管理根本没有密钥需要管理密钥存在 GitHub Secrets 里为什么我们暂时不这么做因为我们部署目标是裸 VPS。裸 VPS 没有 IAM 系统——它就是 SSH 登录。你不能让 VPS 去验证一个 OIDC token 然后给你临时 SSH 权限至少没有现成的、简单的基础设施来做这件事。如果将来迁移到托管 K8sEKS/GKE/AKSOIDC 联合就是自然的选择因为云平台原生支持它。但在裸 VPS 上SSH 密钥 forced command 已经是在没有 IAM 的情况下能做到的最合理的方案了。一句话总结裸 VPS 是一台只有 SSH 的远程机器IAM 联合是让 CI 不用拿长期密钥就能安全部署的机制——前者限制了后者所以我们用长期密钥 forced command 来弥补。
)
