Les identités gérées sur Azure : définitions, types, avantages et démo

Les développeurs se retrouvent très fréquemment face à un problème lorsqu'ils doivent sécuriser la communication entre différents services et appareils : c'est la gestion et la sécurisation des identifiants, des clés, des certificats et des secrets au sein de leurs applications cloud natives. Mais il s'avère que le stockage de ces identifiants, secrets et clés directement dans le code de l'application peut exposer l'application à des menaces de sécurité.

Supprimer ces identifiants du code renforce la sécurité de l’application, mais comment gérer ces identifiants, clés et secrets désormais ? C'est là que les identités gérées entrent en jeu. L'utilisation d'identités gérées évite aux développeurs d'avoir à traiter toutes ces informations à la main.

• Définition 
• Types et différences
• Avantages
• Fonctionnement
• Démonstration

Qu'entend-on par identités gérées dans Azure ?

Les identités gérées éliminent la charge de travail manuelle liée à la gestion des identifiants, des secrets, des mots de passe et des clés dans le code de l'application. Ces informations sont alors gérées automatiquement dans Azure Active Directory (AD) lorsqu'elles sont connectées à des ressources prenant en charge l'authentification AD. Les identités gérées peuvent être utilisées pour demander et recevoir des jetons Azure AD sans avoir à contrôler les identifiants, les secrets, les clés et les mots de passe.

Azure Key Vault est une autre solution permettant de stocker et de gérer les secrets et les identifiants d'une application. Dans ce cas, les informations sont stockées dans le coffre-fort Key Vault. Toutefois, l'application doit toujours s'authentifier auprès d'Azure Key Vault pour récupérer les clés et d'autres secrets, ce qui signifie que l'application contient toujours des informations importantes directement dans son code.

Les identités gérées pour les ressources Azure (le nouveau nom du service auparavant appelé Managed Service Identity (MSI)) sont extrêmement puissantes et réduisent la charge de travail associée à la supervision manuelle. Le code reste propre et, si vous utilisez Azure Key Vault, ses configurations n'ont pas besoin d'être conservées dans le code. Vous pouvez également accéder à d'autres ressources Azure prenant en charge l'authentification AD sans stocker leurs chaînes de connexion respectives et d'autres détails de configuration dans l'application. Vous pouvez effectuer des opérations sur les identités gérées à l'aide du portail Azure, d'un modèle ARM, d'Azure CLI, de PowerShell et d'API REST.

Les types d'identités gérées et leurs différences

Il existe deux types d'identités gérées :

1. Les identités gérées attribuées au système
2. Les identités gérées attribuées à l'utilisateur

Ces deux identités ont leurs propres caractéristiques et chacune a ses avantages et ses inconvénients. Passons en revue leurs caractéristiques et leurs différences.

Les identités gérées attribuées au système

Vous pouvez activer des identités gérées attribuées au système sur certains des services Azure les plus couramment utilisés. Lors de l'activation au sein de l'instance de service Azure, une identité est créée dans Azure Active Directory, le principal de service de cette instance de service.

L’identité est également liée au cycle de vie de l’instance de service, ce qui signifie qu’elle est automatiquement supprimée lorsque l’instance est supprimée ou retirée. Lorsque l’identité est supprimée, le principal de service correspondant est également supprimé dans Azure AD.

Les identités gérées attribuées à l'utilisateur

Une autre manière d'utiliser les identités gérées pour les ressources Azure consiste à créer une identité gérée attribuée à l'utilisateur séparément, puis à l'attribuer en tant que ressource Azure autonome. Cette méthode présente l'avantage de pouvoir affecter la même identité gérée à plusieurs services Azure ou à plusieurs instances du service Azure. Étant donné que l’identité gérée attribuée à l’utilisateur est créée séparément, elle n’est pas supprimée lorsque la ressource Azure qui lui est associée est supprimée ou désactivée. 

Différences entre les identités gérées attribuées au système et à l'utilisateur

Pour obtenir la liste complète des services Azure qui prennent en charge les identités gérées, cliquez ici.

Il est important de se rappeler qu'une identité gérée, qu'elle soit attribuée au système ou à l'utilisateur, est un type particulier de principal de service utilisé uniquement avec les ressources Azure.

Comme elles sont synchronisées, les modifications de l’une peuvent affecter l’autre. Par exemple, le principal de service est supprimé lorsque l'identité gérée correspondante est supprimée.

Comment fonctionnent les identités gérées ?

Grâce aux identités gérées, vous pouvez demander des jetons d'accès pour les ressources prenant en charge l'authentification Azure AD.

