Identités gérées dans Microsoft Discovery

Microsoft Discovery utilise des identités managées attribuées par l’utilisateur (UAMI) pour s’authentifier auprès des ressources Azure en votre nom. Au lieu de gérer les secrets ou les chaînes de connexion, vous créez une identité managée, accordez-lui les rôles nécessaires Azure et fournissez son ID de ressource lorsque vous créez des ressources de découverte. La plateforme de découverte utilise ensuite cette identité pour accéder aux comptes de stockage, aux registres de conteneurs, aux services IA et aux ressources mrG (Managed Resource Group).

Pourquoi utiliser des identités managées affectées par l’utilisateur

La découverte nécessite des identités managées attribuées par l’utilisateur (et non attribuées par le système) pour les raisons suivantes :

Reason Explanation
Prise en charge par le client Vous créez, gérez et contrôlez le cycle de vie de l’identité dans votre propre abonnement.
Partagé entre plusieurs ressources Vous pouvez réutiliser une seule UAMI sur un espace de travail, un supercalculateur et des opérations de stockage, ce qui réduit la surcharge de gestion.
Attributions de rôles avec provisionnement électronique Vous attribuez des rôles avant la création de ressources afin que la découverte dispose des autorisations dont elle a besoin à partir du début.
liaison non modifiable L’identité de l’espace de travail et l’identité du cluster de supercomputer sont liées au moment de la création et ne peuvent pas être modifiées ultérieurement, ce qui garantit une posture de sécurité cohérente. Vous pouvez mettre à jour les identités kubelet et de charge de travail du superordinateur après sa création.

Important

L’identité de l’espace de travail et l’identité du cluster supercomputer sont immuables après la création. Vous ne pouvez pas les modifier après leur approvisionnement. Vous pouvez mettre à jour le kubelet du superordinateur et les identités de charge de travail. Planifiez votre stratégie d’identité avant de créer des ressources.

Comment Discovery utilise votre identité

Lorsqu’un espace de travail ou un supercalculateur est créé, le plan de contrôle Discovery :

  • Lit votre UAMI : vérifie que l’identité existe et que le service peut fonctionner dessus.
  • S’attribue le rôle d’opérateur d’identité managée : le principal de service Discovery se voit attribuer le rôle Opérateur d’identité managée sur votre UAMI afin de pouvoir utiliser l’identité pour les opérations sur les ressources managées.
  • Utilise l’UAMI lors de l’exécution : les exécutions de l’outil sur le superordinateur utilisent cette identité pour récupérer des images de conteneur et accéder au stockage blob. Les agents l’utilisent pour interagir avec Azure OpenAI et le stockage.

Emplacements d’identité par type de ressource

Différentes ressources de découverte utilisent des identités managées de différentes façons.

Workspace

Un espace de travail nécessite un seul UAMI fourni par la propriété workspaceIdentity. La détection utilise votre UAMI pour :

  • Identifiez votre espace de travail : UAMI est le principal de sécurité qui lie l’espace de travail aux ressources de votre abonnement.
  • Lire et écrire des données : Stockage Blob Azure comptes lisent et écrivent des données via des conteneurs de stockage.
  • Extraire des images de conteneur : les images de conteneur sont extraites depuis Azure Container Registry lorsque vous exécutez des outils sur un supercalculateur.

Discovery provisionne et exploite le MRG (Azure Cosmos DB, les services d’IA, les index de recherche et Azure OpenAI) à l’aide de ses propres principaux de service, et non de votre UAMI. Votre UAMI n'a pas besoin de rôles sur le MRG.

Supercalculateur

Un supercalculateur utilise trois emplacements d’identité, qui peuvent tous faire référence au même UAMI par souci de simplicité, ou à des UAMI distincts afin de respecter le principe du moindre privilège.

Plage Objectif
Identité du cluster Utilisé par le plan de contrôle AKS pour gérer les ressources au niveau du cluster, telles que la mise en réseau et les équilibreurs de charge.
Identité Kubelet Utilisé au niveau du nœud pour extraire des images conteneur à partir de Container Registry et accéder aux ressources Azure.
Identité de la charge de travail Utilisé comme informations d’identification fédérées par des pods exécutant des outils et des agents sur le supercalculateur.

Étagère

Une bibliothèque référence votre UAMI par le biais de sa propriété workloadIdentities. Discovery utilise ses propres principaux de service pour approvisionner et exploiter le MRG de la bibliothèque (AI Search, SQL, AI Services). Le service crée également une identité gérée par le système à l'intérieur du MRG bookshelf pour l'authentification interne entre ressources.

