Partager via

Accès sécurisé à Azure Repos à partir de pipelines

  • Article

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Vos référentiels sont essentiels pour la réussite de votre entreprise, car ils hébergent le code qui alimente vos opérations. L’accès aux référentiels doit être soigneusement contrôlé. Cet article vous guide sur l’amélioration de la sécurité du pipeline de build et du pipeline de mise en production Classique lors de l’accès à Azure Repos pour atténuer le risque d’accès non autorisé.

Pour garantir un accès sécurisé aux référentiels Azure, activez les bascules suivantes :

  • Limiter l’étendue d’autorisation de travail au projet actuel pour les pipelines sans mise en production
  • Limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines de mise en production
  • Protéger l’accès aux dépôts dans les pipelines YAML

Processus De base

Les étapes suivantes pour sécuriser vos pipelines sont similaires dans tous les pipelines :

  1. Identifiez les dépôts Azure Repos auxquels votre pipeline a besoin d’accéder au sein de la même organisation, mais dans différents projets.
    Pour ce faire, inspectez votre pipeline ou activez l’étendue d’autorisation de travail limite au projet actuel pour les pipelines (non)de mise en production et notez quels référentiels votre pipeline ne parvient pas à extraire. Les dépôts de sous-modules peuvent ne pas s’afficher lors de la première exécution ayant échoué.
  2. Accordez l’accès d’identité de build du pipeline à ce projet pour chaque projet qui contient un référentiel auquel votre pipeline doit accéder.
  3. Accordez à l’identité de build du pipeline l’accès en lecture à ce référentiel pour chaque dépôt que votre pipeline extrait.
  4. Accordez à l’identité de build du pipeline l’accès en lecture à ce référentiel pour chaque dépôt utilisé comme sous-module par un référentiel que votre pipeline extrait et se trouve dans le même projet.
  5. Activez l’étendue Limiter l’autorisation de travail au projet actuel pour les pipelines sans mise en production, limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines de mise en production et protéger l’accès aux référentiels dans les pipelines YAML.

Pipelines de build

Pour illustrer les étapes à suivre pour améliorer la sécurité de vos pipelines lorsqu’ils accèdent à Azure Repos, nous utilisons l’exemple suivant.

  • Supposons que vous travaillez sur le SpaceGameWeb pipeline hébergé dans le fabrikam-tailspin/SpaceGameWeb projet, dans le SpaceGameWeb référentiel Azure Repos.
  • Votre SpaceGameWeb pipeline extrait le SpaceGameWebReact référentiel dans le même projet et les FabrikamFiber référentiels FabrikamChat du fabrikam-tailspin/FabrikamFiber projet.
  • Le FabrikamFiber référentiel utilise le FabrikamFiberLib référentiel comme sous-module, hébergé dans le même projet.
  • Les SpaceGameWeb structures de dépôt du projet ressemblent à celles de la capture d’écran suivante. Capture d’écran de la structure du référentiel SpaceGameWeb.
  • FabrikamFiberLes structures de référentiel du projet ressemblent à celles de la capture d’écran suivante. Capture d’écran de la structure du référentiel FabrikamFiber.
  • Imaginez que votre projet ne soit pas configuré pour utiliser une identité de build basée sur le projet, ni pour protéger l’accès aux référentiels dans les pipelines YAML. Supposons également que vous avez déjà exécuté votre pipeline.

Utiliser une identité de build basée sur un projet pour les pipelines de build

Pendant l’exécution du pipeline, une identité est utilisée pour accéder aux ressources, telles que les référentiels, les connexions de service et les groupes de variables. Les pipelines peuvent utiliser deux types d’identités : au niveau du projet et au niveau de la collection. L’ancien hiérarchise la sécurité, tandis que celui-ci met l’accent sur la facilité d’utilisation. Pour plus d’informations, consultez l’étendue des identités de build et de l’étendue d’autorisation du travail.

