Accéder de manière sécurisée aux dépôts à partir des pipelines

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

Pour protéger le code qui exécute ses opérations, les organisations doivent contrôler soigneusement l’accès à leurs référentiels de code source. Cet article décrit comment les pipelines de génération et de mise en production d’Azure Pipelines peuvent accéder en toute sécurité aux référentiels afin de réduire le risque d’accès non autorisé.

Cet article fait partie d’une série qui vous aide à implémenter des mesures de sécurité pour Azure Pipelines. Pour plus d’informations, consultez Sécuriser Azure Pipelines.

Conditions préalables

Identités basées sur des projets pour les pipelines

Un pipeline utilise une identité pour accéder aux ressources telles que les référentiels, les connexions de service et les groupes de variables pendant l’exécution. Les pipelines peuvent utiliser deux types d’identités : au niveau de la collection ou au niveau du projet.

L'identité de niveau collection est facile à configurer et à utiliser, mais les identités de niveau projet priorisent la sécurité. Pour améliorer la sécurité, utilisez des identités au niveau du projet pour exécuter des pipelines. Une identité au niveau du projet peut accéder aux ressources uniquement au sein de son projet, ce qui réduit l’impact de tout accès non autorisé par des acteurs malveillants. Pour plus d’informations, consultez Identités de build délimitées et étendue d’autorisation de travail.

Pour configurer un pipeline afin d’utiliser une identité au niveau du projet, vous activez Limitez l’étendue de l’autorisation de travail au projet actuel pour les pipelines non destinés à la mise en production ou Limitez l’étendue de l’autorisation de travail au projet actuel pour les pipelines de mise en production dans les Paramètres du projet du projet de pipeline sous Pipelines>Paramètres.

Étapes d’amélioration de la sécurité de l’accès au référentiel

Un administrateur de projet ou un administrateur de collection de projets peut effectuer les étapes suivantes pour améliorer la sécurité de l’accès aux référentiels Git à partir de pipelines.

1. Inspectez les pipelines pour identifier les référentiels requis qui se trouvent dans d’autres projets. Si vous activez Limiter l’étendue de l’autorisation de travail au projet actuel pour les pipelines sans mise en production, les pipelines peuvent extraire du code uniquement à partir des référentiels du projet actuel.

2. Accordez aux projets de pipeline l’accès à tous les autres projets dont ils ont besoin. Pour plus d’informations, consultez Configurer les autorisations d’un projet pour accéder à un autre projet dans la même collection de projets.

3. Accordez aux identités de build de pipeline l’accès en lecture à chaque dépôt qu’ils recherchent. Accordez également aux identités de pipeline l’accès en lecture aux référentiels utilisés comme sous-modules par les référentiels requis. Pour plus d’informations, consultez Configurer les autorisations d’accès à un autre dépôt dans la même collection de projets.

4. Activez les paramètres d’organisation ou de projet suivants pour le projet de pipeline :

   • Limitez l’étendue d’autorisation du travail au projet actuel pour les pipelines sans mise en production.
   • Limitez l'étendue d'autorisation des tâches au projet actuel pour les pipelines de déploiement si votre projet possède des pipelines de déploiement.
   • Protégez l’accès aux référentiels dans des pipelines YAML si votre projet possède des pipelines YAML Azure Repos.

   Activez ces paramètres en mettant leurs bascules sur Activé dans les paramètres de l'organisation ou les paramètres du projet>, paramètres des pipelines>, paramètres généraux>.

   Si les paramètres sont activés dans les paramètres de l’organisation, ils ne peuvent pas être remplacés dans les paramètres du projet. Si les paramètres ne sont pas activés dans les paramètres de l’organisation, ils peuvent être activés au niveau du projet.

Utiliser un référentiel comme sous-module

Si un référentiel utilise un autre référentiel dans son projet en tant que sous-module, le processus peut échouer lors de la récupération du sous-module, même si vous accordez au pipeline l'accès en lecture aux deux référentiels. Pour résoudre ce problème, clonez explicitement les référentiels de sous-modules avant de cloner ceux qui les utilisent. Pour plus d’informations, consultez Consulter les sous-modules.

Référentiels GitHub

