1. 传统 CI Secret 的问题，不只是“可能泄漏”#

假设一个 GitHub Actions Workflow 需要把构建产物部署到某个云平台。

传统方案大概是：

1
Cloud Provider
2
    ↓ 创建 Access Key
3
GitHub Repository Secret
4
    ↓ 注入环境变量
5
GitHub Actions Job
6
    ↓ 调用 CLI / SDK
7
Cloud Provider API

这种方式的问题有四层。

1
任务生命周期 = 8 分钟
2
凭据生命周期 = 几个月甚至永久

1
Job 启动
2
  ↓
3
获得短期身份
4
  ↓
5
完成任务
6
  ↓
7
凭据自动失效

1
一个长期、跨环境、跨资源的云账号权限

1
持有者拥有某权限

1
这是 owner/repo 的 main 分支
2
这是 deploy-production.yml
3
这是 production environment
4
这是某个经过审核的 commit

2. GitHub Actions OIDC：CI Job 不再拿固定身份证，而是出示“任务证明”#

GitHub 官方文档对 OIDC 的基本描述非常直接：Workflow 可以从 GitHub 的 OIDC Provider 获取一个短期 Token，并把它交给支持 OIDC 的云服务。

云服务验证这个 Token 的签名和 Claims 后，再发放自己的短期 Access Token。

整体流程是：

1
GitHub Actions Job
2
        │
3
        │ 请求 OIDC Token
4
        ▼
5
GitHub OIDC Provider
6
        │
7
        │ JWT：repo / ref / environment / workflow ...
8
        ▼
9
Cloud Provider / Service
10
        │
11
        │ 验证 issuer + claims
12
        ▼
13
短期访问凭据
14
        │
15
        ▼
16
执行部署 / 上传 / API 操作

这里最关键的一点是：

GitHub 的 OIDC Token 本身通常不是云平台 API Key。

它更像一个由 GitHub 签名的声明：

“我证明现在有一个满足这些条件的 Workflow Job 正在运行。”

真正的资源服务再决定：

“这个 Job 是否有资格换取我的短期凭据？”

这就是 Federation。

3. id-token: write 到底给了什么权限？#

GitHub Actions 中常见配置是：

1
permissions:
2
  contents: read
3
  id-token: write

很多人看到 write 会误以为：

这个 Workflow 获得了“写 GitHub Token”的高危权限。

不是。

这里的 id-token: write 表示允许 Job 向 GitHub OIDC Provider 请求一个 OIDC ID Token。

它并不等于：

1
contents: write
2
packages: write
3
pull-requests: write

也不会自动赋予 AWS、Vercel 或其他第三方权限。

真正决定第三方是否接受这个 Token 的，是第三方的 Trust Policy。

因此安全边界不是：

1
能不能拿 OIDC Token

而是：

1
谁的 OIDC Token
2
在什么条件下
3
能换到什么权限

4. Claims 才是 OIDC 最重要的部分#

一个 OIDC JWT 通常会包含：

1
iss   issuer
2
sub   subject
3
aud   audience
4
exp   expiration
5
nbf   not before
6
iat   issued at

GitHub 还可以携带与 Repository、Workflow、Branch、Environment 等相关的身份信息。

真正安全的 Trust Policy 不应该只写：

1
只要是 GitHub 发的 Token 就行

而应该尽量限制到：

1
特定 organization
2
特定 repository
3
特定 branch / tag
4
特定 environment
5
必要时特定 workflow

可以把它理解为从：

1
“有钥匙的人都能进”

升级成：

1
“只有满足特定上下文的这一次任务能临时进”

这也是 Zero Trust 在 CI 里的一个非常典型实现。

5. 第一条链路：GitHub Actions → Cloud Provider#

这是 OIDC 最经典、最成熟的用法。

例如 GitHub Actions 需要访问 AWS。

传统方式：

1
env:
2
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
3
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

OIDC 方式则更接近：

1
permissions:
2
  contents: read
3
  id-token: write
4

5
steps:
6
  - uses: actions/checkout@v4
7

8
  - name: Configure cloud credentials