Pour améliorer la sécurité, utilisez des identités au niveau du projet lorsque vous exécutez vos pipelines. Ces identités peuvent uniquement accéder aux ressources au sein de leur projet associé, ce qui réduit le risque d’accès non autorisé par des acteurs malveillants.

Pour configurer votre pipeline afin d’utiliser une identité au niveau du projet, activez l’étendue Limite d’autorisation du travail au projet actuel pour le paramètre de pipelines sans mise en production.

Dans notre exemple en cours d’exécution, lorsque ce bouton bascule est désactivé, le SpaceGameWeb pipeline peut accéder à tous les référentiels dans tous les projets. Lorsque le bouton bascule est activé, SpaceGameWeb peut uniquement accéder aux ressources du fabrikam-tailspin/SpaceGameWeb projet, donc uniquement aux référentiels SpaceGameWeb et SpaceGameWebReact .

Si vous exécutez notre exemple de pipeline, lorsque vous activez le bouton bascule, le pipeline échoue et les journaux d’erreurs vous remote: TF401019: The Git repository with name or identifier FabrikamChat does not exist or you do not have permissions for the operation you are attempting. indiquent et remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Pour résoudre les problèmes d’extraction, suivez les étapes décrites dans la section Processus de base de cet article.

En outre, consultez explicitement les référentiels de sous-modules avant les référentiels qui les utilisent. Dans notre exemple, il s’agit du FabrikamFiberLib référentiel.

Si vous exécutez notre exemple de pipeline, il réussit.

Configuration supplémentaire

Pour améliorer davantage la sécurité lorsque vous accédez à Azure Repos, envisagez d’activer Protéger l’accès aux référentiels dans des pipelines YAML.

Supposons que le SpaceGameWeb pipeline est un pipeline YAML et que son code source YAML ressemble au code suivant.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md
  - ...

Protéger l’accès aux référentiels dans les pipelines YAML

Azure DevOps fournit un mécanisme d’autorisations fragmenté pour les référentiels Azure Repos, sous la forme de paramètre Protéger l’accès aux référentiels dans les pipelines YAML. Ce paramètre permet à un pipeline YAML de demander explicitement l’autorisation d’accéder à tous les référentiels Azure Repos, quel que soit le projet auquel ils appartiennent. Pour plus d’informations, consultez les dépôts d’accès. Ce paramètre n’affecte pas l’extraction d’autres types de référentiels, tels que les référentiels hébergés par GitHub.

Dans notre exemple en cours d’exécution, lorsque ce paramètre est activé, le SpaceGameWeb pipeline demande l’autorisation d’accéder au SpaceGameWebReact référentiel dans le fabrikam-tailspin/SpaceGameWeb projet et aux FabrikamFiber FabrikamChat référentiels du fabrikam-tailspin/FabrikamFiber projet.

Lorsque vous exécutez l’exemple de pipeline, celui-ci est similaire à l’exemple suivant.

Capture d'écran de la première exécution du pipeline SpaceGameWeb après avoir activé l'option Protéger l'accès aux référentiels dans les pipelines YAML.

Accordez l’autorisation à vos référentiels ou ressources de pipeline.

Capture d'écran montrant qu'il est demandé au pipeline SpaceGameWeb d'autoriser l'accès à trois référentiels.

Votre pipeline s’exécute, mais échoue, car il ne peut pas extraire le FabrikamFiberLib référentiel en tant que sous-module de FabrikamFiber. Pour résoudre ce problème, vérifiez explicitement le FabrikamFiberLib, en ajoutant une - checkout: git://FabrikamFiber/FabrikamFiberLib étape avant l’étape -checkout: FabrikamFiber .

L’exemple de pipeline réussit.

Notre code source de pipeline YAML final ressemble à l’extrait de code suivant.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: git://FabrikamFiber/FabrikamFiberLib  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md

Dépannage

