Compartir a través de

Configuración de la autenticación entre Azure Machine Learning y otros servicios

  • Artículo

SE APLICA A:Extensión ML de la CLI de Azure v2 (actual)SDK de Python azure-ai-ml v2 (actual)

Azure Machine Learning se compone de varios servicios de Azure. Hay varias maneras mediante las que la autenticación puede producirse entre Azure Machine Learning y los servicios en los que se basa.

  • El área de trabajo de Azure Machine Learning usa una identidad administrada para comunicarse con otros servicios. De forma predeterminada, es una identidad administrada asignada por el sistema. También puede usar una identidad administrada asignada por el usuario en su lugar.
  • Azure Machine Learning usa Azure Container Registry (ACR) para almacenar imágenes de Docker que se usan para entrenar e implementar modelos. Si permite que Azure Machine Learning cree automáticamente ACR, se habilitará la cuenta de administrador.
  • El clúster de proceso de Azure Machine Learning usa una identidad administrada para recuperar información de conexión para almacenes de datos de Azure Key Vault y extraer imágenes de Docker de ACR. También puede configurar el acceso basado en identidades a almacenes de datos, que en su lugar usará la identidad administrada del clúster de proceso.
  • El acceso a los datos puede producirse a lo largo de varias rutas de acceso en función del servicio de almacenamiento de datos y de la configuración. Por ejemplo, la autenticación en el almacén de datos puede usar una clave de cuenta, un token, una entidad de seguridad, una identidad administrada o una identidad de usuario.
  • Los puntos de conexión en línea administrados pueden usar una identidad administrada para acceder a los recursos de Azure al realizar la inferencia. Para más información, consulte Acceso a los recursos de Azure desde un punto de conexión en línea.

Prerrequisitos

Antes de seguir los pasos de este artículo, asegúrese de que tiene los siguientes requisitos previos:

Tipos de identidad del área de trabajo

El área de trabajo de Azure Machine Learning usa una identidad administrada para comunicarse con otros servicios. Se admiten varios tipos de identidad para Azure Machine Learning.

Tipo de identidad administrada Creación de asignaciones de roles Fin
Asignado por el sistema (SAI) Administrada por Microsoft Ciclo de vida asociado al recurso; uso de un único recurso; fácil de empezar
Asignado por el sistema+asignado por el usuario (SAI+UAI) Administrado por usted El ciclo de vida independiente para la identidad asignada por el usuario, el uso de varios recursos, controla el acceso con privilegios mínimos. Obtener acceso a los datos de los trabajos de entrenamiento.

Una vez que se crea un área de trabajo con el tipo de identidad SAI, se puede actualizar a SAI+UAI, pero no volver de SAI+UAI a SAI. Puede asignar varias identidades asignadas por el usuario al mismo área de trabajo.

Tipos de identidad y Azure Container Registry

En esta tabla se muestra la matriz de compatibilidad al autenticarse en Azure Container Registry, según el método de autenticación y la configuración de acceso a la red pública de la instancia de Azure Container Registry.

Método de autenticación Acceso a la red pública
deshabilitado		 Azure Container Registry
acceso a la red pública habilitado
Usuario administrador ✓ ✓
Identidad administrada asignada por el sistema del área de trabajo ✓ ✓

Identidad administrada asignada por el usuario

Área de trabajo

Puede agregar una identidad administrada asignada por el usuario al crear un área de trabajo de Azure Machine Learning desde Azure Portal. Siga estos pasos al crear el área de trabajo:

  1. En la página Aspectos básicos, seleccione la cuenta de Azure Storage, Azure Container Registry y Azure Key Vault que desea usar con el área de trabajo.
  2. En la página Identidad, seleccione Identidad asignada por el usuario y, a continuación, seleccione la identidad administrada que se va a usar.

Las siguientes asignaciones de roles RBAC de Azure son necesarias en la identidad administrada asignada por el usuario para que el área de trabajo de Azure Machine Learning acceda a los datos de los recursos asociados al área de trabajo.

Recurso Permiso
Área de trabajo de Azure Machine Learning Colaborador
Azure Storage Colaborador (plano de control) + Colaborador de datos de Storage Blob (plano de datos, opcional, para habilitar la versión preliminar de datos en Estudio de Azure Machine Learning)
Azure Key Vault (al usar el modelo de permisos RBAC) Colaborador (plano de control) + administrador de Key Vault (plano de datos)
Azure Key Vault (al usar el modelo de permisos de directivas de acceso) Colaborador + cualquier permiso de directiva de acceso, además de operaciones de purga
Azure Container Registry Colaborador
Azure Application Insights Colaborador

Para la creación automatizada de asignaciones de roles en la identidad administrada asignada por el usuario, puede usar esta plantilla de ARM.

Sugerencia

En un área de trabajo con claves administradas por el cliente para el cifrado, puede pasar una identidad administrada asignada por el usuario para autenticarse desde el almacenamiento en Key Vault. Use los parámetros user-assigned-identity-for-cmk-encryption (CLI) o user_assigned_identity_for_cmk_encryption (SDK) para pasar la identidad administrada. Esta identidad administrada puede ser la misma que la identidad administrada asignada por el usuario principal del área de trabajo, o una diferente.

Para crear un área de trabajo con múltiples identidades asignadas por el usuario, use uno de los métodos siguientes:

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

az ml workspace create -f workspace_creation_with_multiple_UAIs.yml --subscription <subscription ID> --resource-group <resource group name> --name <workspace name>

Donde el contenido de workspace_creation_with_multiple_UAIs.yml es el siguiente:

location: <region name>
identity:
   type: user_assigned
   user_assigned_identities:
    '<UAI resource ID 1>': {}
    '<UAI resource ID 2>': {}
storage_account: <storage acccount resource ID>
key_vault: <key vault resource ID>
image_build_compute: <compute(virtual machine) resource ID>
primary_user_assigned_identity: <one of the UAI resource IDs in the above list>

Para actualizar las identidades asignadas a los usuarios de un área de trabajo, incluida la adición de una nueva o la eliminación de las existentes, utilice uno de los siguientes métodos:

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

az ml workspace update -f workspace_update_with_multiple_UAIs.yml --subscription <subscription ID> --resource-group <resource group name> --name <workspace name>

Donde el contenido de workspace_update_with_multiple_UAIs.yml es el siguiente:

identity:
   type: user_assigned
   user_assigned_identities:
    '<UAI resource ID 1>': {}
    '<UAI resource ID 2>': {}
primary_user_assigned_identity: <one of the UAI resource IDs in the above list>

Sugerencia

Para agregar una nueva UAI, puede especificar el nuevo id. de UAI en la sección user_assigned_identities además de las UAI existentes, es necesario pasar todos los id. de UAI existentes.
Para eliminar una o varias UAI existentes, puede colocar los id. de la UAI que deben conservarse en la sección user_assigned_identities, el resto de id. de UAI se eliminarán.

Adición de una identidad administrada asignada por el usuario a un área de trabajo además de una identidad asignada por el sistema

En algunos escenarios, es posible que tenga que usar una identidad administrada asignada por el usuario además de la identidad del área de trabajo asignada por el sistema predeterminada. Para agregar una identidad administrada asignada por el usuario, sin cambiar la identidad del área de trabajo existente, siga estos pasos:

  1. Creación de una identidad administrada asignada por el usuario. Guarde el identificador de la identidad administrada que cree.

  2. Para adjuntar la identidad administrada al área de trabajo, necesita un archivo YAML que especifique la identidad. A continuación se muestra un ejemplo del contenido del archivo YAML. Reemplace <TENANT_ID>, <RESOURCE_GROUP> y <USER_MANAGED_ID> con sus propios valores.

    identity:
    type: system_assigned,user_assigned
    tenant_id: <TENANT_ID>
    user_assigned_identities:
        '/subscriptions/<SUBSCRIPTION_ID/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<USER_MANAGED_ID>':
        {}

  3. Use el comando az ml workspace update de la CLI de Azure para actualizar las áreas de trabajo. Especifique el archivo YAML del paso anterior usando el parámetro --file. En el ejemplo siguiente se muestra el aspecto de este comando:

    az ml workspace update --resource-group <RESOURCE_GROUP> --name <WORKSPACE_NAME> --file <YAML_FILE_NAME>.yaml

Clúster de proceso

Nota

Los clústeres de proceso de Azure Machine Learning solo admiten una identidad asignada por el sistema o varias identidades asignadas por el usuario, no ambas de forma simultánea.

La identidad administrada predeterminada es la identidad administrada asignada por el sistema o la primera identidad administrada asignada por el usuario.

Durante una ejecución, hay dos aplicaciones de una identidad:

  1. El sistema usa una identidad para configurar los montajes de almacenamiento, el registro de contenedor y los almacenes de datos del usuario.

    • En este caso, el sistema usará la identidad administrada predeterminada.

  2. Se aplica una identidad para acceder a los recursos desde dentro del código para un trabajo enviado:

    • En este caso, proporcione el elemento client_id correspondiente a la identidad administrada que quiere usar para recuperar una credencial.
    • También puede obtener el id. de cliente de la identidad asignada por el usuario a través de la variable de entorno DEFAULT_IDENTITY_CLIENT_ID.

    Por ejemplo, para recuperar un token para un almacén de datos con la identidad administrada predeterminada:

    client_id = os.environ.get('DEFAULT_IDENTITY_CLIENT_ID')
credential = ManagedIdentityCredential(client_id=client_id)
token = credential.get_token('https://storage.azure.com/')

Para configurar un clúster de proceso con identidad administrada, use uno de los métodos siguientes:

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

az ml compute create -f create-cluster.yml

Donde el contenido de create-cluster.yml es el siguiente:

$schema: https://azuremlschemas.azureedge.net/latest/amlCompute.schema.json 
name: basic-example
type: amlcompute
size: STANDARD_DS3_v2
min_instances: 0
max_instances: 2
idle_time_before_scale_down: 120
identity:
  type: user_assigned
  user_assigned_identities: 
    - resource_id: "identity_resource_id"

En comparación, el ejemplo siguiente procede de un archivo YAML que crea un clúster que usa una identidad administrada asignada por el sistema:

$schema: https://azuremlschemas.azureedge.net/latest/amlCompute.schema.json 
name: basic-example
type: amlcompute
size: STANDARD_DS3_v2
min_instances: 0
max_instances: 2
idle_time_before_scale_down: 120
identity:
  type: system_assigned

Si tiene un clúster de proceso existente, puede cambiar entre la identidad administrada por el usuario y la identidad administrada por el sistema. En los ejemplos siguientes se muestra cómo cambiar la configuración:

Identidad administrada asignada por el usuario

export MSI_NAME=my-cluster-identity
export COMPUTE_NAME=mycluster-msi

does_compute_exist()
{
  if [ -z $(az ml compute show -n $COMPUTE_NAME --query name) ]; then
    echo false
  else
    echo true
  fi
}

echo "Creating MSI $MSI_NAME"
# Get the resource id of the identity
IDENTITY_ID=$(az identity show --name "$MSI_NAME" --query id -o tsv | tail -n1 | tr -d "[:cntrl:]" || true)
if [[ -z $IDENTITY_ID ]]; then
    IDENTITY_ID=$(az identity create -n "$MSI_NAME" --query id -o tsv | tail -n1 | tr -d "[:cntrl:]")
fi
echo "MSI created: $MSI_NAME"
sleep 15 # Let the previous command finish: https://github.com/Azure/azure-cli/issues/8530


echo "Checking if compute $COMPUTE_NAME already exists"
if [ "$(does_compute_exist)" == "true" ]; then
  echo "Skipping, compute: $COMPUTE_NAME exists"
else
  echo "Provisioning compute: $COMPUTE_NAME"
  az ml compute create --name "$COMPUTE_NAME" --type amlcompute --identity-type user_assigned --user-assigned-identities "$IDENTITY_ID"
fi
az ml compute update --name "$COMPUTE_NAME" --identity-type user_assigned --user-assigned-identities "$IDENTITY_ID"

Identidad administrada asignada por el sistema

export COMPUTE_NAME=mycluster-sa

does_compute_exist()
{
  if [ -z $(az ml compute show -n $COMPUTE_NAME --query name) ]; then
    echo false
  else
    echo true
  fi
}

echo "Checking if compute $COMPUTE_NAME already exists"
if [ "$(does_compute_exist)" == "true" ]; then
  echo "Skipping, compute: $COMPUTE_NAME exists"
else
  echo "Provisioning compute: $COMPUTE_NAME"
  az ml compute create --name "$COMPUTE_NAME" --type amlcompute
fi

az ml compute update --name "$COMPUTE_NAME" --identity-type system_assigned

Almacenamiento de datos

Al crear un almacén de datos que use el acceso a datos basado en identidades, la cuenta de Azure (token de Microsoft Entra) se usa para confirmar que tiene permiso para acceder al servicio de almacenamiento. En el escenario de acceso a datos basado en identidades, no se guardarán las credenciales de autenticación. Lo único que se guardará en el almacén de datos será la información de la cuenta de almacenamiento.

En cambio, los almacenes de datos que usan información de conexión de caché de autenticación basada en credenciales, como la clave de la cuenta de almacenamiento o el token de SAS, en el almacén de claves asociado al área de trabajo. Este enfoque tiene la limitación de que otros usuarios del área de trabajo con permisos suficientes puedan recuperar esas credenciales, lo que puede ser un problema de seguridad para alguna organización.

Para más información sobre cómo se autentica el acceso a los datos, consulte el artículo Administración de datos. Para información sobre cómo configurar el acceso basado en identidades a los datos, consulte Creación de almacenes de datos.

Hay dos escenarios en los que se puede aplicar el acceso a datos basado en identidades de Azure Machine Learning. Estos escenarios son una buena opción para utilizar el acceso basado en identidades cuando hay datos confidenciales de por medio y es preciso administrar el acceso a los datos de forma más pormenorizada:

  • Acceso a servicios de almacenamiento
  • Entrenamiento de modelos de Machine Learning

El acceso basado en identidades permite usar controles de acceso basado en roles (RBAC) para restringir qué identidades, como usuarios o recursos de proceso, tienen acceso a los datos.

Acceso a servicios de almacenamiento

Puede conectarse a los servicios de almacenamiento mediante el acceso a datos basado en identidad con almacenes de datos de Azure Machine Learning.

Cuando se usa el acceso a datos basado en identidades, Azure Machine Learning solicita el token de Microsoft Entra para autenticar el acceso a los datos en lugar de guardar las credenciales en el almacén de datos. Este enfoque permite administrar el acceso a los datos en el nivel de almacenamiento y preserva la confidencialidad de las credenciales.

El mismo comportamiento se aplica cuando se trabaja con datos de forma interactiva a través de una Jupyter Notebook en el equipo local o en la instancia de proceso.

Nota

Las credenciales que se almacenan con la autenticación basada en credenciales incluyen: los identificadores de la suscripción, los tokens de firma de acceso compartido (SAS), las claves de acceso de almacenamiento y la información de la entidad de servicio, como los identificadores de cliente y los identificadores de inquilino.

Para ayudar a garantizar la seguridad al conectarse al servicio de almacenamiento de Azure, en Azure Machine Learning es obligatorio tener permiso para poder acceder al almacenamiento de datos correspondiente.

Advertencia

No se admite el acceso entre inquilinos a las cuentas de almacenamiento. Si el acceso entre inquilinos es necesario para su escenario, póngase en contacto con el alias de equipo de soporte técnico de datos de Azure Machine Learning en amldatasupport@microsoft.com para obtener ayuda con una solución de código personalizada.

El acceso a datos basado en identidades solo permite conectarse a los siguientes servicios de almacenamiento.

  • Azure Blob Storage
  • Azure Data Lake Storage Gen1
  • Azure Data Lake Storage Gen2

Para poder acceder a estos servicios de almacenamiento, debe tener como mínimo acceso de Lector de datos de Storage Blob a la cuenta de almacenamiento. Solo los propietarios de la cuenta de almacenamiento pueden cambiar el nivel de acceso mediante Azure Portal.

Acceso a los datos para trabajos de entrenamiento en proceso mediante la identidad administrada

Algunos escenarios de aprendizaje automático implican trabajar con datos privados. En tales casos, es posible que los científicos de datos no tengan acceso directo a los datos como usuarios de Microsoft Entra. En este escenario, puede utilizarse la identidad administrada de un proceso para la autenticación del acceso a datos. En este escenario, solo se puede acceder a los datos desde una instancia de proceso o un clúster de proceso de aprendizaje automático que ejecuta un trabajo de entrenamiento. Con este enfoque, el administrador concede a la instancia de proceso o a la identidad administrada del clúster de proceso permisos lector de datos de Storage Blob en el almacenamiento. No es necesario conceder acceso a cada científico de datos.

Para habilitar la autenticación con la identidad administrada de proceso:

Nota:

El nombre de la identidad administrada del sistema creada para la instancia de proceso o el clúster tendrá el formato /workspace-name/computes/compute-name en Microsoft Entra ID.

Una vez habilitada la autenticación basada en identidades, la identidad administrada de proceso se usa de manera predeterminada al acceder a los datos de los trabajos de entrenamiento. Opcionalmente, puede autenticarse con la identidad de usuario mediante los pasos que se describen en la sección siguiente.

Para obtener información sobre el uso de RBAC de Azure para el almacenamiento, consulte Controles de acceso basados en roles.

Acceso a datos para trabajos de entrenamiento en clústeres de proceso mediante la identidad de usuario

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

Al entrenar en clústeres de proceso de Azure Machine Learning, puede autenticarse en el almacenamiento con el token de Microsoft Entra de usuario.

Este modo de autenticación le permite:

  • Configure permisos específicos, donde los distintos usuarios del área de trabajo pueden tener acceso a diferentes cuentas de almacenamiento o carpetas dentro de las cuentas de almacenamiento.
  • Permitir que los científicos de datos vuelvan a usar los permisos existentes en los sistemas de almacenamiento.
  • Audite el acceso al almacenamiento porque los registros de almacenamiento muestran qué identidades se usaron para acceder a los datos.

Importante

Esta funcionalidad tiene las siguientes limitaciones

  • La característica se admite para los experimentos enviados a través de la CLI de Azure Machine Learning y el SDK de Python V2, pero no a través de ML Studio.
  • La identidad del usuario y la identidad administrada de proceso no se pueden usar para la autenticación en el mismo trabajo.
  • Para los trabajos de canalización, se recomienda establecer la identidad de usuario en el nivel de paso individual que se ejecutará en un proceso, en lugar de en el nivel de canalización raíz. ( Aunque se admite la configuración de identidad tanto en la canalización raíz como en los niveles de paso, la configuración del nivel de paso tiene prioridad si se establecen ambas. Sin embargo, para las canalizaciones que contienen componentes de canalización, la identidad debe establecerse en los pasos individuales que se ejecutarán. La identidad establecida en el nivel de componente de canalización raíz o canalización no funcionará. Por lo tanto, se recomienda establecer la identidad en el nivel de paso individual para simplificar).

En los pasos siguientes se describe cómo configurar el acceso a datos con la identidad de usuario para los trabajos de entrenamiento en clústeres de proceso desde la CLI.

  1. Conceda a la identidad de usuario acceso a los recursos de almacenamiento. Por ejemplo, conceda a StorageBlobReader acceso a la cuenta de almacenamiento específica que quiere usar o conceda permiso basado en ACL a carpetas o archivos específicos en el almacenamiento de Azure Data Lake Gen 2.

  2. Cree un almacén de datos Azure Machine Learning sin credenciales almacenadas en caché para la cuenta de almacenamiento. Si un almacén de datos tiene credenciales almacenadas en caché, como la clave de la cuenta de almacenamiento, se usan esas credenciales en lugar de la identidad del usuario.

  3. Envíe un trabajo de entrenamiento con la identidad de propiedad establecida en tipo: user_identity, como se muestra en la especificación de trabajo siguiente. Durante el entrenamiento, la autenticación en el almacenamiento se produce a través de la identidad del usuario que envía el trabajo.

    Nota:

    Si la propiedad identity se deja sin especificar y el almacén de datos no tiene credenciales almacenadas en caché, la identidad administrada de proceso se convierte en la opción de reserva.

    command: |
echo "--census-csv: ${{inputs.census_csv}}"
python hello-census.py --census-csv ${{inputs.census_csv}}
code: src
inputs:
census_csv:
    type: uri_file 
    path: azureml://datastores/mydata/paths/census.csv
environment: azureml:AzureML-sklearn-1.0-ubuntu20.04-py38-cpu@latest
compute: azureml:cpu-cluster
identity:
type: user_identity

En los pasos siguientes se describe cómo configurar el acceso a datos con la identidad de usuario para los trabajos de entrenamiento en clústeres de proceso desde el SDK de Python.

  1. Conceda acceso a datos y cree un almacén de datos como se ha descrito anteriormente para la CLI.

  2. Envíe un trabajo de entrenamiento con el parámetro de identidad establecido en azure.ai.ml.UserIdentityConfiguration. Esta configuración de parámetro permite que el trabajo acceda a los datos en nombre del usuario que envía el trabajo.

    from azure.ai.ml import command
from azure.ai.ml.entities import Data, UriReference
from azure.ai.ml import Input
from azure.ai.ml.constants import AssetTypes
from azure.ai.ml import UserIdentityConfiguration

# Specify the data location
my_job_inputs = {
    "input_data": Input(type=AssetTypes.URI_FILE, path="<path-to-my-data>")
}

# Define the job
job = command(
    code="<my-local-code-location>", 
    command="python <my-script>.py --input_data ${{inputs.input_data}}",
    inputs=my_job_inputs,
    environment="AzureML-sklearn-0.24-ubuntu18.04-py37-cpu:9",
    compute="<my-compute-cluster-name>",
    identity= UserIdentityConfiguration() 
)
# submit the command
returned_job = ml_client.jobs.create_or_update(job)

Importante

Durante el envío del trabajo con la autenticación con la identidad de usuario habilitada, las instantáneas de código están protegidas contra alteraciones mediante la validación de suma de comprobación. Si tiene componentes de canalización existentes y piensa usarlos con la autenticación con la identidad de usuario habilitada, es posible que tenga que volver a cargarlos. De lo contrario, el trabajo puede producir un error durante la validación de suma de comprobación.

Trabajo con redes virtuales

De forma predeterminada, Azure Machine Learning no puede comunicarse con una cuenta de almacenamiento que esté detrás de un firewall o en una red virtual.

Puede configurar las cuentas de almacenamiento para permitir el acceso exclusivamente desde redes virtuales específicas. Esta configuración requiere algunos pasos adicionales para evitar que los datos se filtren fuera de la red. Este comportamiento es igual en el acceso a datos basado en credenciales. Para obtener más información, consulte Cómo evitar la filtración de datos.

Si la cuenta de almacenamiento tiene una configuración de red virtual, esto determina qué tipo de identidad y acceso a los permisos es necesario. Por ejemplo, en el caso de la vista previa de datos y el perfil de datos, la configuración de red virtual determina qué tipo de identidad se usa para autenticar el acceso a los datos.

  • En aquellos escenarios en los que solo determinadas direcciones IP y subredes pueden tener acceso al almacenamiento, Azure Machine Learning usa la MSI del área de trabajo para realizar perfiles y vistas previas de datos.

  • Si el almacenamiento es ADLS Gen 2 o Blob y tiene una configuración de red virtual, los clientes pueden usar la MSI del área de trabajo y la identidad del usuario dependiendo de la configuración del almacén de datos definida durante la creación.

  • Si la configuración de red virtual es "Permitir que los servicios de Azure de la lista de servicios de confianza accedan a esta cuenta de almacenamiento", se usa la MSI del área de trabajo.

Escenario: Azure Container Registry sin usuario administrador

Al deshabilitar el usuario administrador de ACR, Azure Machine Learning usa una identidad administrada para crear y extraer imágenes de Docker. Hay dos flujos de trabajo al configurar Azure Machine Learning para usar un ACR con el usuario administrador deshabilitado:

  • Permita que Azure Machine Learning cree la instancia de ACR y, después, deshabilite el usuario administrador.
  • Traiga un ACR existente con el usuario administrador ya deshabilitado.

Azure Machine Learning con una instancia de ACR creada automáticamente

  1. Cree una nueva área de trabajo de Azure Machine Learning.

  2. Realice una acción que requiera Azure Container Registry. Por ejemplo, el Tutorial: Entrenamiento del primer modelo.

  3. Obtenga el nombre del ACR creado por el clúster.

    SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

    az ml workspace show --name <my workspace name> \
--resource-group <my resource group> \
--subscription <my subscription id> \
--query container_registry

    Este comando devuelve un valor similar al siguiente texto: Solo desea la última parte del texto, que es el nombre de la instancia de ACR:

    /subscriptions/<subscription id>/resourceGroups/<my resource group>/providers/MicrosoftContainerReggistry/registries/<ACR instance name>

  4. Actualice la instancia de ACR para deshabilitar el usuario administrador:

    az acr update --name <ACR instance name> --admin-enabled false

Traiga su propia instancia de ACR

Si la directiva de suscripción no permite el usuario administrador de ACR, debe crear primero la instancia de ACR sin el usuario administrador y, a continuación, asociarla al área de trabajo. Cree una instancia de ACR desde la CLI de Azure sin establecer el argumento --admin-enabled, o desde Azure Portal sin habilitar el usuario administrador. A continuación, al crear el área de trabajo de Azure Machine Learning, especifique el identificador de recurso de Azure de la instancia de ACR. En el ejemplo siguiente se muestra cómo crear una nueva área de trabajo de Azure Machine Learning que use una instancia de ACR existente:

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

az ml workspace create -n <workspace name> \
-g <workspace resource group> \
-l <region> \
--container-registry /subscriptions/<subscription id>/resourceGroups/<acr resource group>/providers/Microsoft.ContainerRegistry/registries/<acr name>

Sugerencia

Para obtener el valor del parámetro --container-registry, use el comando az acr show para mostrar la información de la instancia de ACR. El campo id contiene el identificador de recurso de su instancia de ACR.

Además, si ya tiene un ACR existente con el usuario administrador deshabilitado, puede asociarlo al área de trabajo actualizándolo. El siguiente ejemplo demuestra la actualización de un área de trabajo de Azure Machine Learning para usar un ACR existente:

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

az ml workspace update --update-dependent-resources \
--name <workspace name> \
--resource-group <workspace resource group> \
--container-registry /subscriptions/<subscription id>/resourceGroups/<acr resource group>/providers/Microsoft.ContainerRegistry/registries/<acr name>

