Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Al crear un agente, Azure aprovisiona automáticamente los recursos de identidad. En este artículo se explica lo que se crea, por qué existen dos identidades y cómo los conectores los usan.
Para obtener información sobre cómo el agente adquiere permisos en los recursos de Azure (roles de RBAC, niveles de permisos, flujo con derechos delegados), consulte Permisos del agente.
Qué se crea
Se crean dos identidades administradas junto con el agente.
| Identidad | ¿Qué es? | Qué haces con él |
|---|---|---|
| Identidad administrada asignada por el usuario (UAMI) | Un recurso de identidad independiente en su grupo de recursos | Asigne roles de RBAC, selecciónelo al configurar conectores. Esta es la identidad que gestionas. |
| Identidad administrada asignada por el sistema | Una identidad interna usada por la infraestructura del agente | Nada: esta identidad se administra automáticamente y se usa solo para operaciones internas. |
UAMI es la identidad con la cual trabaja. Aparece en tu grupo de recursos, le asignas roles de RBAC y lo seleccionas al configurar conectores.
Sugerencia
Cuando vea una lista desplegable de identidades administradas en el portal (para conectores, repositorios u otras integraciones), seleccione la UAMI del agente. Es la identidad que se corresponde con las asignaciones de roles de RBAC.
Dónde se utiliza la UAMI del agente
La UAMI de su agente es la identidad principal para la mayoría de las operaciones.
| Operación | Identidad | Notas |
|---|---|---|
| Operaciones de recursos de Azure (Azure Resource Manager, CLI, diagnósticos) | UAMI | Los roles de RBAC que usted asigna determinan a qué puede acceder el agente. |
| Conectores de comunicación (Outlook, Teams) | UAMI + sus credenciales de OAuth | Inicia sesión mediante OAuth; UAMI gestiona la autenticación al recurso del conector |
| Conectores de datos (Azure Data Explorer) | UAMI | Conceda permisos a la UAMI en el clúster de Kusto de destino |
| Conectores de código fuente (GitHub, Azure DevOps) | UAMI (para la identidad administrada de Azure DevOps) | El conector de Azure DevOps usa UAMI; GitHub usa OAuth |
| Conectores MCP | Varía | Proporcione las credenciales y la dirección URL del punto de conexión; opcionalmente, asigne una identidad administrada para las llamadas de Azure de nivel inferior. |
| Infraestructura interna | UAMI | Se usa automáticamente para las operaciones internas del agente |
| Almacén de claves | UAMI: (preferido) o asignado por el sistema | Vuelve a asignarse al sistema si no se especifica ninguna UAMI |
Cómo usan los conectores la identidad
Los distintos tipos de conector usan la identidad de forma diferente. La distinción clave es si el conector debe pasar por Azure Resource Manager (ARM) para llegar al servicio externo.
Conectores de comunicación (Outlook, Teams)
Al configurar un conector de comunicación, suceden dos cosas:
- Inicie sesión con su cuenta a través de OAuth, lo que proporciona al conector sus credenciales de usuario.
- Seleccione una UAMI en la lista desplegable de identidades, que el conector usa para autenticarse en el recurso del conector.
El conector almacena el token de OAuth de forma segura en un recurso de conector. El recurso del conector actúa como un puente seguro. El recurso contiene las credenciales para que el agente no necesite acceso directo a ellas. Usa UAMI para intermediar la autenticación cuando el agente envía un correo electrónico o publica un mensaje de Teams en su nombre.
Conectores de datos (Azure Data Explorer/ Kusto)
En el caso de los conectores de Kusto, el agente usa UAMI directamente para autenticarse en el clúster de Azure Data Explorer. No se necesita ningún inicio de sesión de OAuth. Conceda a la UAMI los permisos necesarios, como el rol Visor, en el clúster de Kusto.
Conectores de código fuente (GitHub, Azure DevOps)
Los conectores de código fuente usan diferentes métodos de autenticación en función de la plataforma.
- Azure DevOps: Usa UAMI para la autenticación de identidad administrada. Seleccione la UAMI en la lista desplegable de identidades y concédale acceso a la organización de Azure DevOps.
- GitHub: Usa la autenticación de OAuth. Inicie sesión con su cuenta de GitHub. No se necesita ninguna identidad administrada para la propia conexión de GitHub.
Conectores MCP personalizados
Los conectores MCP usan la autenticación basada en puntos de conexión. Proporcione la dirección URL del servidor MCP junto con las credenciales, como una clave de API, un token de portador o OAuth. Opcionalmente, puede asignar una identidad administrada para que el servidor MCP la utilice al realizar llamadas a la API de Azure.
Encuentra la UAMI de tu agente
Puede buscar la identidad administrada asignada por el usuario del agente desde el portal del agente, el Azure Portal o la CLI de Azure.
Desde el portal del agente:
- Vaya a Configuración>de Azure.
- El nombre de la identidad aparece en el campo Identidad administrada .
- Seleccione Ir a Identidad para abrirlo en Azure Portal.
Desde Azure Portal:
- Vaya al grupo de recursos de su agente.
- Busque el recurso de identidad administrada
id-*. - Copie el identificador del objeto (principal). Use este valor para las asignaciones de roles de RBAC.
Desde la CLI de Azure:
# 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
Paso siguiente
Contenido relacionado
- Permisos del agente: aprenda a configurar los roles de RBAC y los niveles de permisos para el agente.
- Conectores: configure los tipos de conector y obtenga información sobre cómo amplían las funcionalidades del agente.
- Roles y permisos de usuario: controle quién puede ver, interactuar y administrar el agente.