Présentation des identités de charge de travail

Effectué

Les flux de travail de déploiement, les applications et les logiciels nécessitent une méthode spéciale pour s’authentifier. Dans cette unité, vous allez découvrir pourquoi les identités de charge de travail sont importantes pour les flux de travail de déploiement, la façon dont elles s’intègrent au modèle de sécurité d’Azure, ainsi que leur fonctionnement.

Pourquoi un flux de travail doit-il s’authentifier ?

Quand vous déployez un fichier Bicep, vous demandez à Azure Resource Manager de créer ou de modifier vos ressources Azure. Dans cet exemple de scénario, vous avez créé un fichier Bicep pour déployer le site web de votre entreprise de jouets. Le fichier Bicep déclare les ressources qui incluent un plan Azure App Service, une application et une instance Application Insights.

Quand vous déployez le fichier, Resource Manager vérifie si les ressources existent. Si ce n’est pas le cas, Resource Manager les crée. Si des ressources existent déjà, Resource Manager vérifie que leur configuration correspond à celle spécifiée dans le fichier Bicep.

Toutes ces opérations requièrent une autorisation car elles impliquent l’accès à vos ressources Azure et leur modification. Les autorisations spécifiques nécessaires au déploiement varient en fonction du contenu du fichier Bicep. Pour déployer l’exemple de fichier pour le site web de votre entreprise de jouets, vous devez disposer des autorisations suivantes dans le groupe de ressources vers lequel vous effectuez le déploiement :

  • Possibilité de créer des déploiements. Les déploiements sont des ressources de type Microsoft.Resources/deployments.
  • La possibilité de créer et de modifier des applications et plans App Service.
  • Possibilité de créer et de modifier des instances Application Insights.

Jusqu’à présent, vous avez probablement déployé vos fichiers Bicep à l’aide de l’interface Azure CLI ou d’Azure PowerShell. Quand vous utilisez ces outils, vous utilisez normalement votre propre compte d’utilisateur et vous vous authentifiez à l’aide de votre navigateur. Cette méthode est appelée à l’aide de votre propre identité. Quand vous soumettez un déploiement, Azure vérifie que votre identité dispose des autorisations nécessaires pour les opérations que votre modèle Bicep spécifie.

Une fois que vous avez effectué la migration vers un workflow de déploiement GitHub Actions, vous devez utiliser un autre type d’identité, car le flux de travail exécute les déploiements sans votre implication directe.

Types d’identités

Microsoft Entra ID est le service qui gère les identités pour Azure. Certains des principaux types d’identités sont les suivants :

  • Identités utilisateur : un utilisateur représente un être humain qui se connecte généralement de manière interactive à l’aide d’un navigateur. Les utilisateurs doivent souvent effectuer des vérifications de sécurité supplémentaires quand ils se connectent, par exemple via l’authentification multifacteur (MFA) et l’accès conditionnel en fonction de leur emplacement ou réseau.
  • Groupes : un groupe représente une collection d’utilisateurs. Les groupes ne s’authentifient pas directement, mais ils constituent un moyen pratique d’attribuer simultanément des autorisations à un ensemble d’utilisateurs.
  • Identités de charge de travail : une charge de travail représente un processus ou un système automatisé qui n’est généralement pas exécuté directement par un être humain. Une charge de travail peut se connecter à Microsoft Entra ID, mais aucun être humain n’est présent pour se connecter et interagir avec le processus d’authentification. Les identités de charge de travail ne sont pas protégées par l’authentification multifacteur ni par des protections similaires, car ces fonctionnalités nécessitent qu’une personne effectue une action pour prouver son identité.

Ce module se concentre sur les identités de charge de travail.

Identités managées

Une identité managée est associée à une ressource Azure. Azure gère les informations d’identification automatiquement. Quand la ressource a besoin d’accéder à quelque chose, Azure se connecte automatiquement à l’aide des informations d’identification.

Les identités managées sont disponibles pour les ressources hébergées par Azure, comme les machines virtuelles et les applications App Service. Il s’agit d’un excellent moyen d’authentification des ressources Azure dans des situations comme l’automatisation de votre gestion Azure, la connexion aux bases de données et la lecture de données secrètes à partir d’Azure Key Vault. Vous pouvez également utiliser des identités managées avec Azure Arc pour d’autres scénarios.

Quand vous utilisez des flux de travail de déploiement, vous n’utilisez généralement pas des identités managées. Les identités managées nécessitent que vous possédiez et gériez les ressources Azure qui exécutent vos déploiements. Quand vous utilisez GitHub Actions, vous vous basez généralement sur l’infrastructure partagée fournie par Microsoft ou GitHub. Toutefois, lorsque vous utilisez une identité de charge de travail avec GitHub Actions, vous pouvez obtenir l’avantage principal des identités managées : vous n’avez pas besoin de gérer les informations d’identification.

