Fédération des identités de charge de travail

Cet article fournit une vue d’ensemble de la fédération des identités pour les charges de travail logicielles. L’utilisation de la fédération des identités de charge de travail vous permet d’accéder aux ressources protégées par Microsoft Entra sans avoir à gérer les secrets (pour les scénarios pris en charge).

Vous pouvez utiliser la fédération des identités de charge de travail dans des scénarios tels que GitHub Actions, les charges de travail s’exécutant sur Kubernetes ou les charges de travail s’exécutant dans des plateformes de calcul en dehors d’Azure.

Pourquoi utiliser la fédération des identités de charge de travail ?

Regardez cette vidéo pour comprendre tout l’intérêt de la fédération d’identité de charge de travail.

En général, une charge de travail logicielle (comme une application, un service, un script ou une application basée sur des conteneurs) a besoin d’une identité pour s’authentifier, et pour accéder à des ressources ou communiquer avec d’autres services. Quand ces charges de travail s’exécutent sur Azure, vous pouvez utiliser des identités managées, et la plateforme Azure gère les informations d’identification pour vous. Cependant, vous pouvez utiliser des identités managées uniquement pour les charges de travail logicielles exécutées sur Azure. Pour une charge de travail logicielle exécutée en dehors d’Azure, vous devez utiliser les informations d’identification de l’application (secret ou certificat) pour accéder aux ressources protégées par Microsoft Entra (comme des ressources Azure, Microsoft Graph, Microsoft 365 ou tierces). Ces informations d’identification présentent un risque de sécurité, et doivent être stockées de façon sécurisée et faire régulièrement l’objet de rotations. Vous courez également le risque d’un arrêt du service si les informations d’identification expirent.

Vous utilisez la fédération d'identité de charge de travail pour configurer une identité managée attribuée par l'utilisateur ou un enregistrement d'application dans Microsoft Entra ID afin de faire confiance aux jetons d'un fournisseur d'identité externe (IdP), tel que GitHub ou Google. L'identité gérée attribuée par l'utilisateur ou l'enregistrement de l'application dans Microsoft Entra ID devient une identité pour les charges de travail logicielles exécutées, par exemple, dans des workflows Kubernetes ou GitHub Actions sur site. Une fois cette relation d’approbation créée, votre charge de travail logicielle externe échange des jetons approuvés provenant du fournisseur d’identité externe pour des jetons d’accès de la plateforme d’identités Microsoft. Votre charge de travail logicielle utilise ce jeton d’accès pour accéder aux ressources protégées par Microsoft Entra auxquelles la charge de travail a obtenu l’accès. Vous éliminez la charge en maintenance pour gérer manuellement les informations d’identification, et vous éliminez aussi le risque de fuite de secrets ou d’expiration des certificats.

Scénarios pris en charge

Les scénarios suivants sont pris en charge pour accéder aux ressources protégées par Microsoft Entra à l’aide de la fédération des identités de charge de travail :

