Créer un principal de service et une clé

Effectué

Maintenant que vous comprenez le concept du principal de service, vous vous demandez peut-être comment il prouve son identité à Microsoft Entra ID. Dans cette leçon, vous allez découvrir le processus d’authentification et les informations d’identification pour les principaux du service. Vous allez également apprendre à créer un principal de service et à lui attribuer une clé.

Comprendre comment les principaux de service sont authentifiés

Quand un principal de service doit communiquer avec Azure, il se connecte à Microsoft Entra ID. Une fois que Microsoft Entra ID a vérifié l’identité du principal de service, il émet un jeton que l’application cliente stocke et utilise quand elle envoie des requêtes à Azure.

Globalement, ce processus ressemble à la façon dont vous vous connectez à Azure vous-même en tant qu’utilisateur. Toutefois, par rapport aux utilisateurs, les principaux de service disposent d’un type d’informations d’identification légèrement différent pour prouver leur identité. Les principaux de service utilisent deux informations d’identification principales : les clés et les certificats.

Notes

N’oubliez pas que les identités managées sont des principaux de service spéciaux qui fonctionnent dans Azure. Elles disposent d’un autre type de processus d’authentification qui ne nécessite pas de connaître ni de gérer les informations d’identification.

Keys

Les clés sont similaires aux mots de passe. Toutefois, les clés sont beaucoup plus longues et plus complexes. En fait, pour la plupart des situations, Microsoft Entra ID génère des clés elle-même pour s’assurer que :

  • Les clés sont aléatoires par chiffrement. Autrement dit, elles sont extrêmement difficiles à deviner.
  • Les êtres humains ne peuvent pas utiliser accidentellement des mots de passe faibles comme clés.

Les principaux de service disposent souvent d’autorisations à privilèges élevés. Il est donc essentiel qu’ils soient sécurisés. En règle générale, vous devez uniquement gérer la clé brièvement lors de la configuration initiale du principal de service et de votre pipeline. La clé n’a donc pas besoin d’être facile à taper ni à mémoriser.

Un principal de service unique peut avoir plusieurs clés en même temps, mais les utilisateurs ne peuvent pas avoir plusieurs mots de passe. Comme les mots de passe, les clés ont une date d’expiration. Vous en apprendrez davantage à ce sujet ultérieurement.

Notes

Considérez les clés comme des mots de passe très importants, comme les clés de compte de stockage. Vous devez les traiter avec le même niveau de sécurité et de précaution.

Certificats

Les certificats constituent une autre façon d’authentifier les principaux de service. Ils sont très sécurisés, mais ils peuvent s’avérer difficiles à gérer. Certaines organisations requièrent l’utilisation de certificats pour certains types de principaux de service.

Nous n’aborderons pas les certificats dans ce module. Toutefois, si vous utilisez un principal de service qui utilise l’authentification par certificat, il fonctionne de la même façon que n’importe quel autre principal de service en termes de gestion et d’octroi d’autorisation pour votre pipeline.

Notes

Les certificats sont une bonne solution quand vous pouvez les utiliser. Ils sont plus difficiles à dérober pour les attaquants. Il est également plus difficile d’intercepter et de modifier les requêtes utilisant des certificats. Toutefois, les certificats nécessitent une infrastructure plus importante et présentent une surcharge de maintenance continue.

Utiliser des clés pour les principaux de service

Quand vous créez un principal de service, vous demandez généralement à Azure de créer une clé en même temps. Azure génère habituellement une clé aléatoire pour vous.

Remarque

Vous vous souvenez du fonctionnement des principaux de service que nous avons abordé précédemment ? Les clés sont stockées dans le cadre de l’objet d’inscription d’application. Si vous ouvrez le Portail Azure, effectuez une recherche dans la configuration Microsoft Entra, puis accédez aux inscriptions d’application. Vous pouvez également y créer et supprimer des clés.

Azure affiche la clé quand vous créez le principal de service. Il s’agit de la seule fois où Azure vous montre la clé. Après cela, vous ne pouvez plus la récupérer. Il est important de copier la clé de manière sécurisée afin de pouvoir l’utiliser quand vous configurez votre pipeline. Ne partagez pas la clé par e-mail ou via un autre moyen non sécurisé. Si vous perdez une clé, vous devez la supprimer et en créer une nouvelle.

Gérer les principaux de service pour Azure Pipelines