Les jetons d'accès sont reçus en fonction du RBAC qui leur est attribué sur la ressource. Une fois que la ressource reçoit le jeton d'accès, vous pouvez y accéder. Le plus intéressant, c'est qu'Azure se charge de saisir les identifiants utilisés par l'instance de service, éliminant ainsi la moindre probabilité de fuite de mot de passe.

Sept étapes pour implémenter les identités gérées Azure :

• Étape 1 : la requête est envoyée pour qu'Azure Resource Manager active (dans le cas d'une identité gérée attribuée au système) ou crée (dans le cas d'une identité gérée attribuée à l'utilisateur) une identité gérée.
• Étape 2 : dans le cas de l'identité gérée attribuée au système, lorsque Azure Resource Manager reçoit une demande d'activation d'une identité gérée sur la VM, il crée un principal de service pour l'identité gérée dans AD. Le tenant Azure AD approuvé hébergera le nouveau principal de service.
  • Pour les identités gérées attribuées à l'utilisateur, Azure Resource Manager reçoit la requête de création de l'identité gérée en tant que ressource distincte. Lorsque celle-ci est créée, un principal de service correspondant est également créé par le gestionnaire de ressources dans le tenant Azure AD approuvé.
• Étape 3 : pour les identités gérées attribuées au système, le gestionnaire de ressources met à jour l'identité de la VM à l'aide du point de terminaison de l'identité Azure Instance Metadata Service (IMDS). Cette configuration fournit au terminal l'identifiant client et le certificat du principal de service.
  • Dans le cas des identités gérées attribuées à l'utilisateur, lorsque le gestionnaire de ressources reçoit la requête de configuration de l'identité gérée sur les VM, Azure Resource Manager met ensuite à jour le point de terminaison d'identité IMDS avec l'ID client et le certificat du principal de service de l'identité gérée attribuée à l'utilisateur.
• Étape 4 : après avoir créé le principal de service et activé ou attribué l'identité de la VM, vous devez utiliser les informations du principal de service pour attribuer un RBAC approprié à la ressource Azure.
• Étape 5 : le code de l'application exécuté sur la VM demande un jeton à partir du point de terminaison IMDS, accessible uniquement depuis la VM. Certains paramètres sont envoyés pour les demandes de jetons. Il s'agit de :
  • Paramètre de ressource : représente le service auquel le jeton est envoyé pour authentification
  • Paramètre de version API : représente la version IMDS. Utilisez api-version=2018-02-01 ou supérieur
  • Paramètre ID client : principal de service pour l'identité demandée par le jeton. Ceci s'applique uniquement aux identités gérées attribuées à l'utilisateur, car c'est la seule option pour attribuer plusieurs identités à une seule machine virtuelle.
• Étape 6 : la demande de jeton d'accès est envoyée à Azure AD à l'aide de l'ID client et du certificat. Azure AD renvoie un jeton d'accès JSON Web Token (JWT).
• Étape 7 : le code envoie maintenant le jeton Azure AD pour accéder au service Azure souhaité, tant qu'il prend en charge l'authentification Azure AD.

Création et configuration des identités gérées : démonstration

Vous trouverez ci-dessous les étapes pour créer, configurer et attribuer un RBAC aux identités gérées.

1. Mise en place du scénario : objectifs du labo
2. Conditions requises
3. Phase 1 : Utilisation des identités gérées attribuées au système
4. Phase 2 : Utilisation des identités gérées attribuées à l'utilisateur

Mise en place du scénario : objectifs du labo

Vous pouvez choisir entre configurer l'identité gérée attribuée au système ou l'identité gérée attribuée à l'utilisateur pour vos projets, en fonction de vos exigences et de vos objectifs. Cependant, à des fins de démonstration, ce labo est divisé en deux parties.

Dans la première partie, nous mettrons en place une identité gérée attribuée au système pour une VM sur Azure. Nous fournirons ce principal de service, rôle de contributeur au compte de stockage.

Dans la deuxième partie du labo, nous créerons une identité gérée attribuée à l'utilisateur en tant que ressource distincte, en attribuant cette identité à la VM et en attribuant un RBAC à cette identité sur le compte de stockage.

Conditions préalables pour le labo

1. Un abonnement Azure est requis ; cliquez ici pour vous connecter
2. Un réseau virtuel
3. Une machine virtuelle au sein du réseau virtuel
4. Un compte de stockage pour affecter le RBAC

Première phase : utilisation des identités gérées attribuées au système

1. Connectez-vous au portail Azure et ouvrez la page des machines virtuelles.

2. Dans le menu de gauche, cliquez sur « identité » dans les paramètres.

