Дыра в безопасности в Azure Pipelines?

Aug 16 2020

Я изучал 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 - соединение службы в azureSubscription - был извлечен из среды PROD. К сожалению, насколько я могу судить, это не так. Вместо этого он связан с самим конвейером.

Это означает, что при первом запуске конвейера пользовательский интерфейс Azure DevOps предлагает мне разрешить конвейерному доступу к соединению службы, что необходимо для любого развертывания. Как только доступ разрешен, этот конвейер получает доступ к этому сервисному соединению навсегда. Это означает, что с этого момента это служебное соединение может использоваться независимо от того, какая среда указана для задания. Что еще хуже, любое указанное имя среды, которое не распознается, не вызывает ошибки, но по умолчанию создает пустую среду!

Таким образом, даже если я настрою ручное утверждение для среды PROD, если кому-то в организации удастся пропустить изменение через нашу проверку кода (что возможно при регулярных больших проверках кода), что изменит имя среды на NewPROD в лазурном -pipelines.yml, CI / CD создаст эту новую среду и немедленно развернет ее в PROD, потому что новая среда не имеет проверок или одобрений!

Конечно, вместо этого имеет смысл связать сервисное соединение с окружающей средой. Также было бы разумно иметь возможность запретить автоматическое создание новых сред - в любом случае я не понимаю, насколько это особенно полезно. Прямо сейчас, насколько я могу судить, это огромная дыра в безопасности, которая может позволить развертывание в критических средах любому, кто имеет доступ к репо для фиксации или сумел внести изменения в файл azure-pipelines.yml в процессе утверждения. , представляя главную единую точку отказа / слабости. Что случилось с получившим признание поэтапным подходом к защите ваших трубопроводов? Мне что-то здесь не хватает, или эта дыра в безопасности так плоха, как я думаю?

Ответы

1 CeceDong-MSFT Aug 17 2020 at 16:04

В вашем примере казалось, что вы создали / использовали пустую среду, цели развертывания нет. В настоящее время в среде поддерживаются только ресурсы Kubernetes и типы ресурсов виртуальных машин .

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

Ресурс в вашем примере - это соединение службы, поэтому вам нужно перейти к соединению службы и определить проверки для этого соединения службы.