Utilisez les solutions suivantes pour tous les problèmes qui surviennent.

Vous utilisez git dans la ligne de commande pour extraire des référentiels dans le même organisation

Par exemple, si vous utilisez - script: git clone https://$(System.AccessToken)@dev.azure.com/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/. La commande échoue lorsque le paramètre Protéger l’accès aux référentiels dans le paramètre de pipelines YAML est activé.

Pour résoudre le problème, consultez le OtherRepo référentiel à l’aide de la checkout commande, par - checkout: git://FabrikamFiber/OtherRepoexemple .

Un dépôt utilise un autre dépôt comme sous-module

Supposons que l’un des référentiels que votre pipeline extrait utilise un autre référentiel (dans le même projet) comme sous-module, comme c’est le cas dans notre exemple pour les référentiels FabrikamFiber et FabrikamFiberLib . En savoir plus sur la façon d’extraire des sous-modules.

En outre, supposons que vous avez donné à SpaceGamel’identité de build l’accès en lecture à ce référentiel, mais que l’extraction FabrikamFiber du référentiel échoue toujours lors de l’extraction du FabrikamFiberLib sous-module.

Pour résoudre ce problème, vérifiez explicitement le FabrikamFiberLib, en ajoutant une - checkout: git://FabrikamFiber/FabrikamFiberLib étape avant celle-ci -checkout: FabrikamFiber .

Pipelines de mise en production classiques

Le processus de sécurisation de l’accès aux référentiels pour les pipelines de mise en production est similaire à celui des pipelines de build.

Pour illustrer les étapes à suivre, nous utilisons un exemple en cours d’exécution. Dans notre exemple, il existe un pipeline de mise en production nommé FabrikamFiberDocRelease dans le fabrikam-tailspin/FabrikamFiberDocRelease projet. Supposons que le pipeline extrait le FabrikamFiber référentiel dans le fabrikam-tailspin/FabrikamFiber projet, exécute une commande pour générer la documentation publique, puis la publie sur un site web. En outre, imaginez que le FabrikamFiber référentiel utilise le FabrikamFiberLib référentiel (dans le même projet) comme sous-module.

Utilisez une identité de build basée sur un projet pour les pipelines de mise en production classiques

Lorsqu’un pipeline s’exécute, il utilise une identité pour accéder à diverses ressources, telles que les référentiels, les connexions de service, les groupes de variables. Il existe deux types d’identités qu’un pipeline peut utiliser : un au niveau du projet et un au niveau de la collection. L’ancien offre une meilleure sécurité. Ce dernier offre une facilité d’utilisation. En savoir plus sur les identités de build délimitées et l’étendued’autorisation des travaux.

Nous vous recommandons d’utiliser des identités au niveau du projet pour exécuter vos pipelines. Par défaut, les identités au niveau du projet peuvent uniquement accéder aux ressources du projet dont elles sont membres. L’utilisation de cette identité améliore la sécurité, car elle réduit l’accès obtenu par une personne malveillante lors du détournement de votre pipeline.

Pour que votre pipeline utilise une identité au niveau du projet, activez le paramètre Limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines de mise en production .

Dans notre exemple en cours d’exécution, lorsque ce bouton bascule est désactivé, le FabrikamFiberDocRelease pipeline de mise en production peut accéder à tous les référentiels dans tous les projets, y compris le référentiel FabrikamFiber. Lorsque le bouton bascule est activé, FabrikamFiberDocRelease peut uniquement accéder aux ressources du fabrikam-tailspin/FabrikamFiberDocRelease projet, de sorte que le FabrikamFiber référentiel devient inaccessible.

Si vous exécutez notre exemple de pipeline, lorsque vous activez le bouton bascule, le pipeline échoue et les journaux vous indiquent remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Pour résoudre ces problèmes, suivez les étapes décrites dans la section Processus de base de cet article.

Notre exemple de pipeline réussit.