Utilisation des identités managées pour Azure avec Service Fabric

  • Article

Une difficulté courante lors de la création d’applications cloud consiste à gérer en toute sécurité les informations d’identification dans votre code pour l’authentification auprès de différents services sans les enregistrer localement sur une station de travail de développeur ou dans le contrôle de code source. Les identités managées pour Azure résolvent ce problème pour toutes vos ressources dans Microsoft Entra ID en leur fournissant des identités managées automatiquement dans Microsoft Entra ID. Vous pouvez utiliser l’identité d’un service pour vous authentifier auprès d’un service qui prend en charge l’authentification Microsoft Entra, y compris Key Vault, sans aucune information d’identification stockée dans votre code.

Les identités managées pour les ressources Azure sont gratuites avec Microsoft Entra ID pour les abonnements Azure. Il n’y a aucun coût supplémentaire.

Notes

Identités managées pour Azure est le nouveau nom du service, anciennement nommé Managed Service Identity (MSI).

Concepts

Les identités managées pour Azure s’appuient sur plusieurs concepts clés :

  • ID client : identificateur unique généré par Microsoft Entra ID lié à une application et à un principal de service lors de son approvisionnement initial (consultez également ID d’application (client)).

  • ID du principal : ID d’objet du principal de service pour votre identité managée ; il est utilisé pour accorder un accès basé sur les rôles à une ressource Azure.

  • Principal du service : un objet Microsoft Entra, qui représente la projection d’une application Microsoft Entra dans un abonné donné (consultez également principal du service.)

Il existe deux types d’identités administrées :

  • Une identité managée attribué par le système est activée directement sur une instance de service Azure. Le cycle de vie d’une identité attribuée par le système est propre à l’instance de service Azure sur laquelle elle est activée.
  • Une identité managée attribuée par l’utilisateur est créée en tant que ressource Azure autonome. L’identité peut être assignée à une ou plusieurs instances de service Azure et est managée séparément des cycles de vie de ces instances.

Pour mieux comprendre la différence entre les types d’identités managées, consultez Comment fonctionnent les identités managées pour les ressources Azure ?.

Scénarios pris en charge pour les applications Service Fabric

Les identités managées pour Service Fabric ne sont prises en charge que dans les clusters Service Fabric déployés par Azure, et pour les applications déployées en tant que ressources Azure. Une identité ne peut pas être attribuée à une application non déployée en tant que ressource Azure. En théorie, la prise en charge des identités managées dans un cluster Azure Service Fabric est constitué de deux phases :

  1. Attribuez une ou plusieurs identités managées à la ressource d’application ; une application peut se voir attribuer une seule identité attribuée par le système et/ou des identités attribuées par des utilisateurs, jusqu’à 32, respectivement.

  2. Dans la définition de l’application, mappez l’une des identités attribuées à l’application à un service individuel comprenant l’application.

L’identité attribuée par le système d’une application est propre à cette application ; une identité attribuée par l’utilisateur est une ressource autonome, qui peut être attribuée à plusieurs applications. Dans une application, une seule identité (qu’elle soit attribuée par le système ou par l’utilisateur) peut être attribuée à plusieurs services de l’application, mais chaque service individuel ne peut être attribué qu’à une seule identité. Enfin, une identité doit être attribuée explicitement à un service pour pouvoir accéder à cette fonctionnalité. Dans les faits, le mappage des identités d’une application à ses services constitutifs permet une isolation dans l’application : un service peut uniquement utiliser l’identité qui lui est mappée.

Voici les scénarios pris en charge pour cette fonctionnalité :

  • Déployer une nouvelle application avec un ou plusieurs services et une ou plusieurs identités attribuées

  • Attribuer une ou plusieurs identités managées à une application existante (déployée dans Azure) afin d’accéder aux ressources Azure

Les scénarios suivants ne sont ni pris en charge, ni recommandés. Ces actions ne sont pas forcément bloquées, mais peuvent entraîner des pannes dans vos applications :

  • Suppression ou modification des identités attribuées à une application. Si vous avez besoin d’apporter des modifications, envoyez des déploiements distincts pour ajouter une nouvelle attribution d’identité, puis en supprimer une précédemment attribuée. La suppression d’une identité d’une application existante peut avoir des effets indésirables, notamment la sortie de votre application dans un état qui ne peut pas être mis à niveau. La suppression complète de l’application ne pose aucun problème si la suppression d’une identité est nécessaire. La suppression de l’application a pour effet de supprimer toute identité affectée par le système associée à l’application, ainsi que toutes les associations avec des identités affectées par l’utilisateur à l’application.

  • Service Fabric ne prend pas en charge les identités managées dans le paramètres déconseillé AzureServiceTokenProvider. Utilisez plutôt des identités managées dans Service Fabric à l’aide du Kit de développement logiciel (SDK) Azure Identity

Étapes suivantes