Accéder aux dépôts, aux artefacts et à d’autres ressources

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

Au moment de l’exécution, chaque travail d’un pipeline peut accéder à d’autres ressources dans Azure DevOps. Par exemple, un travail peut :

  • Extraire le code source à partir d’un dépôt Git
  • Ajouter une balise au dépôt
  • Accéder à un flux dans Azure Artifacts
  • Charger des journaux de l’agent vers le service
  • Charger des résultats de test et d’autres artefacts de l’agent vers le service
  • Mettre à jour un élément de travail

Azure Pipelines utilise des jetons d’accès de travaux pour effectuer ces tâches. Un jeton d’accès de travail est un jeton de sécurité généré dynamiquement par Azure Pipelines pour chaque travail au moment de l’exécution. L’agent sur lequel le travail s’exécute utilise le jeton d’accès du travail pour accéder à ces ressources dans Azure DevOps. Vous pouvez contrôler les ressources auxquelles votre pipeline a accès en contrôlant la façon dont les autorisations sont accordées aux jetons d’accès de travaux.

Les autorisations du jeton sont dérivées (a) de l’étendue d’autorisation du travail et (b) des autorisations que vous définissez sur le compte de service de génération de projet ou de collection.

Étendue d’autorisation du travail

Vous pouvez définir l’étendue d’autorisation du travail sur la collection ou le projet. En définissant l’étendue sur la collection, vous choisissez de laisser les pipelines accéder à tous les dépôts de la collection ou de l’organisation. En définissant l’étendue sur le projet, vous choisissez de restreindre l’accès uniquement aux dépôts qui se trouvent dans le même projet que le pipeline.

L’étendue d’autorisation du travail peut être définie pour l’ensemble de l’organisation Azure DevOps ou pour un projet spécifique.

Notes

Dans Azure DevOps Server 2020, l’option Limiter l’étendue d’autorisation du travail au projet actif s’applique uniquement aux pipelines YAML et aux pipelines de build classiques. Elle ne s’applique pas aux pipelines de mise en production classiques. Les pipelines de mise en production classiques s’exécutent toujours avec une étendue de collection de projets.

Pour définir l’étendue d’autorisation du travail pour l’organisation :

  • Accédez à la page des paramètres de votre organization dans l’interface utilisateur Azure DevOps.
  • Sélectionnez Paramètres sous Pipelines.
  • Cochez Limiter l’étendue d’autorisation du travail au projet actif pour limiter l’étendue au projet. Il s’agit du paramètre recommandé, car il renforce la sécurité de vos pipelines.

Pour définir l’étendue d’autorisation du travail pour un projet spécifique :

  • Accédez à la page des paramètres de votre projet dans l’interface utilisateur Azure DevOps.
  • Sélectionnez Paramètres sous Pipelines.
  • Cochez Limiter l’étendue d’autorisation du travail au projet actif pour limiter l’étendue au projet. Il s’agit du paramètre recommandé, car il renforce la sécurité de vos pipelines.
  • Pour définir l’étendue d’autorisation du travail au niveau de l’organisation pour tous les projets, choisissez Paramètres de l’organisation>Pipelines>Paramètres.
  • Pour définir l’étendue d’autorisation du travail pour un projet spécifique, choisissez Paramètres du projet>Pipelines>Paramètres.

Activez un ou plusieurs des paramètres suivants. L’activation de ces paramètres est recommandée, car elle renforce la sécurité de vos pipelines.

  • Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines qui ne sont pas des pipelines de mise en production : Ce paramètre s’applique aux pipelines YAML et aux pipelines de build classiques. Il ne s’applique pas aux pipelines de mise en production classiques.
  • Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines de mise en production : Ce paramètre s’applique uniquement aux pipelines de mise en production classiques.

Notes

Si l’étendue est définie sur un projet au niveau de l’organisation, vous ne pouvez pas modifier l’étendue dans chaque projet.