• Charges de travail s’exécutant sur n’importe quel cluster Kubernetes (Azure Kubernetes Service (AKS), Amazon Web Services EKS, Google Kubernetes Engine (GKE) ou local). Établissez une relation d'approbation entre votre identité managée ou votre application attribuée par l'utilisateur dans Microsoft Entra ID et une charge de travail Kubernetes (décrite dans la présentation de l'identité de charge de travail).
• GitHub Actions. Tout d’abord, configurez une relation d’approbation entre votre identité managée ou application attribuée par l’utilisateur dans Microsoft Entra ID et un dépôt GitHub dans le centre d’administration Microsoft Entra ou à l’aide de Microsoft Graph. Ensuite, configurez un workflow GitHub Actions pour obtenir un jeton d’accès du fournisseur d’identité Microsoft et accéder aux ressources Azure.
• Google Cloud. Tout d’abord, configurez une relation d’approbation entre votre identité gérée ou votre application attribuée par l’utilisateur dans Microsoft Entra ID et une identité dans Google Cloud. Configurez ensuite votre charge de travail logicielle exécutée dans Google Cloud pour obtenir un jeton d’accès du fournisseur d’identité Microsoft et accéder aux ressources protégées par Microsoft Entra. Consultez Accéder aux ressources protégées par Microsoft Entra à partir d’une application dans Google Cloud.
• Charges de travail s’exécutant sur Amazon Web Services (AWS). Tout d'abord, configurez une relation d'approbation entre votre identité gérée ou votre application attribuée par l'utilisateur dans Microsoft Entra ID et une identité dans Amazon Cognito. Configurez ensuite votre charge de travail logicielle exécutée dans AWS pour obtenir un jeton d’accès du fournisseur d’identité Microsoft et accéder aux ressources protégées par Microsoft Entra. ConsultezFédération d’identité de charge de travail avec AWS.
• Autres charges de travail exécutées dans des plateformes de calcul en dehors d’Azure. Configurez une relation d'approbation entre votre identité managée ou votre application attribuée par l'utilisateur dans Microsoft Entra ID et l'IdP externe de votre plateforme de calcul. Vous pouvez utiliser des jetons émis par cette plateforme pour vous authentifier auprès de la plateforme d’identités Microsoft et appeler des API dans l’écosystème Microsoft. Utilisez le flux des informations d’identification du client pour obtenir un jeton d’accès auprès de la plateforme d’identités Microsoft, en passant le jeton JWT du fournisseur d’identité au lieu d’en créer un vous-même en utilisant un certificat stocké.
• SPIFFE et SPIRE sont un ensemble de normes open source indépendantes de la plateforme pour fournir des identités à vos charges de travail logicielles déployées sur des plateformes et des fournisseurs de cloud. Tout d’abord, configurez une relation d’approbation entre votre identité managée ou votre application attribuée par l’utilisateur dans Microsoft Entra ID et un ID SPIFFE pour une charge de travail externe. Configurez ensuite votre charge de travail logicielle externe pour obtenir un jeton d’accès du fournisseur d’identité Microsoft et accéder aux ressources protégées par Microsoft Entra. Consultez Fédération des identités de charge de travail avec SPIFFE et SPIRE.
• Créez une connexion de service dans Azure Pipelines (préversion). Créer une connexion de service Azure Resource Manager à l’aide de la fédération des identités de charge de travail.

Remarque

Les jetons émis par Microsoft Entra ID ne peuvent pas être utilisés pour les flux d’identités fédérés. Le flux d’informations d’identification d’identité fédérée ne prend pas en charge les jetons émis par Microsoft Entra ID.

Fonctionnement

Créez une relation d'approbation entre l'IdP externe et une identité ou une application gérée attribuée par l'utilisateur dans Microsoft Entra ID. Les informations d’identification d’identité fédérée sont utilisées pour indiquer quel jeton du fournisseur d’identité externe doit être approuvé par votre application ou identité managée. Voici plusieurs façons de configurer une identité fédérée :

• Sur une identité managée affectée par l’utilisateur via le centre d’administration Microsoft Entra, Azure CLI, Azure PowerShell, Azure SDK et des modèles Azure Resource Manager (ARM). La charge de travail externe utilise le jeton d’accès pour accéder aux ressources protégées par Microsoft Entra sans avoir besoin de gérer les secrets (dans les scénarios pris en charge). Les étapes de configuration de la relation de confiance diffèrent selon le scénario et le fournisseur d’identité externe.
• Lors d’une inscription d’application dans le centre d’administration Microsoft Entra ou via Microsoft Graph. Cette configuration vous permet d’obtenir un jeton d’accès pour votre application sans avoir à gérer les secrets en dehors d’Azure. Pour plus d’informations, découvrez comment configurer une application pour approuver un fournisseur d’identité externe.

Le workflow pour l’échange d’un jeton externe contre un jeton d’accès est cependant identique pour tous les scénarios. Le diagramme suivant montre le workflow général d’une charge de travail échangeant un jeton externe contre un jeton d’accès, puis accédant aux ressources protégées par Microsoft Entra.

1. La charge de travail externe (par exemple un workflow GitHub Actions) demande un jeton auprès du fournisseur d’identité externe (par exemple GitHub).
2. Le fournisseur d’identité externe envoie un jeton à la charge de travail externe.
3. La charge de travail externe (par exemple l’action de connexion dans un workflow GitHub) envoie le jeton à la plateforme d’identités Microsoft, puis demande un jeton d’accès.
4. La plateforme d'identité Microsoft vérifie la relation de confiance sur l'identité managée attribuée par l'utilisateur ou l'enregistrement de l'application et valide le jeton externe par rapport à l'URL de l'émetteur OpenID Connect (OIDC) sur l'IdP externe.
5. Quand les vérifications sont satisfaites, la plateforme d’identités Microsoft émet un jeton d’accès à destination de la charge de travail externe.
6. La charge de travail externe accède aux ressources protégées par Microsoft Entra à l’aide du jeton d’accès de la plateforme d’identité Microsoft. Par exemple, un workflow GitHub Actions utilise le jeton d’accès pour publier une application web sur Azure App Service.

La plateforme d’identités Microsoft stocke uniquement les 100 premières clés de signature lorsqu’elles sont téléchargées à partir du point de terminaison OIDC du fournisseur d’identité (IdP) externe. Si le fournisseur d’identité externe expose plus de 100 clés de signature, vous risquez de rencontrer des erreurs lors de l’utilisation de la fédération des identités de charge de travail.

Étapes suivantes

En savoir plus sur le fonctionnement de la fédération des identités de charge de travail :

• Comment créer, supprimer, obtenir ou mettre à jour les informations d’identification d’identité fédérée sur une identité managée affectée par l’utilisateur.
• Comment créer, supprimer, obtenir ou mettre à jour les informations d’identification d’identité fédérée sur une inscription d’application.
• Lisez la vue d’ensemble de l’identité de charge de travail de façon à savoir comment configurer une charge de travail Kubernetes pour obtenir un jeton d’accès du fournisseur d’identité Microsoft et accéder aux ressources protégées par Microsoft Entra.
• Lisez la documentation GitHub Actions afin d’en savoir plus sur la configuration de votre workflow GitHub Actions pour obtenir un jeton d’accès du fournisseur d’identité Microsoft et accéder aux ressources protégées par Microsoft Entra.
• Comment Microsoft Entra ID utilise l'octroi d'informations d'identification client OAuth 2.0 et une assertion client émise par un autre fournisseur d'identité pour obtenir un jeton.
• Pour des informations sur le format requis des jetons JWT créés par des fournisseurs d’identité externes, lisez l’article sur le format d’assertion.