Identité de l’agent dans l’agent Azure SRE

Lorsque vous créez un agent, Azure provisionne automatiquement les ressources d’identité. Cet article explique ce qui est créé, pourquoi deux identités existent et comment les connecteurs les utilisent.

Pour plus d’informations sur la façon dont votre agent obtient des autorisations sur les ressources Azure (rôles RBAC, niveaux d’autorisation, au nom du flux), consultez Autorisations de l’agent.

Ce qui est créé

Deux identités managées sont créées en même temps que votre agent.

Identité Présentation Ce que vous faites avec elle
Identité managée attribuée par l’utilisateur (UAMI) Ressource d’identité autonome dans votre groupe de ressources Attribuez des rôles RBAC, sélectionnez-le lors de la configuration des connecteurs. Il s’agit de l’identité que vous gérez
Identité managée affectée par le système Identité interne utilisée par l’infrastructure de l’agent Rien : cette identité est gérée automatiquement et utilisée uniquement pour les opérations internes

L’UAMI est l’identité avec laquelle vous travaillez. Il apparaît dans votre groupe de ressources, vous lui attribuez des rôles RBAC et vous le sélectionnez lors de la configuration des connecteurs.

Conseil / Astuce

Lorsque vous voyez une liste déroulante d’identité managée dans le portail (pour les connecteurs, les référentiels ou d’autres intégrations), sélectionnez l’UAMI de votre agent. Il s’agit de l’identité qui correspond à vos attributions de rôles RBAC.

Dans quels contextes l’UAMI de votre agent est utilisé

L’UAMI de votre agent est l’identité principale pour la plupart des opérations.

Operation Identité Remarques
Opérations de ressources Azure (Azure Resource Manager, CLI, diagnostics) UAMI Les rôles RBAC que vous attribuez déterminent ce que l’agent peut accéder
Connecteurs de communication (Outlook, Teams) UAMI + vos informations d’identification OAuth Vous vous connectez via OAuth ; l'UAMI gère l'authentification vers la ressource du connecteur.
Connecteurs de données (Azure Data Explorer) UAMI Accorder les autorisations UAMI sur le cluster Kusto cible
Connecteurs de code source (GitHub, Azure DevOps) UAMI (pour l’identité managée Azure DevOps) Le connecteur Azure DevOps utilise UAMI ; GitHub utilise OAuth
Connecteurs MCP Varie Vous fournissez l’URL et les informations d’identification du point de terminaison ; affecter éventuellement une identité managée pour les appels Azure en aval
Infrastructure interne UAMI Utilisé automatiquement pour les opérations internes de l’agent
Coffre-fort de clés UAMI (préféré) ou affecté par le système Revient à l’identité attribuée par le système si aucune UAMI n’est spécifiée

Comment les connecteurs utilisent l’identité

Différents types de connecteurs utilisent l’identité différemment. La distinction clé est de savoir si le connecteur doit passer par Azure Resource Manager (ARM) pour atteindre le service externe.

Connecteurs de communication (Outlook, Teams)

Lorsque vous configurez un connecteur de communication, deux choses se produisent :

  1. Vous vous connectez avec votre compte via OAuth, ce qui donne au connecteur vos informations d’identification utilisateur.
  2. Vous sélectionnez une UAMI dans la liste déroulante d’identités, que le connecteur utilise pour s’authentifier auprès de la ressource du connecteur.

Le connecteur stocke votre jeton OAuth en toute sécurité dans une ressource de connecteur. La ressource de connecteur agit comme un pont sécurisé. La ressource contient vos informations d’identification afin que l’agent n’ait pas besoin d’un accès direct à eux. Il utilise l’UAMI pour répartir l’authentification lorsque l’agent envoie un e-mail ou publie un message Teams en votre nom.

Connecteurs de données (Azure Data Explorer / Kusto)

Pour les connecteurs Kusto, l’agent utilise directement l’UAMI pour s’authentifier auprès de votre cluster Azure Data Explorer. Aucune connexion OAuth n’est nécessaire. Accordez à l’UAMI les autorisations requises, telles que le rôle Visionneuse sur le cluster Kusto.

Connecteurs de code source (GitHub, Azure DevOps)

Les connecteurs de code source utilisent différentes méthodes d’authentification en fonction de la plateforme.

  • Azure DevOps : Utilise l’UAMI pour l’authentification d’identité managée. Sélectionnez l’UAMI dans la liste déroulante des identités et accordez-lui l’accès à votre organisation Azure DevOps.
  • Github: Utilise l’authentification OAuth. Connectez-vous à l’aide de votre compte GitHub. Aucune identité managée n’est nécessaire pour la connexion GitHub elle-même.

Connecteurs MCP personnalisés

Les connecteurs MCP utilisent l’authentification basée sur le point de terminaison. Fournissez l’URL du serveur MCP, ainsi que les informations d’identification, telles qu’une clé API, un jeton du porteur ou OAuth. Vous pouvez éventuellement affecter une identité managée pour le serveur MCP à utiliser lors d’appels d’API Azure en aval.

Trouver l’UAMI de votre agent

Vous pouvez localiser l’identité managée assignée par l’utilisateur de votre agent à partir du portail de l’agent, du portail Azure ou d'Azure CLI.

À partir du portail de l’agent :

  1. Accédez aux paramètres>Azure.
  2. Le nom de l’identité apparaît dans le champ Identité managée .
  3. Sélectionnez Accéder à l’identité pour l’ouvrir dans le portail Azure.

À partir du portail Azure :

  1. Accédez au groupe de ressources de votre agent.
  2. Recherchez la ressource d’identité id-* gérée.
  3. Copiez l’ID d’objet (principal). Utilisez cette valeur pour les attributions de rôles RBAC.

À partir d’Azure CLI :

# List user-assigned identities on the agent resource
az resource show \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <AGENT_NAME> \
  --resource-type Microsoft.App/containerApps \
  --query identity.userAssignedIdentities

Étape suivante

Configurer les autorisations de l’agent

Contenu connexe

  • Last updated on