无需用户个人访问令牌，实现GitHub Action与Azure DevOps认证

一、采用Azure AD服务主体作为独立身份 #

这是替代个人PAT的企业级最优方案，服务主体是Azure AD中的非用户身份，完全独立于个人账户，适配多仓库、多用户场景：

• 创建服务主体：在Azure AD中注册新的服务主体，为其分配对应权限——发布Azure Artifacts Feed需“贡献者”权限，触发Azure Pipeline需项目级“流水线运行者”或更高权限。
• 配置GitHub Secrets：将服务主体的client-id、client-secret、tenant-id打包为JSON格式，添加为组织级Secrets（而非单仓库），所有仓库可直接引用，减少重复配置。
• 在GHA中获取访问令牌：使用Azure官方azure/login Action完成认证，示例：

- name: Authenticate with Azure AD
  id: login
  uses: azure/login@v1
  with:
    creds: ${{ secrets.AZURE_SERVICE_PRINCIPAL }}

• 发布至Azure Artifacts Feed：用获取到的令牌作为twine的密码（用户名固定为az），示例：

- name: Publish Python Wheel to AAF
  run: |
    twine upload --repository-url https://pkgs.dev.azure.com/[你的组织]/[项目]/_packaging/[Feed名]/pypi/upload/ dist/* -u az --password ${{ steps.login.outputs.accessToken }}

二、组织级Secrets与环境隔离 #

针对数百个仓库的规模，通过以下方式简化维护：

• 所有服务主体凭据统一存储在GitHub组织级Secrets中，避免逐个仓库配置。
• 结合GitHub Environments，为测试、生产等不同环境配置不同权限的服务主体，实现权限隔离，降低风险。

三、触发Azure Pipeline的认证方案 #

同样用服务主体令牌替代个人PAT，通过ADO REST API触发流水线，示例：

- name: Trigger Azure Pipeline
  run: |
    curl -X POST https://dev.azure.com/[你的组织]/[项目]/_apis/pipelines/[流水线ID]/runs?api-version=7.1-preview.1 \
      -H "Authorization: Bearer ${{ steps.login.outputs.accessToken }}" \
      -H "Content-Type: application/json" \
      -d '{"resources": {"repositories": {"self": {"refName": "refs/heads/main"}}}}'

四、权限最小化与安全管控 #

• 遵循最小权限原则：服务主体仅分配完成任务所需的最低权限，比如发布Feed只给“贡献者”，触发流水线只给“运行者”权限。
• 定期轮换服务主体的密钥，建立密钥轮换机制，降低泄露风险。

内容的提问来源于stack exchange，提问作者ini