octo-sts：GitHub的STS

这个仓库包含一个名为octo-sts的GitHub应用，它作为GitHub API的安全令牌服务（STS）。使用这个应用，实质上可以在任何能生成OIDC令牌的地方运行的工作负载都可以与这个应用的STS API联合，以生成用于与GitHub交互的短期令牌。

这个应用的最终目标是完全消除对GitHub个人访问令牌（即PAT）的需求。

原始博客文章。

设置工作负载信任

为了让应用生成能在您的组织中使用的凭证，必须将其安装到组织中，并允许访问您希望工作负载能够交互的任何仓库。不幸的是，由于GitHub应用的限制，该应用必须请求联合所需权限的超集，因此应用请求的完整权限集将很大，但除了一个例外（contents: read读取策略文件），应用只根据您配置的"信任策略"创建具有这些范围的令牌。

信任策略

信任策略保存在.github/chainguard/{name}.sts.yaml中，包含几个关键部分：

1. 联合的声明匹配条件，
2. 授予身份的权限，
3. （对于组织级策略）授予访问权限的仓库列表。

这是一个简单示例，允许chainguard-dev/foo中在main分支上运行的GitHub Actions工作流读取仓库内容并与问题交互：

issuer: https://token.actions.githubusercontent.com
subject: repo:chainguard-dev/foo:ref:refs/heads/main

permissions:
  contents: read
  issues: write

信任策略还可以使用正则表达式匹配发行者、主题，甚至自定义声明。例如：

issuer: https://accounts.google.com
subject_pattern: '[0-9]+'
claim_pattern:
  email: '.*@chainguard.dev'

permissions:
  contents: read

这个策略将允许具有Chainguard电子邮件地址的Google账户的OIDC令牌进行联合并读取仓库内容。

联合令牌

GitHub应用实现了Chainguard SecurityTokenService GRPC服务定义，见此处。

如果发送适合联合的${TOKEN}，如下所示：

curl -H "Authorization: Bearer ${TOKEN}" \
  "https://octo-sts.dev/sts/exchange?scope=${REPO}&identity=${NAME}"

应用将尝试从${REPO}的.github/chainguard/${NAME}.sts.yaml加载信任策略，如果提供的${TOKEN}满足这些规则，它将返回一个具有信任策略中权限的令牌。