3. Une fois sur la page Identité, vous remarquerez deux onglets : l'un pour l'identité attribuée au système et l'autre pour l'identité attribuée à l'utilisateur.

4. Dans l'onglet attribué au système, basculez le bouton de statut sur « On ». Une fois terminé, cliquez sur Enregistrer.

5. L'ajout de l'identité gérée attribuée au système prendra quelques secondes.

6. Maintenant, ouvrez la page du compte de stockage et cliquez sur « Contrôle d'accès (IAM) » dans la barre de navigation de gauche.

7. Sur la page de contrôle d'accès, cliquez sur le bouton Ajouter dans la barre de navigation supérieure, puis sur Ajouter une attribution de rôle.

8. Sur la page qui s'affiche, choisissez le rôle que vous voulez donner au principal de service créé et cliquez sur le bouton Suivant en bas de la page.

9. Sélectionnez l'option « Identité gérée » sous « Attribuer l'accès à », puis cliquez sur Sélectionner les membres.

10. Une fenêtre pop-up apparaît sur le côté droit. Choisissez « machine virtuelle » dans la liste déroulante « Identité gérée ». Le principal de service nouvellement créé pour la VM apparaîtra pour être sélectionné.

11. Sélectionnez le principal de service approprié qui apparaît et cliquez sur le bouton « Sélectionner ».

12. Cliquez maintenant sur le bouton « Vérifier + attribuer ».

13. Une fois sur la page de confirmation, cliquez à nouveau sur le bouton « Vérifier + attribuer ».

14. Le rôle attribué ultérieurement sera visible sous l'onglet Attributions de rôles.

Deuxième phase : travailler avec les identités gérées attribuées à l'utilisateur

1. Sur la page de la VM, cliquez sur la barre de recherche et recherchez « identité gérée ».

2. Sélectionnez la première option qui apparaît. Une fois sur la page des identités gérées, cliquez sur le bouton « Créer » dans la barre de navigation supérieure.

3. Sur la page « Créer une identité gérée attribuée à l'utilisateur », sélectionnez l'abonnement, le groupe de ressources et l'emplacement. Enfin, donnez un nom à votre identité gérée (dans cet exemple, il s'agit de « vmidentity ». Une fois terminé, cliquez sur le bouton « Vérifier + créer ».

4. Une fois la validation terminée, cliquez sur le bouton Créer pour provisionner l'identité gérée.

5. Revenez à la page de la VM et sous les paramètres, puis cliquez sur « identité ». Sur la page de l'identité, cliquez sur l'onglet « attribué à l'utilisateur ».

6. Dans l'onglet attribué à l'utilisateur, cliquez sur « Ajouter » dans la barre de navigation supérieure. Une fenêtre pop-up apparaîtra sur le côté droit. Sélectionnez l'identité gérée que vous venez de créer (« vmidentity » dans ce cas) et cliquez sur Ajouter.

7. L'identité apparaîtra désormais sous la page « identité gérée attribuée à l'utilisateur ».

8. Revenez maintenant au compte de stockage et cliquez sur Contrôle d'accès (IAM). Une fois sur la page de contrôle d'accès, cliquez sur Ajouter dans la barre de navigation supérieure et sélectionnez « Ajouter une attribution de rôle ».

10. Sélectionnez « Identité gérée » sous « Attribuer l'accès à » et cliquez ensuite sur Sélectionner des membres. Une fenêtre pop-up apparaît sur le côté droit. Sélectionnez l'identité gérée attribuée à l'utilisateur nouvellement créée et cliquez sur le bouton Sélectionner.

11. À présent, cliquez sur le bouton « Vérifier + attribuer » sur la page principale. Après validation, cliquez à nouveau sur « Vérifier + attribuer ».

12. Il faudra quelques secondes pour que l'identité gérée attribuée à l'utilisateur soit provisionnée pour le compte de stockage.

Maintenant que vous avez attribué un rôle aux identités gérées dans le compte de stockage, vous pouvez accéder aux ressources de stockage à partir de la VM.

Conclusion

Les identités gérées sont utiles car elles permettent de gérer automatiquement des identités de charge de travail qui s'authentifient auprès d'Azure Active Directory. Les applications obtiennent des jetons auprès d'Azure AD sans avoir à gérer les identifiants et les secrets au sein du code de l'application. Vous pouvez attribuer ces rôles d'identités à d'autres ressources prenant en charge l'authentification Azure AD pour accéder à ces ressources. Pour les développeurs et les administrateurs, cela supprime la tâche manuelle de gestion des identifiants au sein du code de l'application ou des charges de travail, ce qui réduit les risques de fuite de mot de passe ou de failles de sécurité.