Identidades administradas en Microsoft Detector

Microsoft Detección usa identidades administradas asignadas por el usuario (UAMIs) para autenticarse en recursos de Azure en su nombre. En lugar de administrar secretos o cadenas de conexión, cree una identidad administrada, concédale los roles de Azure necesarios y proporcione su identificador de recurso al crear recursos de detección. A continuación, la plataforma de detección usa esa identidad para acceder a las cuentas de almacenamiento, los registros de contenedor, los servicios de IA y los recursos del grupo de recursos administrados (MRG).

Por qué utilizar identidades administradas asignadas por el usuario

La detección requiere identidades administradas asignadas por el usuario (no asignadas por el sistema) por los siguientes motivos:

Motivo Explanation
Propiedad del cliente Puede crear, administrar y controlar el ciclo de vida de la identidad en su propia suscripción.
Compartido entre varios recursos Puede reutilizar una única UAMI en un área de trabajo, superequipos y operaciones de almacenamiento, lo que reduce la sobrecarga de administración.
Asignaciones de roles aprovisionadas electrónicamente Asigne roles antes de la creación de recursos para que Discovery tenga los permisos que necesita desde el principio.
Vinculación inmutable La identidad del área de trabajo y la identidad del clúster de superequipos están enlazadas en tiempo de creación y no se pueden cambiar más adelante, lo que garantiza una posición de seguridad coherente. Puede actualizar las identidades del kubelet y de la carga de trabajo del superordenador tras su creación.

Importante

La identidad del área de trabajo y la identidad del clúster de superequipos son inmutables después de la creación. No se pueden cambiar una vez aprovisionados. Puede actualizar las identidades del kubelet y de la carga de trabajo del superordenador. Planee la estrategia de identidad antes de crear recursos.

Cómo Discovery utiliza tu identidad

Cuando se crea un área de trabajo o un superordenador, el plano de control de Discovery:

  • Lee su UAMI: valida que la identidad existe y que el servicio puede operar con ella.
  • Se asigna a sí mismo el rol de Operador de identidad administrada: La entidad del servicio de descubrimiento obtiene el rol de Operador de identidad administrada en su UAMI para poder utilizar la identidad en operaciones con recursos administrados.
  • Utiliza la UAMI en tiempo de ejecución: Las herramientas que se ejecutan en el superordenador utilizan la identidad para descargar imágenes de contenedores y acceder al almacenamiento de blobs. Los agentes lo usan para interactuar con Azure OpenAI y el almacenamiento.

Ranuras de identidad por tipo de recurso

Los distintos recursos de detección usan identidades administradas de diferentes maneras.

Workspace

Un área de trabajo requiere una única UAMI proporcionada a través de la propiedad workspaceIdentity. Discovery utiliza su UAMI para:

  • Identificar su espacio de trabajo: La UAMI es la entidad de seguridad que vincula el espacio de trabajo a los recursos de su suscripción.
  • Leer y escribir datos: las cuentas de Azure Blob Storage leen y escriben datos mediante contenedores de almacenamiento.
  • Descargar imágenes de contenedor: Las imágenes de contenedor se descargan de Azure Container Registry cuando se ejecutan herramientas en una supercomputadora.

Discovery configura y administra el MRG (Azure Cosmos DB, servicios de IA, índices de búsqueda y Azure OpenAI) utilizando sus propias entidades de servicio, no tu UAMI. Tu UAMI no necesita roles en el MRG.

Superequipos

Un superordenador utiliza tres ranuras de identidad, que pueden hacer referencia a la misma UAMI para mayor simplicidad o a UAMI distintas para aplicar el principio de privilegios mínimos.

Ranura propósito
Identidad del clúster Usado por el plano de control de AKS para administrar recursos de nivel de clúster, como redes y equilibradores de carga.
Identidad de kubelet Se usa a nivel de nodo para extraer imágenes de contenedor de Container Registry y acceder a los recursos de Azure.
Identidad de la carga de trabajo Se utilizan como credenciales federadas por los pods que ejecutan herramientas y agentes en el superordenador.

Estantería

Un Bookshelf hace referencia a su UAMI a través de su propiedad workloadIdentities. Discovery utiliza sus propias entidades de servicio para aprovisionar y administrar el MRG de estantería (AI Search, SQL, servicios de IA). El servicio también crea una identidad administrada por el sistema dentro de Bookshelf MRG para la autenticación interna entre recursos.

