Azure DevOps跨项目安全集中代码签名流水线构建需求

方案1：流水线触发 + 跨项目工件共享（推荐） #

完全依赖Azure DevOps原生能力，无需额外组件，能严格隔离敏感变量。

集中签名流水线配置 #

• 工件接收与存储：在集中项目下创建Universal Package库（或Pipeline Artifacts），给所有需要签名的项目服务主体分配该库的**“贡献者”（允许上传未签名包）和“读者”**（允许下载已签名包）权限。
• 敏感变量隔离：在集中项目的Library中创建保密变量组，绑定Azure Key Vault的证书相关密钥（如证书密码、Key Vault访问令牌），仅授权集中流水线访问该变量组。
• 签名逻辑：
  1. 添加“下载工件”任务，通过$(Build.RequestedForProjectId)识别触发源项目，拉取对应未签名包。
  2. 从Key Vault获取证书，执行代码签名操作（比如用signtool.exe或对应语言签名工具）。
  3. 将已签名包发布到同一工件库，用{项目ID}-{流水线运行ID}-signed这类唯一标识命名，方便调用项目识别。
• 触发规则：配置集中流水线为**“手动触发+REST API触发”**，禁止自动触发，确保只有授权项目能调用。

各项目流水线配置（仅需2步） #

• 上传未签名包：添加AzureArtifacts.UniversalPackages@0任务，指定集中项目的工件库名称，上传本地未签名包，包名用当前流水线运行ID做标识。
• 拉取已签名包：添加脚本任务，用Azure CLI轮询集中流水线运行状态（az pipelines runs list --project <集中项目名> --definition-id <集中流水线ID> --query "[?contains(name, '<当前运行ID>')].status"），待状态为succeeded后，用同样任务下载对应已签名包到本地，继续后续流程。

方案2：Azure Function中间代理层（更高隔离性） #

如果需要更严格的权限隔离（比如不让各项目直接访问集中项目工件库），可引入Azure Function作为中间层处理包的上传、签名触发和返回。

集中侧配置 #

• 集中签名流水线改为由Azure Function触发，通过Service Principal调用Azure DevOps REST API启动流水线。
• Azure Function配置：
  1. 暴露两个HTTP端点：/upload（接收未签名包）和/download/{requestId}（返回已签名包）。
  2. 将上传的包存储到私有Azure Blob Storage容器，仅Function和集中流水线能访问。
  3. 调用集中流水线REST API，传递requestId参数触发签名流程。
• 集中流水线完成签名后，将已签名包上传到Blob Storage对应requestId的路径，并更新状态为完成。

各项目流水线配置（仅需1行脚本+1步下载） #

• 上传未签名包：用curl或Azure CLI调用Function的/upload端点，获取返回的requestId。
• 轮询并下载：用脚本轮询/download/{requestId}端点，直到获取到已签名包并保存到本地。

关键注意事项 #

• 权限控制：所有敏感资源（Key Vault、集中变量组、Blob Storage）仅授权集中流水线或Azure Function访问，各项目仅拥有上传/下载的最小权限。
• 唯一标识：必须用每个请求的唯一ID（如项目流水线运行ID）关联未签名和已签名包，避免混淆。
• 失败处理：在各项目流水线中添加超时和重试逻辑，处理签名失败情况，比如集中流水线运行失败时终止当前项目流水线并抛出错误。

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