Service connections Azure DevOps : passe à la fédération d’identité

Si tes pipelines Azure DevOps utilisent encore des service connections basées sur un service principal avec secret ou pire, un Personal Access Token planqué dans une variable « secrète », tu portes une dette de sécurité qui n’a plus vraiment de raison d’être en 2026. Microsoft pousse depuis plusieurs mois une alternative sans secret, la Microsoft Entra Workload Identity Federation, désormais l’approche recommandée pour authentifier tes pipelines auprès d’Azure et même d’autres organisations Azure DevOps. Dans cet article, tu vas voir pourquoi ce changement compte, comment le mettre en place concrètement, et les pièges classiques à éviter.

Si tu es en train de revoir la façon dont tes pipelines s’exécutent, ça vaut aussi le coup de relire notre article sur les Managed DevOps Pools et la fin de la maintenance des agents : les deux sujets touchent à la même logique de simplification et de sécurisation de l’exécution de tes pipelines.

Le problème avec les service connections « classiques »

Une service connection Azure Resource Manager basée sur un service principal avec secret, c’est un identifiant et une chaîne secrète stockés côté Azure DevOps, avec une date d’expiration à surveiller manuellement. Deux soucis récurrents en découlent :

• Le secret doit être renouvelé régulièrement, et un oubli casse silencieusement tous les pipelines qui en dépendent, souvent un lundi matin.
• Le secret circule (portail Entra, connexion Azure DevOps, parfois des exports de configuration), ce qui élargit la surface d’attaque en cas de fuite.

Un Personal Access Token utilisé comme raccourci pose le même genre de problème, en pire : il est souvent lié à un compte personnel, avec des droits plus larges que nécessaire.

Ce que change le Workload Identity Federation

Avec la fédération d’identité, Azure DevOps n’a plus besoin de connaître un secret. Le pipeline s’authentifie via un jeton JWT éphémère, émis à la volée, vérifié par Microsoft Entra ID via une relation de confiance fédérée établie une fois pour toutes entre ton organisation Azure DevOps et ton tenant Entra. Concrètement, ça t’évite :

• de créer, stocker ou faire tourner un secret quel qu’il soit ;
• les pannes de pipeline liées à une expiration de secret non anticipée ;
• une bonne partie de la surface d’exposition en cas de fuite de configuration, puisqu’il n’y a simplement rien à voler.

Autre bénéfice concret : la fédération permet aussi de connecter proprement une organisation Azure DevOps à une autre organisation Azure DevOps (par exemple pour aller chercher un repo externe ou publier sur un flux d’artefacts partagé), sans passer par un PAT partagé entre équipes.

Mettre en place une service connection fédérée

La documentation officielle Microsoft détaille la procédure complète (Access Azure DevOps with Microsoft Entra workload identity), mais voici l’essentiel.

1. Ajouter le service principal ou la managed identity à l’organisation

Dans Organization Settings > Users > Add users, tu ajoutes l’identité (par son nom ou son Object ID Entra) avec un access level Basic, et tu l’assignes à un groupe avec les droits minimum nécessaires — évite de la mettre directement dans Project Collection Administrators par facilité.

2. Créer la connexion de service

Dans Project Settings > Service connections > New service connection, tu choisis le type Azure Resource Manager (ou Azure DevOps pour un accès cross-org) puis l’option workload identity federation, et tu sélectionnes l’identité créée à l’étape précédente.

3. L’utiliser dans un pipeline YAML

steps:
- task: AzureCLI@3
  inputs:
    connectionType: 'azureDevOps'
    azureDevOpsServiceConnection: 'my-azdo-connection'
    scriptType: 'pscore'
    inlineScript: |
      az devops project list --query "value[].{Name:name, Id:id}" -o table

Pour authentifier un flux d’artefacts NuGet, c’est tout aussi direct :

- task: NuGetAuthenticate@1
  inputs:
    nuGetServiceConnections: 'my-azdo-connection'

Managed identity ou service principal : lequel choisir ?

Les deux fonctionnent avec la fédération, mais la durée de vie du jeton diffère : environ 1h pour un service principal, contre 24h pour une managed identity. Si tes pipelines enchaînent des étapes longues (build + déploiement + tests d’intégration qui dépassent l’heure), préfère une managed identity pour éviter une expiration en plein milieu d’exécution.

Pièges et limitations à connaître

• Applications multi-tenant non supportées : configure ton app registration Entra en AzureADMyOrg, pas en AzureADMultipleOrgs.
• AADSTS700238 : un administrateur Entra doit explicitement autoriser la fédération d’identité de charge de travail au niveau du tenant avant que ça fonctionne — la même équipe qui gère tes politiques Conditional Access est généralement la bonne interlocutrice pour débloquer ce point.
• AADSTS70021 (« No matching federated identity record ») : le plus souvent une URL d’issuer ou un subject mal renseigné côté federated credential — à vérifier directement dans la boîte de dialogue d’édition de la connexion.
• Clouds souverains : certains environnements Azure souverains bloquent encore la fédération (erreur AADSTS900382) — vérifie la compatibilité avant de migrer un projet critique.
• Le service principal ou la managed identity doit être ajouté comme utilisateur dans chaque organisation Azure DevOps cible pour un accès cross-org, même si c’est la même identité Entra derrière.

Et côté sécurisation du code, quoi de neuf ?

Dans la même logique de renforcement de la sécurité des pipelines, Microsoft a aussi fait évoluer l’offre GitHub Advanced Security pour Azure DevOps, désormais disponible en deux produits indépendants plutôt qu’un seul bundle : GitHub Secret Protection (protection contre les fuites de secrets avant qu’elles n’arrivent) et GitHub Code Security (scan de dépendances et analyse CodeQL). Les clients existants ne sont pas impactés automatiquement — la bascule vers l’un ou l’autre produit se fait à la demande via le portail Azure. Plus de détails sur le blog officiel Azure DevOps.

FAQ

Le Workload Identity Federation remplace-t-il complètement les PAT ?

Pour l’authentification pipeline vers Azure ou vers une autre organisation Azure DevOps, oui, c’est l’option recommandée. Les PAT restent utiles pour certains scénarios d’automatisation en dehors des pipelines (scripts locaux, outils tiers), mais leur usage doit rester limité et avec une durée de vie courte.

Est-ce compatible avec les agents self-hosted ?

Oui, la fédération d’identité fonctionne aussi bien avec les agents Microsoft-hosted qu’avec des agents self-hosted ou des Managed DevOps Pools.

Ça coûte plus cher ?

Non, la fédération d’identité ne change rien à la facturation Azure DevOps — c’est une méthode d’authentification, pas un service payant.

En résumé

Si tu gères encore des service connections avec secret qui expirent tous les six ou douze mois, c’est le moment de planifier la bascule. Commence par un projet non critique pour valider la configuration Entra, documente les groupes de droits, puis généralise. Tu gagnes en sécurité, tu perds une corvée récurrente de rotation de secrets — difficile de trouver un meilleur compromis.