Les considérations de sécurité suivantes s’appliquent à l’accès au pipeline aux référentiels GitHub. Pour plus d’informations, consultez Accès aux référentiels GitHub.

Connexions de service GitHub

Pour utiliser des référentiels GitHub, Azure Pipelines nécessite une connexion de service GitHub. Pour renforcer la sécurité des connexions de service :

• Autoriser l’accès uniquement aux référentiels nécessaires au fonctionnement des pipelines.
• Ne cochez pas Accorder l'autorisation d'accès à tous les pipelines pour la connexion de service. Autorisez explicitement la connexion de service pour chaque pipeline qui l’utilise.

Authentification auprès de référentiels GitHub

Pour déclencher des builds et extraire du code pendant les builds, Azure Pipelines doit avoir accès aux dépôts GitHub. Cet accès peut utiliser le jeton d’accès personnel GitHub (PAT), OAuth ou l’authentification d’application GitHub Azure Pipelines. Pour plus d’informations, consultez Accès aux référentiels GitHub.

L’application GitHub Azure Pipelines est le type d’authentification recommandé pour les pipelines d’intégration continue (CI). Les builds et les mises à jour d’état GitHub utilisent ensuite l’identité Azure Pipelines au lieu d’utiliser votre identité GitHub personnelle. Lorsque vous installez l’application, vous pouvez limiter les dépôts auxquels l’application peut accéder pour renforcer la sécurité.

L’authentification OAuth et PAT utilisent votre identité GitHub personnelle et doivent être autorisées pour l’accès au pipeline. L’utilisation d’un PAT est déconseillée en raison de problèmes de sécurité. Si vous devez utiliser l’authentification PAT, choisissez un PAT précis et limitez l’étendue à certains utilisateurs, référentiels et autorisations. Pour plus d’informations, consultez Gestion de vos jetons d’accès personnels.

Dépôts GitHub dupliqués

Les dépôts dupliqués augmentent les risques liés à l’exécution de code malveillant ou à la publication d’informations sensibles dans les pipelines. Les forks provenant de l’extérieur de votre organisation présentent des risques particuliers.

Pour réduire les risques liés aux référentiels forkés, restreindre la création de demandes de tirage à partir de référentiels GitHub forkés et désactiver la création de demandes de tirage à partir de référentiels forkés sont activées par défaut dans les paramètres de projet ou les paramètres de l'organisationParamètres de pipelinesDéclencheurs.

Pour permettre la génération à partir de référentiels GitHub fourkés, mais réduisez les risques, sélectionnez Générer en toute sécurité des demandes d’extraction à partir de référentiels fourkés. Ce paramètre interdit de rendre les secrets disponibles ou d'utiliser les mêmes autorisations que les builds normales et nécessite un commentaire sur la pull request d'un membre de l'équipe pour déclencher le pipeline.

Vous pouvez également sélectionner Personnaliser des règles pour générer des demandes de tirage à partir de référentiels dérivés pour personnaliser davantage ces paramètres.

Voici d’autres façons d’augmenter la sécurité du fork :

• Si vous utilisez la validation des demandes de tirage (pull requests) pour déclencher des compilations, désélectionnez les demandes de tirage à partir des forks de ce référentiel dans la section Déclencheur de la définition du pipeline, ou assurez-vous que rendre les secrets disponibles pour les compilations de forks et faire en sorte que les compilations de forks disposent des mêmes autorisations que les compilations standards sont désélectionnés. Vous pouvez également sélectionner Exiger le commentaire d’un membre de l’équipe avant de créer une pull request.

• Utilisez des agents hébergés par Microsoft pour créer à partir de forks. Les ressources sont ensuite immédiatement supprimées des agents après les builds. Si vous utilisez des agents hébergés localement, nettoyez et mettez à jour les agents régulièrement, ou bien utilisez des agents distincts pour différents forks ou branches.

Référentiels Azure Repos

Exemple de Azure Repos

L’exemple suivant illustre le processus d’amélioration de la sécurité pour l’accès Azure Repos dans un pipeline.

L’organisation https://dev.azure.com/fabrikam-tailspin contient les projets SpaceGameWeb et FabrikamFiber .

• Le projet SpaceGameWeb contient les dépôts SpaceGameWeb et SpaceGameWebReact .

  

