摘要

  • id-token: write 只允许 GitHub Actions 的作业或工作流请求 OIDC JSON Web Token；GitHub 明确说明，这一设置本身不授予外部资源的写入权限。
  • 云端提供方还会独立审查配置好的信任条件，并可能以 JWT 换取短期访问令牌；随后资源层的授权决定又是另一道控制面。
  • 可审计的云端授权结论应把工作流修订与受限声明、信任策略版本、交换和会话记录、有效权限语境、资源决定以及按时间分开的目标观察连在一起。

“该流水线通过 OIDC 获得云端访问”可以是一个便于沟通的实施描述；把它当成授权已经成立的结论，却会抹平一连串由不同主体管理的决定。GitHub Actions 可以为被允许请求令牌的作业签发 OpenID Connect 身份令牌。云端提供方可以选择信任 GitHub 的签发方，并检查一组指定声明。交换成功后，作业可能得到短期云端凭据。之后云服务仍会结合角色、资源策略、权限边界、会话策略、组织控制、请求条件以及实际操作来作出判断。每一环都有不同的时间、责任主体与留证位置。

GitHub 在第一环画得很清楚：id-token: write 允许工作流请求并使用 OIDC JWT，并不等于工作流已经可以修改其他资源。因此，发布审查中看见这一权限，不应把它转写成最终权限的描述。审查者所知道的只是一个狭窄事实：该作业具备请求 GitHub 身份令牌的资格。它并不能说明请求是否发生、请求的 audience 是什么、返回了哪些声明、云端是否信任这些声明，或某项云端资源是否随后接受了操作。

云端信任关系是另一份配置，也是另一次独立决定。GitHub 关于云端提供方的说明指出，提供方会验证令牌声明；验证成功后，才会向该作业提供访问令牌。提供方的策略决定了 subject、audience、仓库身份、可复用工作流引用或其他可用声明是否构成准入条件。一枚令牌可以格式正确，却被信任条件拒绝；一项条件可以写得过宽，而预期的声明已缺失或格式变化；令牌已经换出，也可能比发布者以为的权限范围更窄。反过来，即便联邦交换成功，资源策略仍可能拒绝后续请求。

AWS 把这种分离展示得更具体。GitHub 的 AWS 指引要求配置 AWS 信任关系，并建议在角色信任策略中评估 OIDC 的 sub 条件键。GitHub 的 sub 声明存在，并不是 AWS 角色会话存在的记录；角色会话存在，也不是它在某一请求语境下拥有全部有效权限的记录。角色策略、权限边界、会话策略、组织级限制、资源策略和显式拒绝都可能影响一次具体决定。这里并未审计任何 AWS 账户；需要指出的是，“OIDC 已授权部署”这样的笼统说法遗漏了太多待核对的内容。

可复用工作流又提供了一个必须保留实际关联的理由。GitHub 说明，运行于可复用工作流中的作业令牌包含常规作业信息，也可以包含 job_workflow_ref；云端提供方对自定义声明的支持并不相同。仓库里有某个工作流名称，不代表依赖方真的检查了该字段。调用方可以被 GitHub 识别，但未必出现在云端信任条件可评估的声明中。subject 声明的后续定制也可能改变提供方预期的格式。这些都应作为配置事实保留，而不是用“联邦”这个令人安心的词来填补空白。

因此，云端授权应形成一份七段式收据：保存精确的工作流修订、触发 ref、作业身份与 id-token: write 语境；保存请求 audience 与返回声明的受限记录，但不保存可用令牌；保存当时生效的云端身份提供方与信任策略版本；保存交换结果、角色或会话身份及到期时间；保存与拟议操作有关的有效权限语境；保存资源的决定与请求记录；最后，以另一时间点保存目标观察。账户名称、资源标识或数据值可受到保护；重点不是公开凭据，而是保存各环节之间的连接。

来源

  1. GitHub Docs — 在云端提供方中配置 OpenID Connect
  2. GitHub Docs — OpenID Connect 参考
  3. GitHub Docs — 在 Amazon Web Services 中配置 OpenID Connect
  4. GitHub Docs — 在可复用工作流中使用 OpenID Connect