Asignaciones de roles necesarias

Debe asignar los siguientes roles integrados a la UAMI antes de crear los recursos de Discovery. Asigne estos roles en el ámbito del grupo de recursos .

Función Identificador de definición de roles propósito
Colaborador de Microsoft Discovery Platform (versión preliminar) 01288891-85ee-45a7-b367-9db3b752fc65 Administrar recursos de detección, como áreas de trabajo, proyectos, agentes y herramientas.
Colaborador de datos de Storage Blob ba92f5b4-2d11-453d-a403-e96b0029c9fe Lea y escriba blobs en cuentas de almacenamiento de Azure.
AcrPull 7f951dda-4ed3-4680-a7ca-43fe172d538d Extraiga imágenes de contenedor del Registro de Contenedores.

Para ver otros roles necesarios en escenarios especializados, consulte Configuración de identidades administradas.

Flujo de identidad de extremo a extremo a través de los recursos de Discovery

Al implementar un stack de Discovery completo, la plataforma crea tres MRG (workspace, bookshelf y supercomputer). Cada MRG contiene Azure recursos que administra el servicio.

Lo que el servicio administra automáticamente

Cuando creas un espacio de trabajo, una estantería o un superordenador, Discovery realiza automáticamente lo siguiente:

  • Crea asignaciones de roles en el MRG para que el servicio pueda aprovisionar y operar los recursos del MRG. Los recursos incluyen Microsoft Foundry, Azure Cosmos DB, Búsqueda de Azure AI, Storage, Azure Key Vault y Azure Kubernetes Service (AKS).
  • Asigna la identidad administrada Operador a tu UAMI para que el servicio pueda utilizarla en las implementaciones del MRG.
  • Crea una identidad administrada por el sistema dentro de cada espacio de trabajo y MRG de bookshelf para la autenticación interna entre recursos (Azure Container Apps, Foundry, SQL).

No es necesario crear ni administrar ninguna de estas identidades ni asignaciones de roles. Están totalmente gestionados por el servicio durante todo su ciclo de vida.

Lo que eres responsable de

Usted es responsable de las siguientes tareas:

  • Cree su UAMI: asigne los tres roles principales (Colaborador de la plataforma de detección, Colaborador de datos de Storage Blob y AcrPull) antes de crear recursos de detección.
  • Proporcione el identificador de recurso UAMI: escriba el identificador al crear un área de trabajo o un superequipos.

Su UAMI en tiempo de ejecución

Su UAMI es la identidad que usan los agentes y las herramientas en tiempo de ejecución.

Operación Recurso de Azure al que se accedió Rol obligatorio
Lectura y escritura de datos en contenedores de almacenamiento Almacenamiento de Blobs de Azure Colaborador de datos de Storage Blob
Extraer imágenes del contenedor de la herramienta Container Registry AcrPull
Administración de recursos de detección Proveedor de recursos de detección Colaborador de Microsoft Discovery Platform (versión preliminar)
Operar redes de clúster AKS subredes de Azure Virtual Network (VNet) Colaborador de red (identidad de clúster de superequipos)

Para el superordenador, su UAMI se usa en tres ranuras:

  • Identidad de clúster: el plano de control de AKS lo usa para administrar equilibradores de carga y redes.
  • Identidad de Kubelet: el agente de nivel de nodo lo usa para extraer imágenes de Container Registry y acceder a los recursos de Azure.
  • Identidad de carga de trabajo: los pods usan credenciales federadas para ejecutar herramientas y agentes.

Para obtener instrucciones sobre cómo elegir entre una única UAMI compartida y identidades independientes por función, consulte Recomendaciones de procedimientos recomendados de identidad administrada.

Configuración avanzada: asignaciones de roles granulares por identidad

En la sección asignaciones de roles necesarias se describe el enfoque más sencillo en el que una única UAMI compartida recibe los tres roles principales en el ámbito del grupo de recursos. En entornos de producción que requieren un control de seguridad más estricto, asigne UAMIs independientes con asignaciones de roles con privilegios mínimos en el ámbito de los recursos específicos a los que accede cada identidad.

Importante

La identidad de la carga de trabajo es accesible para los agentes mediante la ejecución de herramientas. Los agentes controlados por modelos de lenguaje grande (LLM) invocan herramientas que usan esta identidad en tiempo de ejecución, por lo que es fundamental minimizar los permisos de la identidad de carga de trabajo. Asigne solo los permisos estrictamente necesarios para las operaciones de herramientas. Los permisos excesivos para la identidad de carga de trabajo suponen un riesgo si un agente utiliza esa identidad fuera del ámbito previsto.

