Je suis toujours étonné de constater combien de développeurs et d’entreprises continuent d’utiliser les configurations basées sur le Client ID et le Client Secret pour se connecter à Azure depuis un service externe. Bien que cette méthode soit plus simple à mettre en place, elle présente des défis en termes de sécurité et de maintenance. À l’inverse, lorsque c’est possible, les identités fédérées offrent une alternative plus sûre et efficace, en supprimant entièrement la gestion des secrets.
Dans ce post, je vais vous présenter un exemple pratique utilisant Azure DevOps, démontrant comment les identités fédérées fonctionnent dans des scénarios réels. Ensuite, je me pencherai sur les principales différences entre l’approche du secret client et les identités fédérées, en soulignant pourquoi ces dernières constituent un meilleur choix pour une gestion sécurisée des identités.
Si vous cherchez à renforcer la sécurité tout en simplifiant la gestion des identités, ce post vous aidera à faire le premier pas vers l’adoption des identités fédérées dans vos propres projets.
Pour mieux illustrer le fonctionnement de la fédération d’identités, cet article prend pour exemple Azure DevOps, où la fonctionnalité est appelée Workload Identity Federation. Il s’agit d’une fonctionnalité indispensable pour automatiser les déploiements depuis Azure DevOps vers n’importe quel abonnement Azure.
Le diagramme suivant illustre le fonctionnement de Workload Identity Federation sur Azure DevOps :
La configuration d’une connexion de type Client ID/Client Secret ou d’une connexion Federated Identity demande à peu près le même effort. Si vous êtes habitués à configurer des Secrets, la configuration des identités fédérées va vous sembler extrêmement simple.
Nous devons mettre en place une connexion de service (Service connection) qui utilise les Workload Federated Identities. Pour ce faire, nous devons nous connecter à Azure DevOps et, dans la fenêtre « Service Connections » (sous Project Settings), créer une nouvelle connexion de type « Azure Resource Manager ». Sélectionnez ensuite « Workflow Identity Federation ». Pour ce post, j’ai choisi une configuration manuelle.
Dans la fenêtre suivante, donnez un nom à votre connexion. En option, vous pouvez accorder l’autorisation d’utiliser cette connexion à toutes les pipelines.
Dans la dernière fenêtre ouverte, vous observerez deux paramètres principaux : l’émetteur (Issuer), et le sujet (Subject) d’une assertion pouvant être générée par Azure DevOps. À ce stade, il est nécessaire de renseigner l’abonnement (Souscription Azure), le Tenant, ainsi que l’identifiant du Service principal que vous utilisez. Cet identifiant peut correspondre soit à une App Registration, soit à une Managed Identity (et oui, les Federated Identities fonctionnent également avec les Managed Identities !). Notez qu’à ce moment précis, il n’est pas encore possible d’établir la connectivité, car Entra ID doit d’abord être configuré avec des Federated Credentials. Pour ce faire, copiez les valeurs de l’émetteur et du sujet, puis connectez-vous à Azure ou Entra ID afin de les configurer.
Dans cet exemple, j’utilise une App Registration pour la connectivité. Une fois que vous avez configuré votre Service Connection dans Azure DevOps, localisez votre App Registration dans Entra ID et accédez à sa fenêtre de gestion « Certificates and secrets ». Ensuite, sélectionnez l’onglet « Federated Identity ».
Comme vous pouvez le constater, la configuration de l’identité fédérée se situe au même niveau que la configuration des secrets. En fait, il s’agit simplement d’une autre façon de s’authentifier.
Pour configurer une nouvelle connexion à l’aide d’une identité fédérée, cliquez sur « + Add Credential » et sélectionnez « Other Issuer » dans le menu déroulant proposé. Dans le formulaire de demande, collez le « Issuer » que vous avez récupéré dans Azure DevOps dans la case « Issuer ». De même collez le « Subject » dans la case « Value ». Enfin, donnez un nom à votre credential et c’est tout !
Une fois les informations d’identification enregistrées, n’oubliez pas de sauvegarder votre Service Connection sur Azure DevOps !
Par ailleurs, si vous utilisez Managed Identities, vous pouvez effectuer ces mêmes étapes à partir de l’onglet « Settings > Federated Credentials » de Managed Identity.
Vous trouverez plus de détails dans la documentation Microsoft.
L’approche basée sur le Client ID et le Client Secret a longtemps été une méthode populaire pour intégrer des applications avec Azure Entra ID. C’est une méthode très simple : il suffit d’enregistrer une application, de générer un secret et de l’utiliser pour s’authentifier. Cependant, cette simplicité comporte des inconvénients majeurs. Les secrets sont statiques et nécessitent une gestion sécurisée par leur détenteur. Cela peut s’avérer complexe, surtout lorsqu’on travaille avec des partenaires externes. Une fois un secret attribué, l’organisation émettrice dispose d’un contrôle limité sur son stockage et son utilisation, ce qui accroît le risque d’exposition accidentelle: par exemple, le stockage en dur des secrets dans le code source, ou le partage via des canaux non sécurisés. Avec le temps, les entreprises se retrouvent souvent à gérer un volume croissant de secrets, parfois des centaines ou des milliers, rendant la rotation des clés particulièrement lourde sur le plan opérationnel.
En revanche, les identités fédérées éliminent complètement la nécessité de secrets statiques en s’appuyant sur des protocoles de fédération d’identité tels qu’OpenID Connect. Avec cette approche, les applications s’authentifient en obtenant dynamiquement des jetons à courte durée de vie. On supprime ainsi la gestion de secrets à long terme par l’application ou son utilisateur. Ces jetons, souvent valables seulement quelques minutes, réduisent considérablement la fenêtre de vulnérabilité. Au contraire, les jetons Azure Entra ID ont par défaut, une durée de vie d’une heure. En plus de renforcer la sécurité, les identités fédérées simplifient également la gestion opérationnelle en supprimant le besoin de rotation des secrets. Cela en fait une solution particulièrement avantageuse pour les collaborations avec des parties externes ou dans des environnements multi-cloud.