Important

Si l’étendue n’est pas limitée au niveau de l’organization ou du projet, chaque travail inclus dans votre pipeline YAML obtient un jeton d’accès de travail délimité à la collection. En d’autres termes, votre pipeline a accès à n’importe quel dépôt dans n’importe quel projet de votre organization. Si une persona non grata est capable d’accéder à un seul pipeline dans un seul projet, elle peut accéder à tout dépôt au sein de votre organisation. C’est pourquoi il est recommandé de limiter l’étendue au niveau le plus élevé (paramètres de l’organisation) afin de contenir l’attaque dans un seul projet.

Si vous utilisez Azure DevOps Server 2019, tous les travaux YAML s’exécutent avec l’étendue d’autorisation du travail définie sur la collection. En d’autres termes, ces travaux ont accès à tous les dépôts inclus dans votre collection de projets. Vous ne pouvez pas modifier cet accès dans Azure DevOps Server 2019.

Les pipelines YAML ne sont pas disponibles dans TFS.

Notes

Si votre pipeline se trouve dans un projet public, l’étendue d’autorisation du travail est automatiquement limitée au projet, quel que soit ce que vous configurez dans tous les paramètres. Les travaux inclus dans un projet public peuvent accéder à des ressources comme des artefacts de build ou des résultats de test uniquement au sein du projet et pas à partir d’autres projets de l’organisation.

Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés

En plus des paramètres d’étendue d’autorisation du travail décrits dans la section précédente, Azure Pipelines propose un paramètre Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés.

Les pipelines peuvent accéder à tous les dépôts Azure DevOps inclus dans les projets autorisés, sauf si l’option Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activée. Une fois cette option activée, vous pouvez réduire l’étendue de l’accès de tous les pipelines aux seuls dépôts Azure DevOps explicitement référencés par une étape checkout ou une instruction uses dans le travail de pipeline qui utilise ce dépôt.

Pour plus d’informations, consultez Dépôts Git Azure Repos – Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés.

Protéger l’accès aux dépôts dans les pipelines YAML

En plus des paramètres d’étendue d’autorisation du travail décrits dans la section précédente, Azure Pipelines propose un paramètre Protéger l’accès aux dépôts dans les pipelines YAML.

Les pipelines peuvent accéder à tous les dépôts Azure DevOps inclus dans les projets autorisés, sauf si l’option Protéger l’accès aux dépôts dans les pipelines YAML est activée. Une fois cette option activée, vous pouvez réduire l’étendue de l’accès de tous les pipelines aux seuls dépôts Azure DevOps explicitement référencés par une étape checkout ou une instruction uses dans le travail de pipeline qui utilise ce dépôt.

Pour plus d’informations, consultez Dépôts Git Azure Repos – Protéger l’accès aux dépôts dans les pipelines YAML.

Important

L’option Protéger l’accès aux dépôts dans les pipelines YAML est activée par défaut pour les nouvelles organisations et les projets créés après mai 2020.

Identités de build étendues

Azure DevOps utilise deux identités intégrées pour exécuter les pipelines.

  • Une identité étendue à la collection, qui a accès à tous les projets de la collection (ou de l’organization pour Azure DevOps Services).
  • Une identité étendue au projet, qui a accès à un seul projet.

Ces identités se voient accorder les autorisations nécessaires pour effectuer des activités de génération/mise en production au moment de l’exécution lors du rappel du système Azure DevOps. Il existe des autorisations par défaut intégrées et vous pouvez également gérer vos propres autorisations selon vos besoins.

Le format du nom de l’identité étendue à la collection est le suivant :

  • Project Collection Build Service ({OrgName})
  • Par exemple, si le nom de l’organisation est fabrikam-tailspin, ce compte porte le nom Project Collection Build Service (fabrikam-tailspin).

