Authentification sans PAT à partir des tâches de la chaîne de production vers les API Azure DevOps

Les tâches d’un pipeline utilisent un jeton d'accès de tâche, disponible via la variable intégrée System.AccessToken ou un PAT pour accéder aux ressources Azure DevOps. Par exemple, une tâche « validation » utilise ce jeton pour s’authentifier auprès du référentiel. De même, un script PowerShell peut utiliser ce jeton pour accéder aux API REST Azure DevOps. Toutefois, les autorisations de ce jeton sont basées sur l’identité project Build Service, ce qui signifie que tous les jetons d’accès aux travaux d’un projet ont des autorisations identiques. Cela accorde un accès excessif à tous les pipelines au sein du projet.

L’utilisation de PAT pour accéder aux ressources Azure DevOps est courante, en particulier lorsqu’une tâche doit accéder à ces ressources au-delà des limites de l’organisation. Par exemple, une tâche Nuget Authenticate utilise un jeton PAT pour s’authentifier auprès d’un flux d’une autre organisation. Les PAT sont un anti-modèle pour la sécurité, car ils ont tendance à être créés avec des autorisations étendues et sont conservés pendant longtemps, augmentant ainsi le risque d’exfiltration.

Pour améliorer la sécurité dans ces scénarios, un nouveau type de connexion de service appelé « Connexion de service Azure DevOps » est introduit. Il utilise un principal de service Azure qui peut être ajouté en tant qu’utilisateur dans Azure DevOps avec des autorisations spécifiques. Cela vous permet de vous authentifier auprès des ressources d’une tâche de pipeline à l’aide de cette connexion de service et de restreindre l’accès à des pipelines spécifiques. Nous allons d’abord introduire le nouveau type de connexion et quelques tâches qui fonctionnent avec elle. Nous allons développer progressivement la liste des tâches qui peuvent utiliser le type de connexion au fil du temps.