9
    uses: cloud-provider/oidc-login-action@...

这里省掉的不是“认证”，而是：

1
不再需要长期保存云平台 Access Key

云平台通过 GitHub OIDC Token 的 Claims 判断这个 Workflow 是否可以 Assume 某个 Role。

最终 Workflow 获得的云凭据应该是：

• 短期；
• 自动失效；
• Scope 较小；
• 可以绑定 Repository / Branch / Environment。

这才是 OIDC 真正改变 CI 安全模型的地方。

6. 第二条链路：Vercel → AWS / Azure / GCP / 自建 API#

这里方向完全反过来了。

Vercel 官方 OIDC Federation 文档描述的是：

1
Vercel Build / Function
2
      ↓
3
Vercel OIDC Identity Provider
4
      ↓
5
外部 Cloud / Backend

也就是说，此时 Vercel 是身份提供方。

Vercel 会为 Build 或 Function 提供 OIDC Token。

在 Build 环境中可以通过：

1
VERCEL_OIDC_TOKEN

获得相关身份。

Vercel 文档还说明，其 Production / Preview OIDC Token 的 TTL 是一小时；Function 场景会在生命周期内处理 Token 缓存与刷新。

这解决的是：

“部署在 Vercel 上的应用如何访问 AWS、Azure、GCP 或其他支持 Federation 的后端，而不保存长期云凭据？”

例如：

1
Vercel Function
2
   ↓ OIDC
3
AWS STS
4
   ↓
5
短期 Role Credential
6
   ↓
7
S3

这和 GitHub Actions 去 Vercel 部署，完全不是同一条链。

7. Vercel 的 aud 与 sub 为什么值得关注#

Vercel OIDC Reference 给出了非常清晰的 Claim 结构。

例如：

1
aud = https://vercel.com/[TEAM_SLUG]

sub 类似：

1
owner:[TEAM_SLUG]:project:[PROJECT_NAME]:environment:[ENVIRONMENT]

这个设计很有价值，因为外部云平台可以把权限绑定到：

1
Team
2
  └── Project
3
       └── Environment

例如只允许：

1
my-team
2
my-api
3
production

访问生产数据库，而 Preview 环境只能访问测试资源。

于是权限模型不再是：

1
Vercel 上所有东西共享一个 AWS Key

而是：

1
不同 project/environment 拥有不同可验证身份

8. 第三条链路：GitHub Actions → Vercel Protected Deployment#

这才是最近几年非常值得关注的一块。

Vercel 的 Deployment Protection 可以让 Preview 或其他 Deployment 处于受保护状态。

以前如果 GitHub Actions 里的 Playwright / Cypress / API Test 想访问这些页面，经常使用：

1
Protection Bypass for Automation

也就是一个长期 Bypass Secret。

请求时发送：

1
x-vercel-protection-bypass: <secret>

这个方案能工作，但仍然存在静态 Secret 的老问题：

1
需要保存
2
需要轮换
3
泄漏后持续有效
4
权限范围可能过大

2026 年 5 月，Vercel 发布 Trusted Sources for Deployment Protection。

它允许受保护 Deployment 接受外部 OIDC Provider 的短期身份，包括 GitHub Actions。

于是链路变成：

1
GitHub Actions
2
    ↓ 请求 OIDC ID Token
3
GitHub OIDC Provider
4
    ↓
5
Vercel Trusted Sources
6
    ↓ 验证 issuer + claims
7
Protected Deployment

调用方把 Token 放在：

1
x-vercel-trusted-oidc-idp-token: <OIDC_TOKEN>

Vercel 再验证：

• Token 签名；
• Issuer；
• 配置的 Claims；
• Environment 规则。

这时 E2E 测试就不一定需要保存长期的 Deployment Bypass Secret。

9. 一个更合理的 GitHub Actions E2E 访问模型#

概念上可以写成：

1
name: E2E Preview
2

3
on:
4
  pull_request:
5

6
permissions:
7
  contents: read
8
  id-token: write
9

10
jobs:
11
  test-preview:
12
    runs-on: ubuntu-latest
13

14
    steps:
15
      - uses: actions/checkout@v4
16

17
      - name: Get GitHub OIDC token
18
        uses: actions/github-script@v7
19
        id: oidc
20
        with:
21
          script: |
22
            const token = await core.getIDToken()
23
            core.setSecret(token)
24
            core.setOutput('token', token)
25

26
      - name: Test protected preview
27
        env:
28
          OIDC_TOKEN: ${{ steps.oidc.outputs.token }}
29
          PREVIEW_URL: ${{ vars.PREVIEW_URL }}
30
        run: |
31
          curl -fsS "$PREVIEW_URL/api/health" \
32
            -H "x-vercel-trusted-oidc-idp-token: $OIDC_TOKEN"

这段代码本身不是完整的生产配置。

真正生产化时还必须在 Vercel Trusted Sources 中限制：

1
Issuer
2
Repository
3
Branch / Environment
4
Audience
5
其他必要 Claims

否则你只是把：

1
“任何拿到 Secret 的人都能访问”

变成：

1
“任何能拿 GitHub OIDC Token 的 Workflow 都能访问”

那仍然太宽。

10. 最容易踩坑的误区：Trusted Sources ≠ Vercel CLI 无 Token 部署#

这是本文最重要的边界。

Vercel Trusted Sources 解决的是：

谁可以访问受 Deployment Protection 保护的 Deployment。

它不是在说：

谁可以调用 Vercel API 创建 Deployment。

截至本文撰写时，Vercel 官方的 GitHub Actions 部署指南仍然使用：

1
VERCEL_TOKEN
2
VERCEL_ORG_ID
3
VERCEL_PROJECT_ID

典型命令仍然是：

1
vercel pull --token=$VERCEL_TOKEN
2
vercel build --token=$VERCEL_TOKEN
3
vercel deploy --prebuilt --token=$VERCEL_TOKEN

所以今天你可以合理做到：

1
GitHub Actions
2
   ├── OIDC → AWS
3
   ├── OIDC → Protected Vercel Preview
4
   └── VERCEL_TOKEN → Vercel CLI Deployment

这是一种“部分去静态密钥”的状态。

不要因为某个平台支持 OIDC，就自动推导出：

1
所有 API 都支持 Token Exchange

必须逐条确认具体产品的认证入口。

11. 为什么这个区别很重要？#

如果误以为 Deployment Protection 的 OIDC 已经等价于 Deployment API 的 OIDC，你可能会做出两种错误设计。

1
GitHub OIDC
2
   ↓
3
自建 API
4
   ↓
5
服务器保存 VERCEL_TOKEN
6
   ↓
7
代替 GitHub 调 Vercel

1
GitHub Secrets

1
你的自建服务

12. 第四条身份：Deployment、访问 Deployment、访问后端，必须分开#

一个完整的现代 Web CI/CD，至少存在三种不同权限：

1
把一个新的版本发布到 Vercel

1
访问被 Vercel Authentication / Password Protection / Trusted IPs 保护的 Preview

1
部署后的 Function 去访问 AWS / GCP / Azure / Database

1
GitHub Actions
2
   │
3
   ├── A. Deployment Auth
4
   │      └── 当前仍可能需要 VERCEL_TOKEN
5
   │
6
   ├── B. Preview Test Auth
7
   │      └── GitHub OIDC → Vercel Trusted Sources
8
   │
9
   └── CI Cloud Access
10
          └── GitHub OIDC → Cloud Role
11

12
Vercel Runtime
13
   │
14
   └── C. Backend Access
15
          └── Vercel OIDC → Cloud Role

13. OIDC 不是“Secret 消失术”，而是 Trust Policy 工程#

OIDC 解决了静态 Secret 的一部分问题，但它把复杂度转移到了另一个地方：

1
Trust Policy

如果 Trust Policy 太宽，OIDC 一样会危险。

例如下面这种思路：

1
所有来自 GitHub 的 OIDC Token 都允许

几乎没有实际安全意义。

更合理的是逐层收紧。

1
katelya77/my-project

1
main
2
production

1
需要的 Bucket
2
需要的 API
3
需要的 Deployment

