1. Secrets 与 Vars：谁该进保险柜？

secrets.* 存放敏感值（API key、token、私钥）；vars.* 适合非敏感配置（region、feature flag）。 在仓库 Settings → Secrets and variables 中配置；Environment 可以挂更细粒度 secrets（并配合 protection rules）。

2. OIDC 信任链：谁签发 JWT，谁验证，谁发云凭证？

GitHub Actions 作为 OpenID Connect IdP 向 job 签发 id_token（JWT）。 在 AWS 侧通过 IAM 信任策略（sts:AssumeRoleWithWebIdentity）或 Azure/GCP 的 federated credential 校验 subject / audience， 再下发短期凭证给该次 workflow run。

Workflow 必须声明 permissions: id-token: write，否则拿不到 id token。

3. 最小权限：IAM / 角色边界与 trust 条件

在云上为 CI 单独建角色（或 workload identity），并限制： 哪个仓库、哪个分支/tag、哪个 environment 可以 assume。 权限只给部署所需：例如只写特定 ECR 仓库、只对某 S3 前缀 PutObject。

4. AWS 示例：configure-aws-credentials + role

典型模式：仓库只保存 role ARN（可用 vars 或 secrets，视组织策略而定）， 由 action 通过 OIDC 完成 AssumeRoleWithWebIdentity。

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: us-east-1
      - run: aws sts get-caller-identity

Azure / GCP 使用对应官方文档中的 federated credential 与 workload identity；思路一致：信任条件绑定 GitHub 的 OIDC 主体。

5. Secrets 分层：仓库、环境、组织

Environment secrets 适合生产：与 approvals、deployment branches 一起用。 Organization secrets 适合多仓库共享；注意范围与可见性。

6. 审计、轮换与“绝不打印 secrets”

启用云侧与 GitHub 侧审计：谁在何时 assume 了角色、哪次 workflow 触发了部署。 定期轮换仍存在的 secrets；OIDC 让长期密钥数量自然下降。

7. 最小清单

1. 新集成优先 OIDC；避免在仓库里放长期云密钥。
2. Workflow 加 permissions:，且 OIDC 场景必须 id-token: write。
3. 云侧 trust 条件绑定到仓库、分支、environment；IAM 权限最小化。
4. 生产 secrets 放 environment，与审批与环境门禁一致。
5. 禁止在日志中打印 secrets；泄露按事件流程轮换。