Le format du nom de l’identité étendue au projet est le suivant :

  • {Project Name} Build Service ({Org Name})
  • Par exemple, si le nom de l’organisation est fabrikam-tailspin et que le nom du projet est SpaceGameWeb, ce compte porte le nom SpaceGameWeb Build Service (fabrikam-tailspin).

Par défaut, l’identité étendue à la collection est utilisée, sauf configuration contraire, comme décrit dans la section précédente sur l’étendue d’autorisation du travail.

Gérer les autorisations du compte de service de build

L’un des résultats de la définition de l’accès étendu au projet est que l’identité étendue au projet peut ne pas disposer des autorisations nécessaires sur une ressource contrairement à l’identité étendue à la collection.

Vous pouvez modifier les autorisations du jeton d’accès du travail dans les scénarios suivants :

  • Vous souhaitez que votre pipeline accède à un flux qui se trouve dans un autre projet.
  • Vous souhaitez que votre pipeline ne soit pas autorisé à modifier le code dans le dépôt.
  • Vous souhaitez que votre pipeline ne soit pas autorisé à créer des éléments de travail.

Pour mettre à jour les autorisations du jeton d’accès du travail :

  • Tout d’abord, déterminez l’étendue d’autorisation du travail pour votre pipeline. Consultez la section ci-dessus pour comprendre l’étendue d’autorisation du travail. Si l’étendue d’autorisation du travail est la collection, alors le compte de service de build correspondant sur lequel gérer les autorisations est Service de build de collection de projets (nom-de-votre-collection). Si l’étendue d’autorisation du travail est le projet, alors le compte de service de build sur lequel gérer les autorisations est Service de build Nom-de-votre-projet (nom-de-votre-collection).

  • Pour restreindre ou accorder un accès supplémentaire au Service de build de collection de projets (nom-de-votre-collection) :

    • Sélectionnez Gérer la sécurité dans le menu Dépassement de capacité de la page Pipelines.
    • Sous Utilisateurs, sélectionnez Service de build de collection de projets (nom-de-votre-collection).
    • Apportez des modifications aux autorisations liées aux pipelines pour ce compte.
    • Accédez aux paramètres de votre organisation Azure DevOps (ou aux paramètres de collection de votre collection de projets).
    • Sélectionnez Autorisations sous Sécurité.
    • Sous l’onglet Utilisateurs, recherchez Service de build de collection de projets (nom-de-votre-collection).
    • Apportez des modifications aux autorisations non liées aux pipelines pour ce compte.
    • Étant donné que Service de build de collection de projets (nom-de-votre-collection) est un utilisateur au sein de votre organisation ou collection, vous pouvez ajouter ce compte explicitement à n’importe quelle ressource, par exemple, à un flux dans Azure Artifacts.
  • Pour restreindre ou accorder un accès supplémentaire au Service de build Nom-de-votre-projet (nom-de-votre-collection) :

    • Le compte de service de build sur lequel vous pouvez gérer les autorisations est créé uniquement après que vous avez exécuté le pipeline une fois. Veillez à avoir déjà exécuté le pipeline une fois.
    • Sélectionnez Gérer la sécurité dans le menu Dépassement de capacité de la page Pipelines.
    • Sous Utilisateurs, sélectionnez Service de build Nom-de-votre-projet (nom-de-votre-collection).
    • Apportez des modifications aux autorisations liées aux pipelines pour ce compte.
    • Accédez aux paramètres de votre organisation Azure DevOps (ou aux paramètres de collection de votre collection de projets).
    • Sélectionnez Autorisations sous Sécurité.
    • Sous l’onglet Utilisateurs, recherchez Service de build Nom-de-votre-projet (nom-de-votre-collection).
    • Apportez des modifications aux autorisations non liées aux pipelines pour ce compte.
    • Étant donné que Service de build Nom-de-votre-projet (nom-de-votre-collection) est un utilisateur au sein de votre organisation ou collection, vous pouvez ajouter ce compte explicitement à n’importe quelle ressource, par exemple, à un flux dans Azure Artifacts.