Quand vous créez une clé pour le principal de service d’un pipeline, il est judicieux de copier immédiatement la clé dans la configuration du pipeline. De cette façon, vous évitez de stocker la clé ou de la transmettre inutilement.

Les outils de pipeline incluent des méthodes sécurisées pour spécifier la clé et l’ID d’application de votre principal de service. Ne stockez jamais d’informations d’identification d’aucune sorte dans le contrôle de code source. À la place, utilisez des connexions de service quand vous utilisez Azure Pipelines. Dans ce module, nous avons uniquement abordé la création d’un principal de service et d’une clé. Vous allez découvrir comment configurer votre pipeline avec la clé dans un module ultérieur.

Conseil

Azure Pipelines peut créer automatiquement des principaux de service à votre place. Dans ce module, vous allez créer et gérer manuellement vos principaux de service afin de mieux comprendre ce qui se passe. Dans d’autres modules, vous allez utiliser la méthode de création automatique par souci de simplicité.

Créer un principal de service et une clé

Vous pouvez utiliser l’interface Azure CLI pour créer et gérer des principaux de service.

Remarque

Vous avez besoin des autorisations associées dans Microsoft Entra ID pour créer et modifier des principaux de service. Dans certaines organisations, il peut être nécessaire qu’un administrateur effectue ces étapes à votre place.

Pour créer un principal de service et une clé, utilisez la commande az ad sp create-for-rbac. Cette commande accepte plusieurs arguments et peut attribuer des rôles au principal de service si vous le souhaitez. Vous en apprendrez davantage à ce sujet ultérieurement dans ce module. Pour le moment, voici un exemple qui illustre la création d’un principal de service sans attributions de rôle Azure :

az ad sp create-for-rbac --name MyPipeline

Quand vous exécutez cette commande, l’interface Azure CLI retourne une réponse JSON avec une propriété password. Cette propriété est la clé du principal de service. Vous ne pouvez pas récupérer cette clé. Vous devez donc l’utiliser immédiatement ou l’enregistrer à un emplacement sécurisé.

Remarque

La commande az ad sp create-for-rbac crée une inscription d’application dans Microsoft Entra ID, ajoute un principal de service à votre locataire Microsoft Entra et crée une clé pour l’inscription d’application. Une autre commande, az ad sp create, crée uniquement le principal de service dans votre locataire (pas l’inscription d’application). Quand vous créez des principaux de service pour les pipelines, la commande az ad sp create-for-rbac est généralement la meilleure option.

Vous pouvez utiliser les cmdlets Azure PowerShell pour créer et gérer des principaux de service.

Remarque

Vous avez besoin des autorisations associées dans Microsoft Entra ID pour créer et modifier des principaux de service. Dans certaines organisations, il peut être nécessaire qu’un administrateur effectue ces étapes à votre place.

Pour créer un principal de service et une clé, utilisez la cmdlet New-AzADServicePrincipal. Cette cmdlet accepte plusieurs arguments et peut attribuer des rôles au principal de service si vous le souhaitez. Vous en apprendrez davantage à ce sujet ultérieurement dans ce module. Pour le moment, voici un exemple qui illustre la création d’un principal de service sans attributions de rôle Azure :

$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline

Quand vous exécutez cette commande, Azure PowerShell remplit la variable servicePrincipal à l’aide d’informations sur le principal de service, notamment la clé.

$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText

Vous ne pouvez pas récupérer cette clé. Vous devez donc l’utiliser immédiatement ou l’enregistrer à un emplacement sécurisé.

Remarque

La cmdlet New-AzADServicePrincipal crée une inscription d’application dans Microsoft Entr IDa, ajoute un principal de service à votre locataire Microsoft Entra et crée une clé pour l’inscription d’application.

Identifier un principal de service

Les principaux de service ont plusieurs identificateurs et noms que vous utilisez pour les identifier et les utiliser. Les identificateurs les plus couramment utilisés sont :

  • ID d’application : l’inscription d’application possède un identificateur unique, souvent appelé ID d’application ou parfois ID client. En général, vous l’utilisez comme nom d’utilisateur quand le principal de service se connecte à Azure.
  • ID d’objet : L’inscription d’application et le principal de service ont leurs propres ID d’objets distincts, qui sont des identificateurs uniques attribués par Microsoft Entra ID. Parfois, vous devrez utiliser ces ID d’objet quand vous gérez un principal de service.
  • Nom d’affichage : il s’agit d’un nom explicite qui décrit le principal de service.

