Comprendre les principaux de service
Les principaux de service permettent d’authentifier les pipelines, les applications et les logiciels. Dans cette leçon, vous allez découvrir pourquoi les principaux de service sont importants pour les pipelines de déploiement, la façon dont ils s’intègrent au modèle de sécurité d’Azure, ainsi que leur fonctionnement.
Pourquoi un pipeline doit-il s’authentifier ?
Quand vous déployez un modèle 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 modèle Bicep pour déployer le site web de votre entreprise de jouets. Le modèle Bicep déclare les ressources qui incluent un plan Azure App Service, une application et une instance Application Insights.
Quand vous déployez le modèle, 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 s’assure que leur configuration correspond à celle que vous spécifiez dans le modèle.
Toutes ces opérations requièrent des autorisations, 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 modèle. Pour déployer l’exemple de modèle Bicep 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 considérés comme 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 modèles 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 pipeline, vous devez utiliser un autre type d’identité, car le pipeline exécute lui-même les déploiements sans votre implication directe.
Types de principaux de sécurité
Microsoft Entra ID est le service qui gère les identités pour Azure. Microsoft Entra ID dispose de plusieurs types d’identités, également appelées principaux de sécurité :
- Un utilisateur représente un être humain qui se connecte généralement de manière interactive à l’aide d’un navigateur. Les utilisateurs ont souvent des vérifications de sécurité supplémentaires à effectuer quand ils se connectent, par exemple l’authentification MFA (authentification multifacteur) et l’accès conditionnel en fonction de leur localisation ou du réseau.
- 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.
- Un principal de service représente un processus ou un système automatisé qui n’est généralement pas directement exécuté par un être humain.
- Une identité managée est un type spécial de principal de service conçu pour les situations où un être humain n’est pas impliqué dans le processus d’authentification.
Principaux de service
Un principal de service est un type de compte. Il 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 principaux de service ne sont pas protégés par l’authentification multifacteur ni par des protections similaires, car celles-ci nécessitent qu’une personne effectue une action pour prouver son identité.
Dans Microsoft Entra ID, un principal de service est identifié par un ID d’application et des informations d’identification. L’ID d’application est un identificateur global unique (GUID). Pour les pipelines, les informations d’identification correspondent généralement à un mot de passe fort appelé clé. Vous pouvez également utiliser un certificat comme informations d’identification.
Identités managées
Contrairement aux autres types de principaux de service, une identité managée ne nécessite pas que vous connaissiez les informations d’identification ni que vous les conserviez. 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 pipelines, vous ne pouvez généralement pas utiliser les identités managées. En effet, 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 Azure Pipelines, vous vous basez généralement sur l’infrastructure partagée fournie par Microsoft.
Notes
Dans certains cas, les pipelines peuvent utiliser des identités managées. Dans Azure Pipelines, vous pouvez créer un agent autohébergé pour exécuter les scripts et le code de votre pipeline sur votre propre machine virtuelle basée sur Azure. Étant donné que vous êtes propriétaire de la machine virtuelle, vous pouvez lui attribuer une identité managée et l’utiliser à partir de votre pipeline.
Toutefois, vos pipelines s’exécutent la plupart du temps à l’aide d’un agent hébergé, qui est un serveur managé par Microsoft. Les agents hébergés ne sont actuellement pas compatibles avec les identités managées.
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. Elle est plus facile à utiliser et généralement plus sécurisée.
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 pipeline, 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 l’authentification multifacteur, 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 pipelines 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 pipelines sont liés au fait qu’ils sont entièrement automatisés et ne nécessitent pas d’interaction humaine. Si vous stockez votre nom d’utilisateur et votre mot de passe dans un pipeline 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 de pipeline intégrées qui interagissent avec Azure ne vous permettent pas de fournir des informations d’identification d’un compte d’utilisateur. Elles requièrent l’utilisation d’un principal de service.
Comment fonctionnent les principaux de service ?
Vous allez rencontrer quelques termes en utilisant les principaux de service ou les outils comme le portail Azure ou l’API Microsoft Graph. Bien qu’il ne soit pas nécessaire de comprendre ces termes pour utiliser les principaux de service dans un pipeline, il est utile de se familiariser un peu avec ces concepts.
Les principaux de service sont une fonctionnalité de Microsoft Entra ID. Microsoft Entra ID est 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 considérer un pipeline de déploiement comme une application.
Dans Microsoft Entra ID, les applications peuvent effectuer de nombreuses tâches qui n’entrent pas dans le cadre des déploiements d’authentification et de pipelines. 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.
Les principaux de service et les applications sont étroitement liés. Chaque fois qu’une inscription d’application est ajoutée à un locataire Microsoft Entra, un objet principal de service est créé dans ce locataire Microsoft Entra. Quand vous examinez un principal de service dans le portail Azure, vous voyez beaucoup d’autres fonctionnalités et configurations qui peuvent ne pas sembler pertinentes. Cela est souvent dû au fait que les principaux du service sont liés aux applications.
Quand vous créez un principal de service, la plupart des outils que vous utilisez créent également une inscription d’application en même temps. Il est possible que vous ne remarquiez pas qu’il existe deux objets différents.
Un type de principal de service n’est pas associé à une inscription d’application : l’identité managée. Comme indiqué précédemment, Azure gère la configuration et les informations d’identification d’une identité managée.
Notes
Un principal de service est parfois appelé application d’entreprise. Certains outils utilisent un nom et d’autres outils utilisent l’autre. 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.
En résumé, quand vous créez un principal de service, vous créez d’abord une inscription d’application, puis vous créez un principal de service que l’inscription de l’application va utiliser. La plupart des outils que vous utilisez s’en chargeront pour vous, sans que vous vous en rendiez compte. Vous ne pouvez pas utiliser toutes les fonctionnalités des applications Microsoft Entra quand vous utilisez des pipelines de déploiement. Toutefois, étant donné que les principaux de service sont liés aux applications, la même structure d’objet Microsoft Entra s’applique.