Configurer les autorisations pour qu’un projet accède à un autre projet dans la même collection de projets

Dans cet exemple, l’identité de build étendue au projet fabrikam-tailspin/SpaceGameWeb se voit accorder des autorisations d’accès au projet fabrikam-tailspin/FabrikamFiber.

  1. Dans le projet FabrikamFiber, accédez à Paramètres du projet, Autorisations.

    Capture d’écran de la manière de configurer les paramètres du projet.

  2. Créez un groupe nommé Projets externes et ajoutez le compte SpaceGameWeb Build Service. Capture d’écran de la création d’un groupe de sécurité.

  3. Choisissez Utilisateurs, commencez à taper le nom SpaceGameWeb, puis sélectionnez le compte SpaceGameWeb Build Service. Si vous ne voyez pas de résultats de recherche initiaux, sélectionnez Développer la recherche.

    Capture d’écran de la sélection de l’utilisateur de l’identité de build étendue au projet SpaceGameWeb.

  4. Accordez l’autorisation Afficher les informations au niveau du projet pour cet utilisateur.

    Capture d’écran de la manière d’octroyer l’autorisation Afficher les informations au niveau du projet pour un utilisateur.

Exemple : Configurer des autorisations pour accéder à un autre dépôt dans la même collection de projets

Dans cet exemple, l’identité de build étendue au projet fabrikam-tailspin/SpaceGameWeb se voit accorder des autorisations d’accès au dépôt FabrikamFiber dans le projet fabrikam-tailspin/FabrikamFiber.

  1. Suivez les étapes pour accorder à l’identité de build étendue au projet SpaceGameWeb l’autorisation d’accéder au projet FabrikamFiber.

  2. Dans le projet FabrikamFiber, accédez à Paramètres du projet, Dépôts, FabrikamFiber.

    Configurez l’accès aux dépôts.

  1. Choisissez l’icône +, commencez à taper le nom SpaceGameWeb, puis sélectionnez le compte SpaceGameWeb Build Service.

    Ajoutez un utilisateur pour l’accès aux dépôts.

  1. Commencez à taper le nom SpaceGameWeb, puis sélectionnez le compte SpaceGameWeb Build Service.

    Capture d’écran de la manière d’ajouter un utilisateur pour l’accès aux dépôts.

  1. Accordez des autorisations de lecture à cet utilisateur.

    Capture d’écran de la manière de configurer des autorisations d’accès aux dépôts.

Exemple : Configurer des autorisations pour accéder à d’autres ressources dans la même collection de projets

Dans cet exemple, l’identité de build étendue au projet fabrikam-tailspin/SpaceGameWeb se voit accorder des autorisations d’accès à d’autres ressources dans le projet fabrikam-tailspin/FabrikamFiber.

  1. Suivez les étapes pour accorder à l’identité de build étendue au projet SpaceGameWeb l’autorisation d’accéder au projet FabrikamFiber.

  2. Configurez les autorisations souhaitées pour cet utilisateur.

    Configurez les autorisations de l’utilisateur.

Questions fréquentes (FAQ)

Comment puis-je déterminer l’étendue d’autorisation du travail de mon pipeline YAML ?

  • Si votre projet est un projet public, l’étendue d’autorisation du travail correspond toujours au projet, quels que soient les autres paramètres.

Tous les pipelines YAML dans Azure DevOps Server 2019 s’exécutent sous l’étendue d’autorisation du travail au niveau de la collection.

  • Vérifiez les paramètres du pipeline sous Paramètres de l’organisation dans Azure DevOps :
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif est activée, alors l’étendue correspond au projet.
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif n’est pas activée, alors vérifiez les paramètres du pipeline sous Paramètres du projet dans Azure DevOps :
      • Si l’option Limiter l’étendue d’autorisation du travail au projet actif est activée, alors l’étendue correspond au projet.
      • Sinon, l’étendue correspond à la collection.
  • Si le pipeline se trouve dans un projet privé, vérifiez les paramètres du pipeline sous Paramètres de l’organisation dans Azure DevOps :
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines qui ne sont pas des pipelines de mise en production est activée, alors l’étendue correspond au projet.
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines qui ne sont pas des pipelines de mise en production n’est pas activée, alors vérifiez les paramètres du pipeline sous Paramètres du projet dans Azure DevOps :
      • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines qui ne sont pas des pipelines de mise en production est activée, alors l’étendue correspond au projet.
      • Sinon, l’étendue correspond à la collection.

Comment puis-je déterminer l’étendue d’autorisation du travail de mon pipeline de build classique ?

  • Si votre pipeline se trouve dans un projet public, alors l’étendue d’autorisation du travail correspond au projet, quels que soient les autres paramètres.
  • Ouvrez l’éditeur pour le pipeline et accédez à l’onglet Options.
    • Si le paramètre Étendue d’autorisation de la tâche de build a la valeur Projet actif, l’étendue correspond au projet.
    • Sinon, l’étendue correspond à la collection.
  • Vérifiez les paramètres du pipeline sous Paramètres de l’organisation dans Azure DevOps :
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif est activée, alors l’étendue correspond au projet.
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif n’est pas activée, alors vérifiez les paramètres du pipeline sous Paramètres du projet dans Azure DevOps :
      • Si l’option Limiter l’étendue d’autorisation du travail au projet actif est activée, alors l’étendue correspond au projet.
      • Si l’option Limiter l’étendue d’autorisation du travail au projet actif n’est pas activée, ouvrez l’éditeur pour le pipeline et accédez à l’onglet Options.
        • Si le paramètre Étendue d’autorisation de la tâche de build a la valeur Projet actif, l’étendue correspond au projet.
        • Sinon, l’étendue correspond à la collection.
  • Si le pipeline se trouve dans un projet privé, vérifiez les paramètres du pipeline sous Paramètres de l’organisation dans Azure DevOps :
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines qui ne sont pas des pipelines de mise en production est activée, alors l’étendue correspond au projet.
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines qui ne sont pas des pipelines de mise en production n’est pas activée, alors vérifiez les paramètres du pipeline sous Paramètres du projet dans Azure DevOps :
      • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines qui ne sont pas des pipelines de mise en production est activée, alors l’étendue correspond au projet.
      • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines qui ne sont pas des pipelines de mise en production n’est pas activée, ouvrez l’éditeur pour le pipeline et accédez à l’onglet Options.
        • Si le paramètre Étendue d’autorisation de la tâche de build a la valeur Projet actif, l’étendue correspond au projet.
        • Ou bien, l’étendue correspond à la collection.

Lors de la création d’un pipeline classique, l’étendue d’autorisation du travail est définie sur le Projet actif et l’Étendue d’autorisation de la tâche de build est définie sur projet par défaut.

Comment puis-je déterminer l’étendue d’autorisation du travail de mon pipeline de mise en production classique ?

Les pipelines de mise en production classiques dans Azure DevOps Server 2020 et les versions antérieures s’exécutent avec une étendue au niveau de la collection.

  • Si votre pipeline se trouve dans un projet public, alors l’étendue d’autorisation du travail correspond au projet, quels que soient les autres paramètres.
  • Si le pipeline se trouve dans un projet privé, vérifiez les paramètres du pipeline sous Paramètres de l’organisation dans Azure DevOps :
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines de mise en production est activée, alors l’étendue correspond au projet.
    • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines de mise en production n’est pas activée, alors vérifiez les paramètres du pipeline sous Paramètres du projet dans Azure DevOps :
      • Si l’option Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines de mise en production est activée, alors l’étendue correspond au projet.
      • Sinon, l’étendue correspond à la collection.