azure - Azure Pipelines 中存在安全漏洞？

Question

我一直在研究 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 应用程序的 protected 资源(azureSubscription 中的服务连接)是从 PROD 环境中提取的，那就没问题了。不幸的是，据我所知，事实并非如此。它与管道本身相关联。

这意味着，当管道首次运行时，Azure DevOps UI 会提示我允许管道访问服务连接，这是进行任何部署所必需的。一旦允许访问，该管道就可以永远访问该服务连接。这意味着从那时起，无论为作业指定哪个环境，都可以使用该服务连接。更糟糕的是，指定的任何无法识别的环境名称不会导致错误，但会导致默认创建一个空白环境!

因此，即使我为 PROD 环境设置了手动批准，如果组织中的某人设法通过我们的代码审查(通过定期的大型代码审查是可能的)进行更改，将环境名称更改为“NewPROD”在 azure-pipelines.yml 文件中，CI/CD 将创建新环境，并立即部署到 PROD，因为新环境没有检查或批准!

当然，将服务连接与环境相关联是有意义的。拥有一个禁止自动创建新环境的选项也是有意义的——无论如何，我真的不明白这有什么特别有用的。目前，据我所知，这是一个巨大的安全漏洞，任何有权访问存储库或设法通过审批流程对 azure-pipelines.yml 文件进行更改的人都可以将其部署到关键环境中，引入主要的单点故障/弱点。广受好评的增量式管道保护方法发生了什么变化？我是否在这里遗漏了一些东西，或者这个安全漏洞是否像我想象的那么糟糕？

Answer 1

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

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

示例中的资源是服务连接，因此您需要进入服务连接并定义对此服务连接的检查。

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