Azure Pipelines中的安全漏洞？

问题描述

我一直在研究Azure DevOps，并且遇到了Azure管道中一个非常明显的安全漏洞。

因此，我正在将管道创建为YAML并定义了两个阶段：构建阶段和部署阶段。部署阶段如下：

- 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，因为新环境没有检查或批准！

当然应该将服务连接与环境关联。可以选择禁止自动创建新环境也很有意义-无论如何，我真的没有看到它特别有用。据我所知，目前，这是一个巨大的安全漏洞，任何有权限访问存储库或设法通过批准过程将对azure-pipelines.yml文件进行更改的人都可以部署到关键环境。 ，引入了主要的单点故障/弱点。广受赞誉的用于保护管道的增量方法发生了什么？我在这里丢失了什么东西吗？还是这个安全漏洞像我想的那样严重？

解决方法

在您的示例中，似乎您创建/使用了一个空环境，没有部署目标。当前，环境中仅支持 Kubernetes资源和虚拟机资源类型。

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/environments?view=azure-devops

示例中的资源是服务连接，因此您需要转到服务连接并为此服务定义检查。

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass