Conexión de un servicio de búsqueda a otros recursos de Azure mediante una identidad administrada
Puede configurar un servicio de Azure Cognitive Search para conectarse a otros recursos de Azure mediante una identidad administrada asignada por el sistema o por el usuario y una asignación de roles de Azure. Las identidades administradas y las asignaciones de roles eliminan la necesidad de pasar secretos y credenciales en una cadena de conexión o el código.
Requisitos previos
Un servicio de búsqueda en el nivel de servicio Básico o superior.
Un recurso de Azure que acepta solicitudes entrantes de un inicio de sesión en Azure AD con una asignación de roles válida.
Escenarios admitidos
Cognitive Search puede usar una identidad administrada asignada por el sistema o asignada por el usuario en conexiones salientes a recursos de Azure. Se indica una identidad administrada del sistema cuando una cadena de conexión es el identificador de recurso único de un servicio o aplicación compatible con Azure AD. Una identidad administrada asignada por el usuario se especifica mediante una propiedad "identity".
Un servicio de búsqueda usa Azure Storage como origen de datos de indizador y como receptor de datos para sesiones de depuración, almacenamiento en caché de enriquecimiento y almacén de conocimiento. Para las características de búsqueda que se reescribieron en el almacenamiento, la identidad administrada necesita una asignación de roles de colaborador, tal como se describe en la sección "Asignar un rol".
| Escenario | Identidad administrada por el sistema | Identidad administrada asignada por el usuario (versión preliminar) |
|---|---|---|
| Conexiones del indexador a orígenes de datos de Azure compatibles1 | Sí | Sí |
| Azure Key Vault para claves administradas por el cliente | Sí | Sí |
| Sesiones de depuración (hospedadas en Azure Storage)1 | Sí | No |
| Caché de enriquecimiento (hospedada en Azure Storage)12 | Sí | Sí |
| Almacén de conocimiento (hospedado en Azure Storage)1 | Sí | Sí |
| Aptitudes personalizadas (hospedadas en Azure Functions o equivalente) | Sí | Sí |
1 Para la conectividad entre la búsqueda y el almacenamiento, la configuración de seguridad de red impone restricciones en el tipo de identidad administrada que puede usar. Solo se puede usar una identidad administrada del sistema para una conexión de la misma región al almacenamiento a través de la regla de instancia de recurso o excepción de servicio de confianza. Ver Acceso a una cuenta de almacenamiento protegida por red para obtener más información.
2 Un método para especificar una caché de enriquecimiento está en el Asistente para importar datos. Actualmente, el asistente no acepta una cadena de conexión de identidad administrada para la caché de enriquecimiento. Sin embargo, una vez completado el asistente, puede actualizar la cadena de conexión en la definición JSON del indizador para especificar una identidad administrada asignada por el sistema o por el usuario y, a continuación, volver a ejecutar el indizador.
Creación de una identidad administrada por el sistema
Cuando se habilita una identidad administrada asignada por el sistema, Azure crea una identidad para el servicio de búsqueda que se puede usar para autenticarse en otros servicios de Azure en el mismo inquilino y la misma suscripción. Después, puede usar esta identidad en las asignaciones de control de acceso basado en rol de Azure (RBAC de Azure) que permiten el acceso a los datos durante la indexación.
Una identidad administrada asignada por el sistema es única para el servicio de búsqueda y está enlazada al servicio durante su vigencia.
Inicie sesión en Azure Portal y encuentre el servicio de búsqueda.
En Configuración, seleccione Identidad.
En la pestaña Asignado por el sistema, en Estado, seleccione Activado.
Seleccione Guardar.
Después de guardar, verá que se ha asignado un identificador de objeto al servicio de búsqueda.
Cree una identidad administrada asignada por el usuario (UAMI) (versión preliminar)
Una identidad administrada asignada por el usuario es un recurso en Azure. Resulta útil si necesita una mayor granularidad en las asignaciones de roles, ya que puede crear identidades independientes para diferentes aplicaciones y escenarios.
Importante
Esta característica se encuentra en versión preliminar pública en los Términos de uso complementarios. Las identidades administradas asignadas por el usuario no se admiten actualmente para las conexiones a una cuenta de almacenamiento protegida por red. La solicitud de búsqueda actualmente requiere una dirección IP pública.
Seleccione + Crear un recurso.
En la barra de búsqueda "Servicios de búsqueda y Marketplace", busque "Identidad administrada asignada por el usuario" y, después, seleccione Crear.
Seleccione la suscripción, el grupo de recursos y la región. Asigne un nombre descriptivo a la identidad.
Seleccione Crear y espere a que el recurso termine de implementarse.
En los siguientes pasos, asignará la identidad administrada por el usuario asignado al servicio de búsqueda.
En la página del servicio de búsqueda, en Configuración, seleccione Identidad.
En la pestaña Usuario asignado, seleccione Agregar.
Elija la suscripción y, a continuación, seleccione el recurso administrado asignado por el usuario que creó en el paso anterior.
Permiso de acceso al firewall
Si el recurso de Azure está detrás de un firewall, asegúrese de que hay una regla de entrada que admite solicitudes del servicio de búsqueda.
Para las conexiones de la misma región a Azure Blob Storage o Azure Data Lake Storage Gen2, use una identidad administrada de sistema y la excepción de servicio de confianza. Opcionalmente, puede configurar una regla de instancia de recurso para admitir solicitudes.
Para todos los demás recursos y conexiones, configure una regla de firewall de IP que admita solicitudes de búsqueda. Consulte Acceso del indizador a orígenes de datos mediante las características de seguridad de red de Azure para obtener información.
Asignar un rol
Una identidad administrada debe emparejarse con un rol de Azure que determine los permisos en el recurso de Azure.
Se necesitan permisos de lector de datos para las conexiones de datos del indexador y para acceder a una clave administrada por el cliente en Azure Key Vault.
Se necesitan permisos de colaborador (escritura) para las características de enriquecimiento con IA que usan Azure Storage para hospedar datos de sesión de depuración, almacenamiento en caché enriquecido y almacenamiento de contenido a largo plazo en un almacén de conocimiento.
A continuación, se incluyen los pasos para Azure Storage. Si el recurso es Cosmos DB o Azure SQL, los pasos son similares.
Inicie sesión en Azure Portal y busque el recurso de Azure, al que debe tener acceso el servicio de búsqueda.
En Azure Storage, seleccione Control de acceso (IAM) en el panel de navegación izquierdo.
Seleccione Agregar asignación de roles.
En la página Rol, elija un rol:
Role Uso Lector y acceso a los datos Concede permisos de lectura para el acceso del indexador al contenido de Azure Table Storage y Azure File Storage. Lector de datos de blobs de almacenamiento Concede permisos de lectura para el acceso del indexador al contenido de Blob Storage y Azure Data Lake Storage Gen2. Colaborador de datos de blobs de almacenamiento Concede los permisos de escritura necesarios para las sesiones de depuración, las proyecciones de objetos del almacén de conocimiento y la caché de enriquecimiento. Colaborador de datos de tabla de Storage Concede los permisos de escritura necesarios para las proyecciones de tablas del almacén de conocimiento. En la página Miembros, seleccione Identidad administrada.
Seleccione los miembros. En la página Seleccionar identidad administrada, elija la suscripción, filtre por tipo de servicio y, a continuación, seleccione el servicio. Solo se podrán seleccionar los servicios que tengan una identidad administrada.
Seleccione Revisar y asignar.
Ejemplos de cadena de conexión
Una vez definida una identidad administrada para el servicio de búsqueda y dada una asignación de roles, las conexiones salientes se pueden modificar para usar el identificador de recurso único del otro recurso de Azure. A continuación, se incluyen algunos ejemplos de cadenas de conexión para varios escenarios.
Origen de datos de blob (sistema):
Un origen de datos del indexador incluye una propiedad "credentials" que determina cómo se realiza la conexión con el origen de datos. En el ejemplo siguiente se muestra una cadena de conexión que especifica el identificador de recurso único de una cuenta de almacenamiento. Azure AD autenticará la solicitud mediante la identidad administrada del sistema del servicio de búsqueda. Observe que la cadena de conexión no incluye un contenedor. En la definición de un origen de datos, se especifica un nombre de contenedor en la propiedad "container" (no se muestra), no en la cadena de conexión.
"credentials": {
"connectionString": "ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/{storage-account-name};"
}
Origen de datos de blob (usuario):
También se puede realizar una solicitud de búsqueda para Azure Storage en una identidad administrada asignada por el usuario, actualmente en versión preliminar. La identidad de usuario del servicio de búsqueda se especifica en la propiedad "identity". Puede usar el portal o la versión preliminar de la API REST 2021-04-30-Preview para establecer la identidad.
"credentials": {
"connectionString": "ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/{storage-account-name};"
},
. . .
"identity": {
"@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
"userAssignedIdentity": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{user-assigned-managed-identity-name}"
}
Una definición de almacén de conocimiento incluye una cadena de conexión a Azure Storage. En Azure Storage, un almacén de conocimiento creará proyecciones como blobs y tablas. La cadena de conexión es el identificador de recurso único de la cuenta de almacenamiento. Observe que la cadena no incluye contenedores ni tablas en la ruta de acceso. Estos elementos se definen en la definición de proyección insertada, no en la cadena de conexión.
"knowledgeStore": {
"storageConnectionString": "ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/storage-account-name};",
Un indexador crea, usa y recuerda el contenedor usado para los enriquecimientos en caché. No es necesario incluir el contenedor en la cadena de conexión de la caché. Puede encontrar el identificador de objeto en la página Identidad del servicio de búsqueda en el portal.
"cache": {
"id": "{object-id}",
"enableReprocessing": true,
"storageConnectionString": "ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/storage-account-name};"
},
Una sesión de depuración se ejecuta en el portal y toma una cadena de conexión al iniciar la sesión. Puede pegar una cadena de conexión es similar a la del ejemplo siguiente.
"ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/{storage-account-name}/{container-name};",
Una aptitud personalizada tiene como destino el punto de conexión de una función de Azure o una aplicación que hospeda código personalizado. El punto de conexión se especifica en la definición de aptitud personalizada. La presencia de "authResourceId" indica al servicio de búsqueda que se conecte mediante una identidad administrada, pasando el identificador de aplicación de la función o la aplicación de destino en la propiedad.
{
"@odata.type": "#Microsoft.Skills.Custom.WebApiSkill",
"description": "A custom skill that can identify positions of different phrases in the source text",
"uri": "https://contoso.count-things.com",
"authResourceId": "<Azure-AD-registered-application-ID>",
"batchSize": 4,
"context": "/document",
"inputs": [ ... ],
"outputs": [ ...]
}