Creación de un proceso con una identidad administrada para acceder a imágenes de Docker para el entrenamiento

Para acceder a la instancia de ACR del área de trabajo, cree un clúster de proceso de Machine Learning con una identidad administrada asignada por el sistema habilitada. Puede habilitar la identidad desde Azure Portal o Studio al crear el proceso, o bien desde la CLI de Azure mediante lo siguiente. Para más información, consulte Uso de identidades administradas con clústeres de proceso.

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

az ml compute create --name cpu-cluster --type <cluster name>  --identity-type systemassigned

A una identidad administrada se le concede automáticamente el rol ACRPull en la instancia de ACR del área de trabajo para habilitar la extracción de imágenes de Docker para el entrenamiento.

Nota

Si crea el proceso antes de la creación de la instancia de ACR del área de trabajo, debe asignar el rol ACRPull manualmente.

Uso de imágenes de Docker para la inferencia

Una vez que haya configurado ACR sin el usuario administrador tal y como se ha descrito anteriormente, puede acceder a las imágenes de Docker para la inferencia sin claves de administración de Azure Kubernetes Service (AKS). Al crear la instancia de AKS o conectarla al área de trabajo, se asigna automáticamente a la entidad de servicio del clúster acceso ACRPull a la instancia de ACR del área de trabajo.

Nota

Si trae su propio clúster de AKS, el clúster debe tener habilitada la entidad de servicio en lugar de la identidad administrada.

Escenario: Uso de una instancia de Azure Container Registry privada

De forma predeterminada, Azure Machine Learning usa imágenes base de Docker que proceden de un repositorio público administrado por Microsoft. A continuación, crea el entorno de entrenamiento o inferencia basado en esas imágenes. Para obtener más información, consulte ¿Qué son los entornos de Azure Machine Learning?

Para usar una imagen base personalizada interna para su empresa, puede usar identidades administradas para acceder a su instancia de ACR privada. Hay dos posibles casos de uso:

  • Uso de la imagen base para el entrenamiento tal cual.
  • Creación de una imagen administrada de Azure Machine Learning mediante la imagen personalizada como base.

Extracción de la imagen base de Docker en el clúster de proceso de Machine Learning para el entrenamiento tal cual

Cree el clúster de proceso de Machine Learning con la identidad administrada asignada por el sistema según se ha descrito anteriormente. A continuación, determine el id. de entidad de seguridad de la identidad administrada.

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

az ml compute show --name <cluster name> -n <workspace> -g <resource group>

Opcionalmente, puede actualizar el clúster de proceso para asignar una identidad administrada asignada por el usuario:

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

az ml compute update --name <cluster name> --user-assigned-identities <my-identity-id>

Para permitir que el clúster de proceso extraiga las imágenes base, conceda el rol ACRPull de Managed Service Identity en la instancia de ACR privada.

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

az role assignment create --assignee <principal ID> \
--role acrpull \
--scope "/subscriptions/<subscription ID>/resourceGroups/<private ACR resource group>/providers/Microsoft.ContainerRegistry/registries/<private ACR name>"

Finalmente, cree un entorno y especifique la ubicación de la imagen base en el archivo YAML del entorno.

SE APLICA A: Extensión de ML de la CLI de Azure v2 (actual)

$schema: https://azuremlschemas.azureedge.net/latest/environment.schema.json
name: docker-image-example
image: pytorch/pytorch:latest
description: Environment created from a Docker image.

az ml environment create --file <yaml file>

Ahora puede usar el entorno en un trabajo de entrenamiento.

Creación el entorno administrado de Azure Machine Learning en una imagen base desde la instancia de ACR privada para el entrenamiento o la inferencia

Nota:

Actualmente no se admite la conexión a un ACR privado mediante la identidad administrada asignada por el usuario. La clave de administrador es el único tipo de autenticación compatible con ACR privado.

Pasos siguientes