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

Vos référentiels sont une ressource essentielle pour la réussite de votre entreprise, car ils contiennent le code qui alimente votre entreprise. L’accès aux référentiels ne doit pas être accordé facilement.

Cet article vous montre comment améliorer la sécurité de vos pipelines qui accèdent à Azure Repos, afin de limiter le risque que votre code source passe entre de mauvaises mains.

La configuration des pipelines pour accéder en toute sécurité aux référentiels Azure est une dans laquelle les bascules Limiter l’étendue d’autorisation de travail au projet actuel pour les pipelines sans mise en production, Limiter l’étendue d’autorisation de travail au projet actuel pour les pipelines de mise en production et Protéger l’accès aux dépôts dans les pipelines YAML sont activés.

Nous allons aborder à la fois les pipelines de build et les pipelines de mise en production classiques :

• Pipelines de build
• Pipeline de mise en production classique

Processus De base

Les étapes sont similaires dans tous les pipelines :

1. Déterminez la liste des référentiels Azure Repos auxquels votre pipeline doit accéder qui font partie de la même organisation, mais qui se trouvent dans des projets différents.

   Vous pouvez compiler la liste des référentiels en inspectant votre pipeline. Vous pouvez également activer l’option Limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines (non) de mise en production et noter les référentiels que votre pipeline ne parvient pas à extraire. Les référentiels de sous-modules peuvent ne pas apparaître lors de la première exécution ayant échoué.

2. Pour chaque projet Azure DevOps qui contient un référentiel auquel votre pipeline doit accéder, suivez les étapes pour accorder à l’identité de build du pipeline l’accès à ce projet.

3. Pour chaque référentiel Azure Repos que votre pipeline extrait, suivez les étapes pour accorder à l’identité de build du pipeline l’accès en lecture à ce référentiel.

4. Pour chaque référentiel utilisé comme sous-module par un dépôt que votre pipeline extrait et qui se trouve dans le même projet, suivez les étapes pour accorder à l’identité de build du pipeline l’accès en lecture à ce référentiel.

5. Activez les options Limiter le champ d'autorisation des tâches au projet actuel pour les pipelines non de mise en production, Limiter le champ d'autorisation des tâches au projet actuel pour les pipelines de mise en production, et Protéger l'accès aux référentiels dans les pipelines YAM.

Pipelines de build

Pour illustrer les étapes à suivre afin d’améliorer la sécurité de vos pipelines lorsqu’ils accèdent à Azure Repos, nous allons utiliser un exemple en cours d’exécution.

Supposons que vous travaillez sur le SpaceGameWeb pipeline hébergé dans le fabrikam-tailspin/SpaceGameWeb projet, dans le SpaceGameWeb référentiel Azure Repos. En outre, supposons que votre SpaceGameWeb pipeline extrait le SpaceGameWebReact référentiel dans le même projet et les FabrikamFiber et FabrikamChat référentiels dans le fabrikam-tailspin/FabrikamFiber projet.

Enfin, supposons que le FabrikamFiber référentiel utilise le FabrikamFiberLib référentiel comme sous-module, hébergé dans le même projet. En savoir plus sur la façon d’extraire des sous-modules.

Les SpaceGameWeb structures de dépôt du projet ressemblent à celles de la capture d’écran suivante.

FabrikamFiberLes structures de référentiel du projet ressemblent à celles de la capture d’écran suivante.

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. Supposez également que vous avez déjà exécuté votre pipeline avec succès.

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

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. La première offre une meilleure sécurité, la seconde 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 non de 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 indiquent 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. 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 Processus de base.

En outre, vous devez extraire 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 maintenant notre exemple de pipeline, il réussit.

Configuration supplémentaire

Pour améliorer davantage la sécurité lors de l’accès à Azure Repos, envisagez d’activer le paramètre Protéger l’accès aux référentiels dans les pipelines YAML.

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. En savoir plus sur ce paramètre. L’extraction d’autres types de référentiels, par exemple ceux hébergés sur GitHub, n’est pas affectée par ce paramètre.

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

Lorsque vous exécutez l’exemple de pipeline, vous verrez une build similaire à la capture d’écran suivante.

Vous serez invité à accorder l’autorisation aux référentiels que votre pipeline extrait ou a définis en tant que ressources.

Une fois que vous le faites, votre pipeline s’exécute, mais il échoue, car il ne pourra pas extraire le FabrikamFiberLib référentiel en tant que sous-module de FabrikamFiber. Pour résoudre ce problème, extrayez explicitement le FabrikamFiberLib, par exemple, ajoutez une étape - checkout: git://FabrikamFiber/FabrikamFiberLibavant l’étape-checkout: FabrikamFiber.

Si vous exécutez maintenant notre exemple de pipeline, il 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

Voici quelques situations problématiques et comment les gérer.

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 si l’option Protéger l’accès aux référentiels dans les pipelines YAML est activée.

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

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, extrayez explicitement le FabrikamFiberLib, par exemple, ajoutez une étape - checkout: git://FabrikamFiber/FabrikamFiberLibavant la -checkout: FabrikamFiber.

Pipelines de build classiques

Dans les pipelines de build classiques, vous ne pouvez pas déclarer explicitement d’autres référentiels en tant que ressources. La façon dont vous extrayez plus de référentiels Azure Repos consiste à ajouter des tâches de ligne de commande avec git clone des commandes, comme la commande suivante pour extraire le FabrikamFiber référentiel : git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --recurse-submodules https://dev.azure.com/silviuandrica/FabrikamFiber/_git/FabrikamFiber.

Le paramètre de protection de l’accès aux référentiels dans les pipelines YAML

Le paramètre Protéger l'accès aux référentiels dans les pipelines YAML 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. En savoir plus sur ce paramètre.

Soyez prudent lorsque vous activez le paramètre Protéger l’accès aux dépôts dans les pipelines YAML . Dans ce cas, vos pipelines de build classiques ne pourront accéder à aucun autre référentiel Azure DevOps, à l’exception de celui spécifié dans ses paramètres. Dans notre exemple de pipeline, vous obtenez une erreur et le message de journal TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Si votre projet possède à la fois des pipelines de build YAML et classiques et que vos pipelines de build classiques extraient d'autres référentiels Azure DevOps en plus de ceux spécifiés dans leurs paramètres, vous devez alors créer deux projets, un pour les pipelines YAML et un pour les pipelines de build classiques. Ensuite, dans le projet de pipelines YAML, vous pouvez activer le paramètre.

Le paramètre Protéger l’accès aux référentiels dans les pipelines YAML ne s’applique pas aux référentiels hébergés sur d’autres services, tels que GitHub.

Paramètre d’étendue d’autorisation du travail de build

Le paramètre Limiter l’étendue d’autorisation de travail au projet actuel pour les pipelines non de mise en production remplace le paramètre d’étendue d’autorisation du travail de build. Si vous activez le premier, votre pipeline s’exécute avec l’identité basée sur le projet, même si l’étendue d’autorisation du travail de build spécifie collection de projets.

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 allons utiliser 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. La première offre une meilleure sécurité, la seconde 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 d’erreurs 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 Processus de base.

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

Voir aussi

• Identités de build étendues
• Étendue d’autorisation du travail
• Accorder à l’identité de build d’un pipeline l’accès à un projet
• Accorder à l’identité de build d’un pipeline l’accès en lecture à un référentiel
• Comment extraire les sous-modules