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 :
Processus De base
Les étapes sont similaires dans tous les pipelines :
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é.
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.
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.
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.
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.
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 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.