14. GitHub Environment 是生产 OIDC 设计里非常重要的一层#

如果生产部署已经使用 GitHub Environment，例如：

1
production

那么可以把：

1
Environment Protection Rule
2
OIDC Trust Policy
3
Cloud IAM Role

组合起来。

理想链路是：

1
Commit
2
  ↓
3
Workflow
4
  ↓
5
进入 production environment
6
  ↓
7
人工审批 / branch rule
8
  ↓
9
获得符合 production 条件的 OIDC 身份
10
  ↓
11
换取短期生产权限

这比单纯判断：

1
branch == main

更完整。

因为“能向 main push”与“能执行生产部署”并不一定应该是同一个权限。

15. Pull Request Workflow 要特别警惕 Fork#

OIDC 在 PR 场景里需要额外小心。

因为你必须考虑：

1
这个 Workflow 的代码是谁控制的？

如果一个来自 Fork 的 PR 可以修改 Workflow，然后又能获得足够宽的 OIDC 身份，那么攻击者可能尝试把这个身份发给外部服务。

所以生产级设计通常需要：

• 不让不可信 PR 获得生产 Environment；
• 不让 Fork Workflow 直接拥有敏感 Role；
• Trust Policy 限制 Repository / Ref / Environment；
• 避免在高权限上下文直接执行 PR 提供的任意脚本；
• 对 pull_request_target 保持极高警惕。

OIDC 不会自动解决 Workflow 注入问题。

它只确保：

1
身份是可验证的

至于这个“身份”是否应该被信任，仍然取决于你的 Workflow 与 Policy 设计。

16. 为什么短期 Token 仍然需要 setSecret()？#

Vercel Trusted Sources 官方 GitHub Actions 示例里有一个很值得注意的动作：

1
core.setSecret(token)

有些人会问：

都已经是短期 Token 了，为什么还需要隐藏？

因为：

短期 ≠ 可以公开。

只要 Token 在有效期内，攻击者依然可能利用它。

短期 Token 的优势在于：

1
泄漏窗口有限
2
不可长期复用
3
无需人工轮换
4
可以绑定 Claims

但你仍然必须：

• 不打印到日志；
• 不写入 Artifact；
• 不上传 Cache；
• 不提交回仓库；
• 不通过不可信第三方步骤传播。

17. 从“Secrets 数量”转向“Credential Exposure Surface”#

很多团队评估 CI 安全时会数：

1
Repository Secrets 有多少个？

这不是最好的指标。

更好的指标是：

18. 一个 CI 凭据分级表#

可以把 CI 使用的认证方式按风险简单分级：

注意这张表不是说：

1
OIDC = 绝对安全

它只是说明：

在 Trust Policy 正确的前提下，OIDC 可以显著缩小凭据生命周期和重放窗口。

19. 个人项目该不该折腾 OIDC？#

如果只是一个个人博客，可能有人觉得：

为了一个 Token 搞这么多是不是过度工程？

可以分情况。

1
根本不自己维护额外部署 Token

20. 推荐的迁移顺序：不要一次删光所有 Secret#

如果一个仓库现在有十几个 CI Secret，我更推荐按下面顺序迁移。

1
Secret Name
2
服务商
3
用途
4
Owner
5
权限
6
创建时间
7
过期时间
8
使用 Workflow

1
没人知道用途的 Secret

1
production

1
Scope 最小
2
Environment 隔离
3
定期 Rotation
4
Owner 清晰

21. 一个适合个人开发者的最小架构#

假设你有：

• GitHub Repository；
• GitHub Actions；
• Vercel Preview；
• AWS S3；
• Playwright E2E。

推荐身份链路可以设计成：

1
┌────────────────────┐
2
│ GitHub Actions Job │
3
└─────────┬──────────┘
4
          │
5
          ├──────── OIDC ────────► AWS Role
6
          │                         │
7
          │                         └── S3 最小权限
8
          │
9
          ├──────── OIDC ────────► Vercel Trusted Sources
10
          │                         │
11
          │                         └── Protected Preview
12
          │
13
          └──── VERCEL_TOKEN ────► Vercel CLI