• Le projet FabrikamFiber contient les dépôts FabrikamFiber, FabrikamChat et FabrikamFiberLib . Le référentiel FabrikamFiber utilise le référentiel FabrikamFiberLib en tant que sous-module.

  

Le pipeline SpaceGameWeb dans le projet SpaceGameWeb vérifie le dépôt SpaceGameWebReact dans le projet SpaceGameWeb ainsi que les dépôts FabrikamFiber et FabrikamChat dans le projet FabrikamFiber.

Si le projet n’est pas configuré pour utiliser une identité de build basée sur un projet ou pour protéger l’accès aux dépôts dans des pipelines YAML, le pipeline SpaceGameWeb peut accéder à tous les référentiels de tous les projets de l’organisation et s’exécute correctement.

Utiliser l’identité au niveau du projet

Pour améliorer la sécurité, utilisez une identité au niveau du projet pour exécuter le pipeline. Activez l’étendue limite d’autorisation du travail au projet actuel pour les pipelines sans mise en production bascule dans les paramètres du projet ou les paramètres de l’organisation.

Si ce paramètre est activé, le pipeline peut uniquement accéder aux ressources du projet SpaceGameWeb , qui contient uniquement les dépôts SpaceGameWeb et SpaceGameWebReact . Le pipeline échoue, car il est incapable de vérifier les dépôts dans le projet FabrikamFiber.

Vous voyez les erreurs 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, accordez au projet de pipeline l’accès au projet FabrikamFiber et accordez à l’identité de pipeline l’accès en lecture aux référentiels FabrikamFiber, FabrikamChat et FabrikamFiberLib .

Vérifier explicitement le sous-module

Le référentiel FabrikamFiber utilise le référentiel FabrikamFiberLib en tant que sous-module. Même si vous accordez l’accès au pipeline aux deux référentiels, l’extraction du référentiel FabrikamFiber échoue toujours au moment de l’extraction du sous-module FabrikamFiberLib.

Pour résoudre ce problème, consultez explicitement le dépôt FabrikamFiberLib avant d’extraire le référentiel FabrikamFiber . Ajoutez une checkout: git://FabrikamFiber/FabrikamFiberLib étape avant l’étape checkout: FabrikamFiber . L'exemple de pipeline fonctionne maintenant avec succès.

Protéger l’accès au pipeline YAML

Si l’exemple de pipeline SpaceGameWeb est un pipeline YAML et que protéger l’accès aux référentiels dans les pipelines YAML est activé, le pipeline nécessite l’autorisation d’accéder aux référentiels SpaceGameWebReact, FabrikamFiber et FabrikamChat la première fois qu’il s’exécute.

Le code suivant montre le pipeline YAML complet.

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

Autres mesures de sécurité de référentiel

• Pour réduire les risques de sécurité liés au partage de ressources entre les pipelines YAML et classiques, désactivez la création de pipelines classiques en activant les options Désactiver la création de pipelines de build classiques et Désactiver la création de pipelines de mise en production classiques dans les paramètres du projet ou les paramètres de l’organisation. La création de pipeline de build et de mise en production classique est désactivée par défaut pour les nouvelles organisations.

• Utilisez des modèles de pipeline pour définir la structure du pipeline et empêcher l’infiltration de code malveillante. Les modèles peuvent également effectuer automatiquement des tâches telles que l’analyse des informations d’identification ou l’application de vérifications sur les ressources protégées.

• Exiger une approbation manuelle chaque fois qu’un pipeline demande le référentiel. Pour plus d’informations, consultez Approbations et vérifications.

• Utilisez une vérification de branche protégée pour empêcher les pipelines de s’exécuter automatiquement sur des branches non autorisées.

• Définissez un référentiel à utiliser uniquement dans les pipelines YAML spécifiés. Pour plus d’informations, consultez Ajouter des autorisations de pipeline à une ressource de référentiel.

• Limitez l’étendue du jeton d’accès Azure Pipelines en fournissant le jeton uniquement pour les référentiels répertoriés dans la section du resources pipeline. Pour plus d’informations, consultez Protection du référentiel.

Contenu connexe

• Accéder aux dépôts, aux artefacts et à d’autres ressources
• Protéger une ressource de référentiel
• Options de pipeline pour les référentiels Git
• Sécurité des ressources