Trou de sécurité dans Azure Pipelines ?

Aug 16 2020

J'ai fait des recherches sur Azure DevOps et j'ai découvert ce qui ressemble à une faille de sécurité assez évidente dans les pipelines Azure.

Donc, je crée mon pipeline en tant que YAML et je définis 2 étapes : une étape de construction et une étape de déploiement. L'étape de déploiement ressemble à ceci :

- 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'

La documentation de Microsoft parle de la sécurisation en ajoutant des approbations et des vérifications à un environnement ; dans le cas ci-dessus, l'environnement PROD. Ce serait bien si la ressource protégée ici qui permet la publication sur mon application Web PROD - la connexion de service dans azureSubscription - était extraite de l'environnement PROD. Malheureusement, pour autant que je sache, ce n'est pas le cas. Il est plutôt associé au pipeline lui-même.

Cela signifie que lorsque le pipeline est exécuté pour la première fois, l'interface utilisateur Azure DevOps me demande d'autoriser l'accès du pipeline à la connexion de service, ce qui est nécessaire pour que tout déploiement se produise. Une fois l'accès autorisé, ce pipeline a accès à cette connexion de service pour toujours. Cela signifie qu'à partir de ce moment, cette connexion de service peut être utilisée quel que soit l'environnement spécifié pour le travail. Pire encore, tout nom d'environnement spécifié qui n'est pas reconnu ne provoque pas d'erreur, mais provoque la création d'un environnement vide par défaut !

Donc, même si je configure une approbation manuelle pour l'environnement PROD, si quelqu'un dans l'organisation parvient à glisser un changement via notre révision de code (ce qui est possible, avec des révisions régulières de code volumineux) qui change le nom de l'environnement en 'NewPROD' dans l'azur -pipelines.yml, le CI/CD créera ce nouvel environnement, et procédera au déploiement immédiat sur PROD car le nouvel environnement n'a pas de vérifications ni d'approbations !

Il serait certainement logique que la connexion de service soit plutôt associée à l'environnement. Il serait également logique d'avoir une option pour interdire la création automatique de nouveaux environnements - je ne vois pas vraiment en quoi cela est particulièrement utile de toute façon. À l'heure actuelle, pour autant que je sache, il s'agit d'une énorme faille de sécurité qui pourrait permettre des déploiements dans des environnements critiques par toute personne ayant accès au dépôt ou réussissant à glisser une modification dans le fichier azure-pipelines.yml via le processus d'approbation. , introduisant un point unique majeur de défaillance/faiblesse. Qu'est-il arrivé à l'approche incrémentale tant appréciée pour sécuriser vos pipelines ? Ai-je raté quelque chose ici, ou cette faille de sécurité est-elle aussi grave que je le pense ?

Réponses

1 CeceDong-MSFT Aug 17 2020 at 16:04

Dans votre exemple, il semble que vous ayez créé/utilisé un environnement vide, il n'y a pas de cible de déploiement. Actuellement, seuls les types de ressource Kubernetes et de ressource de machine virtuelle sont pris en charge dans un environnement.

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

La ressource dans votre exemple est une connexion de service, vous devez donc accéder à la connexion de service et définir des vérifications pour cette connexion de service.

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