Attributions de rôles requises

Vous devez attribuer les rôles intégrés suivants à votre UAMI avant de créer des ressources de découverte. Attribuez ces rôles à l’étendue du groupe de ressources .

Rôle ID de définition de rôle Objectif
contributeur de plateforme de découverte Microsoft (préversion) 01288891-85ee-45a7-b367-9db3b752fc65 Gérez les ressources de découverte, telles que les espaces de travail, les projets, les agents et les outils.
Contributeur aux données du Blob de stockage ba92f5b4-2d11-453d-a403-e96b0029c9fe Lire et écrire des objets blob dans des comptes de stockage Azure.
AcrPull 7f951dda-4ed3-4680-a7ca-43fe172d538d Récupérez des images conteneur depuis Container Registry.

Pour obtenir d’autres rôles nécessaires dans des scénarios spécialisés, consultez Configurer des identités managées.

Flux d’identité de bout en bout dans les ressources Discovery

Lorsque vous déployez une pile Discovery complète, la plateforme crée trois MRG (espace de travail, bibliothèque et superordinateur). Chaque MRG contient Azure ressources que le service gère.

Ce que le service gère automatiquement

Lorsque vous créez un espace de travail, une bibliothèque ou un superordinateur, Discovery effectue automatiquement :

  • Crée des attributions de rôles sur le MRG afin que le service puisse approvisionner et exploiter des ressources MRG. Les ressources incluent Microsoft Foundry, Azure Cosmos DB, Recherche Azure AI, Storage, Azure Key Vault et Azure Kubernetes Service (AKS).
  • Attribue le rôle Managed Identity Operator à votre UAMI afin que le service puisse l'utiliser pour les déploiements de MRG.
  • Crée une identité managée par le système dans chaque MRG d'espace de travail et de bibliothèque pour l'authentification interne entre ressources (Azure Container Apps, Foundry, SQL).

Vous n’avez pas besoin de créer ou de gérer l’une de ces identités ou attributions de rôles. Ils sont entièrement gérés par le service tout au long de leur cycle de vie.

Ce que vous êtes responsable de

Vous êtes responsable des tâches suivantes :

  • Créez votre UAMI : Attribuez les trois rôles principaux (Contributeur de plateforme de découverte, Contributeur aux données Blob de stockage et AcrPull) avant de créer des ressources de découverte.
  • Indiquez l’ID de ressource UAMI : entrez l’ID lorsque vous créez un espace de travail ou un supercomputer.

Votre UAMI au moment de l’exécution

Votre UAMI est l’identité que les agents et les outils utilisent au moment de l’exécution.

Operation Azure ressource accessible Rôle requis
Lecture/écriture des données au sein des conteneurs de stockage Stockage Blob Azure Contributeur aux données du Blob de stockage
Récupérer les images de conteneurs des outils Container Registry AcrPull
Gérer les ressources de découverte Fournisseur de ressources de découverte contributeur de plateforme de découverte Microsoft (préversion)
Exploiter le réseau du cluster AKS sous-réseaux du réseau virtuel Azure (VNet) Contributeur réseau (identité de cluster supercomputer)

Pour le supercomputer, votre UAMI est utilisé dans trois emplacements :

  • Identité du cluster : le plan de contrôle AKS l’utilise pour gérer les équilibreurs de charge et la mise en réseau.
  • Identité Kubelet : l’agent au niveau du nœud l’utilise pour extraire des images à partir de Container Registry et accéder aux ressources Azure.
  • Identité de charge de travail : les pods utilisent des identifiants fédérés pour exécuter des outils et des agents.

Pour obtenir des conseils sur le choix entre un UAMI partagé unique et des identités distinctes par fonction, consultez les recommandations relatives aux meilleures pratiques d’identité managée.

Configuration avancée : attributions de rôles granulaires par identité

La section attributions de rôles requises décrit l’approche la plus simple où un UAMI partagé unique reçoit les trois rôles principaux dans l’étendue du groupe de ressources. Pour les environnements de production qui nécessitent un contrôle de sécurité plus strict, affectez des UAMIs distincts avec des attributions de rôles avec des privilèges minimum limités aux ressources spécifiques auxquelles chaque identité accède.

Important