14
                                    │
15
                                    └── Create Deployment
16

17
┌────────────────────┐
18
│ Vercel Function    │
19
└─────────┬──────────┘
20
          │
21
          └──────── OIDC ────────► Backend / Cloud Role

重点不是“完全没有 Token”。

重点是把长期 Token 控制在：

1
目前没有 Federation 替代方案的最小范围

22. 如何做一次可复现的 OIDC 安全实验#

如果你想真正理解 OIDC，而不是只复制 YAML，我建议做四组实验。

1
iss
2
aud
3
sub
4
repository
5
ref
6
environment
7
workflow
8
exp

1
main

1
feature/test

1
认证失败

1
拒绝

1
正常请求是否成功

1
过期 Token 是否确定失败

23. OIDC 的 Benchmark 不该测“速度快了多少”#

这不是一个性能优化功能。

如果一定要量化，更应该统计：

24. OIDC 与 Coding Agent 的关系其实会越来越大#

这件事不只是传统 CI/CD 安全问题。

当 Coding Agent 开始自动：

• 创建 Branch；
• 提交 PR；
• 运行 CI；
• 部署 Preview；
• 执行 E2E；
• 读取 Observability；
• 自动修复；
• 甚至申请 Production 操作；

长期 Token 的问题会被进一步放大。

因为以前是：

1
人触发自动化

未来越来越多是：

1
Agent 触发自动化

这时最危险的设计是：

1
Agent + 永久管理员 Token

更合理的设计应该是：

1
Agent
2
  ↓
3
受控 Workflow
4
  ↓
5
可验证身份
6
  ↓
7
短期凭据
8
  ↓
9
最小权限操作

也就是说，OIDC、Workload Identity、Short-lived Credential 很可能会成为 Agentic Infrastructure 的基础设施，而不仅是 DevOps 的一个安全选项。

25. 最终判断：真正应该追求的不是“Zero Secret”，而是“Zero Standing Privilege”#

“无密钥 CI”听起来很酷，但它不是最终目标。

因为系统永远需要某种身份与授权。

更准确的目标应该是：

不要让高权限长期静态地存在。

也就是尽量接近 Zero Standing Privilege：

1
平时没有持续存在的高权限凭据
2
需要时按身份签发
3
权限与任务绑定
4
时间到自动失效

这也是 OIDC Federation 比“把 Token 换个地方存”更有价值的原因。

对于 GitHub Actions + Vercel，当前最重要的工程认知可以压缩成四句话：

1. GitHub Actions OIDC 可以替代很多 Cloud Provider 长期 Secret。
2. Vercel OIDC Federation 解决的是 Vercel Runtime / Build 向外证明身份。
3. Vercel Trusted Sources 可以让 GitHub Actions 用 OIDC 访问受保护 Deployment，从而减少长期 Automation Bypass Secret。
4. 这不等于 Vercel CLI Deployment 已经全面支持 GitHub OIDC 替代 VERCEL_TOKEN；具体 API 的认证能力必须逐项核验。

下一次当你在 CI 里准备新增一个 Secret 时，可以先问自己：

这个凭据真的需要存在 90 天，还是只需要活 10 分钟？

很多 CI/CD 安全改造，其实就从这个问题开始。

参考资料#

• GitHub Docs — OpenID Connect: https://docs.github.com/en/actions/concepts/security/openid-connect
• Vercel Docs — OpenID Connect (OIDC) Federation: https://vercel.com/docs/oidc
• Vercel Docs — OIDC Federation Reference: https://vercel.com/docs/oidc/reference
• Vercel Changelog — Trusted Sources for Deployment Protection: https://vercel.com/changelog/trusted-sources-for-deployment-protection
• Vercel Docs — Deployment Protection: https://vercel.com/docs/deployment-protection
• Vercel Docs — Protection Bypass for Automation: https://vercel.com/docs/deployment-protection/methods-to-bypass-deployment-protection/protection-bypass-automation
• Vercel Guide — How can I use GitHub Actions with Vercel?: https://vercel.com/kb/guide/how-can-i-use-github-actions-with-vercel