【发布时间】：2020-12-05 16:04:24
【问题描述】：
我一直在研究 Azure DevOps，发现 Azure 管道中有一个非常明显的安全漏洞。
因此，我将管道创建为 YAML 并定义了 2 个阶段：构建阶段和部署阶段。部署阶段如下所示：
- stage: deployApiProdStage
displayName: 'Deploy API to PROD'
dependsOn: buildTestApiStage
jobs:
- deployment: deployApiProdJob
displayName: 'Deploy API to PROD'
timeoutInMinutes: 10
condition: and(succeeded(), eq(variables.isRelease, true))
environment: PROD
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp@1
displayName: 'Deploy Azure web app'
inputs:
azureSubscription: '(service connection to production web app)'
appType: 'webAppLinux'
appName: 'my-web-app'
package: '$(Pipeline.Workspace)/$(artifactName)/**/*.zip'
runtimeStack: 'DOTNETCORE|3.1'
startUpCommand: 'dotnet My.Api.dll'
Microsoft 文档谈到通过向环境添加批准和检查来确保这一点；在上述情况下，PROD 环境。如果此处允许发布到我的 PROD Web 应用程序的受保护资源 - azureSubscription 中的服务连接 - 是从 PROD 环境中提取的，这将很好。不幸的是，据我所知，事实并非如此。它与管道本身相关联。
这意味着当管道首次运行时，Azure DevOps UI 会提示我允许 管道 访问服务连接，这是任何部署发生所必需的。一旦允许访问，该管道就可以永远访问该服务连接。这意味着从那时起，无论为作业指定哪个环境，都可以使用该服务连接。更糟糕的是，指定的任何无法识别的环境名称都不会导致错误，而是会导致默认创建空白环境！
因此，即使我为 PROD 环境设置了手动批准，如果组织中的某个人设法通过我们的代码审查（通过定期大型代码审查这是可能的）将环境名称更改为“NewPROD”在 azure-pipelines.yml 文件中，CI/CD 将创建新环境，并继续并立即部署到 PROD，因为新环境没有检查或批准！
当然，将服务连接与环境相关联是有意义的。有一个选项来禁止自动创建新环境也是有意义的——我真的不知道这有什么特别有用的。目前，据我所知，这是一个巨大的安全漏洞，任何对 repo 有提交访问权限或设法通过批准流程对 azure-pipelines.yml 文件进行更改的人都可以将其部署到关键环境，引入一个主要的单点故障/弱点。广受好评的用于保护管道的增量方法发生了什么变化？我在这里遗漏了什么，还是这个安全漏洞有我想象的那么糟糕？
【问题讨论】：
标签： azure security azure-devops azure-pipelines