L’identité associée à la charge de travail est accessible aux agents grâce à l’exécution de l’outil. Les agents basés sur de grands modèles de langage (LLM) appellent des outils qui utilisent cette identité à l’exécution ; il est donc essentiel de réduire au strict minimum les autorisations associées à l’identité de charge de travail. Affectez uniquement les autorisations strictement nécessaires pour les opérations d’outil. Des autorisations trop étendues sur l’identité de charge de travail présentent un risque si un agent l’utilise au-delà du périmètre prévu.

Attributions de rôles par identité

Le tableau suivant montre l’attribution de rôle granulaire recommandée pour chaque identité lorsque vous utilisez des UAMIs distincts.

Identité Rôle Scope Objectif
Identité de l’espace de travail contributeur de plateforme de découverte Microsoft (préversion) Groupe de ressources Gérez les ressources de l’espace de travail telles que les projets, les déploiements de modèles de conversation et les conteneurs de stockage.
Identité de l’espace de travail Contributeur aux données du Blob de stockage Compte de stockage Lire et écrire les données de l’espace de travail, les artefacts du modèle de chat et les ressources du projet dans le compte de stockage sous-jacent.
Identité du cluster Contributeur réseau géré par la plateforme Groupe de ressources de nœud/réseau virtuel Gérez la mise en réseau au niveau du cluster, les équilibreurs de charge et les ressources de groupe de ressources de nœud.
Identité du cluster Opérateur d’identité managée Groupe de ressources de nœud Effectuer des opérations sur les identités managées des charges de travail du cluster.
Identité Kubelet AcrPull Groupe de ressources (couvre Container Registry) Extraire les images de conteneur pour les exécutions d'outils depuis tout registre de conteneurs approvisionné dans le groupe de ressources.
Identité Kubelet Contributeur aux données du Blob de stockage Compte de stockage Lire les artefacts et les entrées des charges de travail depuis le compte de stockage sous-jacent au démarrage des pods.
Identité de la charge de travail Contributeur aux données du Blob de stockage Compte de stockage Accéder aux données pendant l'exécution des outils par les charges de travail des agents (identité fédérée).

Pourquoi les identités distinctes améliorent la sécurité

Lorsque vous utilisez une seule UAMI partagée, l’identité de charge de travail (que les agents utilisent via l’exécution d’outils) hérite de tous les rôles, y compris Discovery Platform Contributor et AcrPull. Cela accorde aux agents pilotés par LLM un accès plus large qu’ils n’en ont besoin.

En séparant les identités :

  • L'identité de charge de travail reçoit uniquement le rôle Storage Blob Data Contributor au niveau du compte de stockage, ce qui limite les données auxquelles les agents peuvent accéder via les outils.
  • L'identité du cluster reçoit des rôles de mise en réseau et d'opérateur qui ne sont jamais exposés aux charges de travail des agents.
  • L'identité kubelet gère l'extraction des images et l'accès aux données au démarrage des pods, de manière isolée de l'exécution des outils des agents.

Cette séparation garantit que même si un agent tente d’utiliser son identité pour les opérations au-delà de l’accès aux données, la demande échoue en raison d’autorisations insuffisantes.

Quand utiliser des affectations granulaires

Utilisez des identités distinctes avec des rôles délimités lorsque :

  • Votre organisation nécessite un contrôle d’accès avec privilèges minimum.
  • Vous exécutez des outils qui traitent des données sensibles et vous souhaitez limiter le rayon d’explosion.
  • Vos exigences de conformité imposent la séparation des identités de plan de contrôle et de plan de données.
  • Vous souhaitez auditer l’accès aux données de l’agent indépendamment des opérations d’infrastructure.

Pour obtenir des conseils sur le choix entre les identités partagées et distinctes, consultez les recommandations relatives aux meilleures pratiques d’identité managée.

Limites

  • L’UAMI doit se trouver dans la même région que la ressource de découverte qui l’utilise.
  • L’identité de l’espace de travail et l’identité du cluster de supercomputer ne peuvent pas être modifiées après la création de la ressource. Vous devez supprimer et recréer la ressource. Vous pouvez mettre à jour les identités kubelet et de charge de travail du superordinateur via PATCH.
  • La propagation de l’attribution de rôle peut prendre jusqu’à 10 minutes. Créez des attributions de rôles avant de créer des ressources de découverte.
  • La découverte nécessite le rôle Opérateur d’identité managée sur votre UAMI. Si cette attribution de rôle échoue lors de la création de ressources (par exemple, en raison de restrictions Azure Policy), l’approvisionnement de l’espace de travail échoue.

Contenu connexe

  • Dernière mise à jour :