Conseil

Utilisez un nom d’affichage clair et descriptif pour votre principal de service. Il est important d’aider votre équipe à comprendre ce qu’est un principal de service, de sorte que personne ne le supprime accidentellement ou ne modifie ses autorisations.

Attention

Un nom d’affichage n’est pas unique. Plusieurs principaux de service peuvent partager le même nom d’affichage. Soyez prudent quand vous octroyez des autorisations à un principal de service en l’identifiant par son nom d’affichage. Vous pouvez accidentellement accorder des autorisations à un principal de service incorrect. Il est recommandé d’utiliser l’ID d’application à la place.

Quand vous créez un principal de service, vous définissez en général uniquement le nom d’affichage. Azure attribue automatiquement les autres noms et identificateurs.

Gérer les clés expirées

Les principaux de service n’expirent pas, contrairement à leurs clés. Quand vous créez une clé, vous pouvez configurer son délai d’expiration. Par défaut, le délai d’expiration est défini sur un an. Une fois ce délai d’expiration écoulé, la clé ne fonctionne plus et le pipeline ne peut pas se connecter à Microsoft Entra ID. Vous devez régulièrement renouveler les clés ou effectuer une rotation.

Attention

Il est tentant de définir des délais d’expiration longs pour vos clés, mais cela est déconseillé. Les principaux de service sont protégés uniquement par leurs informations d’identification. Si un attaquant obtient la clé d’un principal de service, il peut provoquer des dommages importants. La meilleure approche pour réduire la durée maximale d’une attaque consiste à changer régulièrement vos clés. Vous devez également supprimer et recréer les clés si vous soupçonnez une fuite.

Pour réinitialiser une clé pour un principal de service, utilisez la commande az ad sp avec l’ID d’application, comme dans l’exemple suivant :

az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"

Vous pouvez également supprimer et recréer la clé du principal de service en deux étapes distinctes à l’aide des commandes az ad sp credential delete puis az ad sp credential reset --append.

Pour réinitialiser une clé pour un principal de service, commencez par utiliser la cmdlet Remove-AzADServicePrincipalCredential pour supprimer les informations d’identification existantes. Utilisez ensuite la cmdlet New-AzADServicePrincipalCredential pour ajouter de nouvelles informations d’identification. Ces cmdlets utilisent l’ID d’objet du principal de service pour l’identifier. Avant d’utiliser les cmdlets, vous devez obtenir cet ID à partir de l’ID d’application :

$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id

Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId

$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText

Conseil

Un principal de service unique peut avoir plusieurs clés. Vous pouvez mettre à jour votre application en toute sécurité pour utiliser une nouvelle clé alors que l’ancienne clé est toujours valide, puis supprimer l’ancienne clé quand elle n’est plus utilisée. Cette technique évite les temps d’arrêt dus à l’expiration de la clé.

Gérer le cycle de vie de votre principal de service

Il est important de prendre en compte le cycle de vie complet de chaque principal de service que vous créez. Quand vous créez un principal de service pour un pipeline, que se passe-t-il si le pipeline est ensuite supprimé ou s’il n’est plus utilisé ?

Les principaux de service ne sont pas supprimés automatiquement. Vous devez donc auditer et supprimer les anciens principaux de service. Il est important de supprimer les anciens principaux de service pour la même raison que vous supprimez les anciens comptes d’utilisateur : des attaquants pourraient accéder aux clés. Il est préférable qu’il n’existe pas d’informations d’identification qui ne sont pas utilisées activement.

Il est recommandé de documenter vos principaux de service dans un emplacement accessible facilement à vous et à votre équipe. Vous devez inclure les informations suivantes pour chaque principal de service :

  • Informations d’identification essentielles, notamment son nom et son ID d’application.
  • Finalité du principal de service.
  • Personne qui l’a créé, celle qui est responsable de sa gestion et de ses clés, et celle qui est susceptible d’apporter des réponses en cas de problème.
  • Les autorisations nécessaires, ainsi qu’une justification claire de la raison pour laquelle elles sont nécessaires.
  • Durée de vie attendue.

Vous devez régulièrement auditer vos principaux de service pour vous assurer qu’ils sont toujours en cours d’utilisation et que les autorisations attribuées sont toujours correctes.