每次部署到生产环境都要在审批流前面卡半小时，你以为这是安全——今天这件事被 OIDC custom properties 从根上彻底变了

阿监·前端工程化 内容创作者 2026-09-01 86 阅读

每次部署到生产环境都要在审批流前面卡半小时，你以为这是安全——今天这件事被 OIDC custom properties 从根上彻底变了。

GitHub Actions 的 environment protection rules（审批流、wait-timer、branch filter）一直是生产环境部署的标准守卫。但这套机制有个根本限制：它只看「谁来审批」，不看「这个仓库是什么属性」。一个财务报销系统和开源博客只要审批人一样，就用同一套云端权限——这显然不对。

OIDC custom properties 把这件事翻过来了。

它解决了什么问题

传统 OIDC trust policy 长这样：

{
  "StringEquals": {
    "tokens.googleapis.com/sub": "github-actions[bot]@github.com"
  }
}

问题在于：它只认「这是 GitHub Actions 发起的请求」，不认「这是哪个仓库、哪个环境、哪个团队发起的」。

结果是：要么把权限写得很粗（所有仓库共用同一个 IAM role），要么为每个仓库单独配置（维护成本爆炸）。

Custom properties 怎么接进来

今年 4 月，GitHub Actions OIDC tokens 正式支持把仓库的自定义属性（custom properties）作为 claims 写进 token 里。Custom properties 是 GitHub 去年推出的仓库元数据管理功能，你可以给仓库打标签，比如 environment-type: production、team: payments、compliance-tier: soc2。

现在这些标签可以直接作为 OIDC claims 使用：

{
  "StringEquals": {
    "tokens.googleapis.com/sub": "github-actions[bot]@github.com",
    "tokens.googleapis.com/custom_properties/environment-type": "production",
    "tokens.googleapis.com/custom_properties/team": "payments"
  }
}

这样云端 trust policy 不再需要枚举具体仓库 ID，只要仓库拥有特定的 custom property 标签，就能自动获得对应权限。

实际用法

第一步：给仓库打标签（Organization 设置里批量配置）

# 仓库 A
custom-properties:
  environment-type: production
  team: payments
  compliance-tier: soc2

第二步：云端配置 trust policy

AWS IAM trust policy 大致如下：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::123456789:oidc-provider/tokens.googleapis.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "tokens.googleapis.com:aud": "https://github.com/org",
        "tokens.googleapis.com/custom_properties/environment-type": "production",
        "tokens.googleapis.com/custom_properties/compliance-tier": "soc2"
      }
    }
  }]
}

第三步：Workflow 里直接用，不需要改

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/github-actions-production
          aws-region: us-east-1

只要仓库打上了 environment-type: production，这个 workflow 跑起来就能拿到生产权限——不需要在 workflow 里写死任何 secret。

解决了哪些具体的坑

坑一：仓库多了不知道怎么管权限

以前：每个 prod 仓库单独配一个 IAM role，或者所有仓库共用一个粗粒度 role（安全风险）。

现在：按 custom property 分组，一个 policy 管一批仓库。

坑二：新建仓库要等 DevOps 配置权限

以前：新仓库上线要手动在 AWS 里建 role、改 trust policy。

现在：只要仓库打上标签，云端自动识别，workflow 直接跑通。

坑三：审计的时候分不清谁有权限

以前：IAM role 和仓库是两张账，对不上。

现在：custom property 就是权限标签，仓库标签 + 云端 policy 一一对应，审计路径清晰。

迁移路径

如果你已经在用 OIDC（没用 custom properties），升级路径很平滑：

  1. 先在测试环境验证——给一个测试仓库打上 custom property，确认 token claims 里有这个字段
  2. 修改 trust policy 的 condition——把原来的仓库白名单替换成 custom property 条件
  3. 批量给仓库打标签——Organization 层面可以用 CSV 批量导入
  4. 逐步切换——新策略只对打标的仓库生效，老配置保持兼容

三步下一步

  1. 查现状：你的 AWS account 里有多少个 OIDC trust policy？每个对应哪些仓库？有没有用 custom properties？
  2. 选标签：哪些 custom property 最值得作为权限维度？常见选项：environment-type、team、compliance-tier、data-sensitivity
  3. 改一个试：挑一个非关键环境，按上面的三步走一遍，验证 token claims 确实带了 custom property

GitHub Actions 环境保护规则的价值在于「人肉审批」，但真正的权限最小化要靠「身份属性」而不是「人肉判断」。OIDC custom properties 把这件事从「谁批的」变成了「这个仓库是什么属性」——审批流还是审批流，但权限的根已经从信任人变成了信任属性。

评论区

0 条评论

登录后可评论。

阿监·前端工程化 86 阅读