Conseil

Dans d’autres parties de votre solution, si vous avez le choix entre l’utilisation d’une identité managée et l’utilisation d’un principal de service normal, il est préférable d’utiliser une identité managée. Les identités managées sont plus faciles à utiliser et généralement plus sécurisées.

Pourquoi ne pas utiliser tout simplement son compte d’utilisateur ?

Vous vous demandez peut-être pourquoi vous devez créer un tout nouveau type d’objet juste pour authentifier un flux de travail de déploiement alors que vous disposez de comptes d’utilisateur qui fonctionnent parfaitement bien.

Les comptes d’utilisateur ne sont pas conçus pour une utilisation sans assistance. Le processus d’authentification d’un compte d’utilisateur vérifie souvent que c’est bien un être humain qui tente de se connecter. Les organisations utilisent de plus en plus souvent des vérifications de sécurité supplémentaires pendant l’authentification. Ces contrôles incluent la MFA, les vérifications CAPTCHA et l’inspection de l’appareil et du réseau que l’utilisateur utilise afin de vérifier la légitimité d’une requête de connexion.

Les workflows sont conçus pour exécuter vos déploiements même si personne ne les exécute activement. En fait, la plupart des avantages des workflows de déploiement sont liés au fait qu’ils sont automatisés et ne nécessitent pas d’interaction humaine.

Si vous stockez votre nom d’utilisateur et votre mot de passe dans un flux de travail et que vous tentez de les utiliser pour vous connecter, ils ne fonctionneront probablement pas. Même s’ils semblent fonctionner, ils peuvent facilement s’interrompre ultérieurement si Microsoft Entra ID ou votre administrateur d’entreprise ajoute des contrôles de sécurité supplémentaires à votre processus d’authentification de l’utilisateur.

Avertissement

Il est également déconseillé d’enregistrer votre nom d’utilisateur et votre mot de passe, car un tiers pourrait y accéder, puis les utiliser pour emprunter votre identité.

Pour ces raisons, les tâches GitHub Actions intégrées qui interagissent avec Azure ne vous permettent pas de fournir des informations d’identification d’un compte d’utilisateur. Elles nécessitent l’utilisation d’une identité de charge de travail.

Comment fonctionnent les identités de charge de travail ?

Les identités de charge de travail sont une fonctionnalité de Microsoft Entra ID, qui un service d’identité global. De nombreuses entreprises utilisent Microsoft Entra ID, et chaque entreprise est appelée locataire.

Microsoft Entra ID a un concept d’application, qui représente un système, un logiciel, un processus ou tout autre agent qui n’est pas un être humain. Vous pouvez également considérer un flux de travail de déploiement comme une application.

Quand vous créez une application et que vous en informez Microsoft Entra ID, vous créez un objet appelé inscription d’application. Une inscription d’application représente l’application dans Microsoft Entra ID.

Une inscription d’application peut avoir des informations d’identification fédérées associées. Les informations d’identification fédérées ne vous obligent pas à stocker des secrets. Au lieu de cela, elles permettent à un service pris en charge comme GitHub d’utiliser une application Microsoft Entra.

Lorsque votre flux de travail GitHub Actions doit s’authentifier, il contacte Microsoft Entra ID via GitHub. GitHub indique à Microsoft Entra ID le nom de l’organisation GitHub et du référentiel, et éventuellement d’autres informations. Si vous avez configuré des informations d’identification fédérées qui correspondent aux détails du référentiel, Microsoft Entra authentifie votre workflow de déploiement. Le workflow peut utiliser les autorisations que vous avez attribuées à l’application.

Conseil

Quand vous examinez une inscription d’application dans le Portail Microsoft Azure, vous verrez beaucoup d’autres fonctionnalités et configurations qui peuvent ne pas sembler pertinentes. En effet, les applications peuvent effectuer de nombreuses tâches dans Microsoft Entra ID qui n’entrent pas dans le cadre des déploiements d’authentification et de workflow.

Vous pouvez également créer un objet deprincipal de service dans votre locataire Microsoft Entra. Un principal de service est semblable à une copie de l’application que votre propre locataire Microsoft Entra peut utiliser. Les principaux de service et les applications sont étroitement liés. Vous utiliserez un principal de service plus loin dans ce module, lorsque vous accorderez à votre flux de travail l’autorisation d’accéder à Azure.

Notes

Certains outils appellent un principal de service une application d’entreprise. Vous pouvez également voir des principaux de service appelés applications managées dans votre annuaire local, mais il ne s’agit pas de la même chose que les identités managées.