Asignaciones de roles por identidad

En la tabla siguiente se muestra la asignación de roles granular recomendada para cada identidad cuando se usan UAMIs independientes.

Identity Función Ámbito propósito
Identidad del área de trabajo Colaborador de Microsoft Discovery Platform (versión preliminar) Grupo de recursos Administrar recursos de área de trabajo, como proyectos, implementaciones de modelos de chat y contenedores de almacenamiento.
Identidad del área de trabajo Colaborador de datos de Storage Blob Cuenta de almacenamiento Leer y escribir datos del área de trabajo, artefactos del modelo de chat y recursos del proyecto en la cuenta de almacenamiento subyacente.
Identidad del clúster Colaborador de red administrado por la plataforma Grupo de recursos del nodo/red virtual Administrar recursos de red, equilibradores de carga y grupos de recursos de nodo de nivel de clúster.
Identidad del clúster Operador de identidad administrada Grupo de recursos de nodos Operar con identidades administradas para cargas de trabajo de clúster.
Identidad de kubelet AcrPull Grupo de recursos (incluye Container Registry) Recupera imágenes de contenedor para la ejecución de herramientas desde cualquier registro de contenedores aprovisionado en el grupo de recursos.
Identidad de kubelet Colaborador de datos de Storage Blob Cuenta de almacenamiento Lee los artefactos y las entradas de la carga de trabajo desde la cuenta de almacenamiento subyacente durante el inicio del pod.
Identidad de la carga de trabajo Colaborador de datos de Storage Blob Cuenta de almacenamiento Acceso a datos durante la ejecución de herramientas mediante cargas de trabajo de agente (identidad federada).

¿Por qué las identidades independientes mejoran la seguridad?

Cuando se utiliza una única UAMI compartida, la identidad de la carga de trabajo (que los agentes utilizan durante la ejecución de las herramientas) hereda todos los roles, incluidos Discovery Platform Contributor y AcrPull. Esto otorga a los agentes impulsados por LLM un acceso más amplio del que necesitan.

Al separar las identidades:

  • La identidad de la carga de trabajo solo recibe el rol Colaborador de datos de Storage Blob a nivel de la cuenta de almacenamiento, lo que limita el acceso de los agentes a través de las herramientas.
  • La identidad del clúster recibe roles de red y de operador que nunca se exponen a las cargas de trabajo de los agentes.
  • La identidad de Kubelet administra la descarga de imágenes y el acceso a los datos de inicio de los pods, de forma aislada de la ejecución de las herramientas del agente.

Esta separación garantiza que incluso si un agente intenta usar su identidad para las operaciones más allá del acceso a datos, se produce un error en la solicitud debido a permisos insuficientes.

Cuándo usar asignaciones pormenorizadas

Utilice identidades separadas con roles de ámbito limitado cuando:

  • Su organización requiere el control de acceso con privilegios mínimos.
  • Ejecutas herramientas que procesan datos confidenciales y deseas limitar el alcance de un posible incidente.
  • Los requisitos de cumplimiento exigen la separación de identidades de plano de control y plano de datos.
  • Deseas auditar el acceso a los datos del agente de forma independiente de las operaciones de infraestructura.

Para obtener instrucciones sobre cómo elegir entre identidades compartidas y independientes, consulte Recomendaciones de procedimientos recomendados de identidad administrada.

Limitaciones

  • La UAMI debe estar en la misma región que el recurso de Discovery que la utiliza.
  • La identidad del área de trabajo y la identidad del clúster de superequipos no se pueden cambiar después de la creación de recursos. Debe eliminar y volver a crear el recurso. Puedes actualizar las identidades de Kubelet y de las cargas de trabajo del superordenador a través de PATCH.
  • La propagación de la asignación de roles puede tardar hasta 10 minutos. Crear asignaciones de rol antes de crear recursos de Discovery.
  • La detección requiere el rol Managed Identity Operator en tu UAMI. Si se produce un error en esta asignación de roles durante la creación de recursos (por ejemplo, debido a restricciones de Azure Policy), se produce un error en el aprovisionamiento del área de trabajo.

Contenido relacionado

  • Última actualización el