Impostare l'autenticazione tra Azure Machine Learning e altri servizi

SI APPLICA A:estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)Python SDK azure-ai-ml v2 (corrente)

Azure Machine Learning è costituita di più servizi di Azure. Ci sono molteplici modi in cui può avvenire l'autenticazione tra Azure Machine Learning e i servizi di cui si avvale.

  • L'area di lavoro di Azure Machine Learning utilizza un'identità gestita per comunicare con altri servizi. Per impostazione predefinita, si tratta di un'identità gestita assegnata dal sistema. È possibile utilizzare anche un'identità gestita assegnata dall'utente al posto di quella predefinita.
  • Azure Machine Learning usa Registro Azure Container (ACR) per archiviare le immagini Docker utilizzate per eseguire il training e distribuire i modelli. Se si consente ad Azure Machine Learning di creare automaticamente un ACR, verrà abilitato l'account amministratore.
  • Il cluster dell'ambiente di calcolo di Azure Machine Learning utilizza un'identità gestita per recuperare informazioni di connessione per gli archivi dati da Azure Key Vault e per estrarre immagini Docker da ACR. È possibile configurare anche l'accesso basato sull'identità agli archivi dati, che utilizzerà invece l'identità gestita del cluster di elaborazione.
  • L'accesso ai dati può avvenire attraverso percorsi multipli a seconda del servizio di archiviazione dati e della configurazione. Ad esempio, l'autenticazione all'archivio dati può utilizzare una chiave dell'account, un token, un'entità di sicurezza, un'identità gestita o un'identità utente.
  • Gli endpoint online gestiti possono utilizzare un'identità gestita per accedere alle risorse Azure durante l'esecuzione dell'inferenza. Per altre informazioni, vedere Accedere alle risorse di Azure da un endpoint online.

Prerequisiti

Prima di seguire la procedura descritta in questo articolo, assicurarsi di disporre dei prerequisiti seguenti:

  • Per assegnare ruoli, l'accesso alla tua sottoscrizione Azure deve avere il ruolo di Operatore per identità gestita, o un altro ruolo che conceda le azioni richieste (come Proprietario).

  • È necessario avere familiarità con la creazione e l'uso delle Identità gestite.

Registro Azure Container e tipi di identità

La tabella seguente elenca la matrice di supporto durante l'autenticazione per Registro Azure Container, a seconda del metodo di autenticazione e della configurazione dell'accesso alla rete pubblica dell'Registro Azure Container.

Authentication method Accesso alla rete
pubblica disabilitato

accesso alla rete Registro Azure Container Public abilitato
Utente amministratore
Identità gestita assegnata dal sistema dell'area di lavoro
Identità
gestita assegnata dall'utente dell'area di lavoro con il ruolo ACRPull assegnato all'identità

Identità gestita assegnata dall'utente

Area di lavoro

È possibile aggiungere un'identità gestita assegnata dall'utente quando si crea un'area di lavoro di Azure Machine Learning dal portale di Azure. Eseguire la procedura seguente durante la creazione dell'area di lavoro:

  1. Dalla pagina Informazioni di base, selezionare l'account di archiviazione Azure, Registro Azure Container e Azure Key Vault che si vuole utilizzare con l'area di lavoro.
  2. Dalla pagina Identità, selezionare Identità assegnata dall'utente e quindi selezionare l'identità gestita da utilizzare.

Le seguenti assegnazioni di ruolo Controllo degli accessi in base al ruolo di Azure sono richieste sull'identità gestita assegnata dall'utente affinché l'area di lavoro di Azure Machine Learning possa accedere ai dati sulle risorse associate all'area di lavoro.

Conto risorse Autorizzazione
Azure Machine Learning workspace (Area di lavoro di Azure Machine Learning) Collaboratore
Archiviazione di Azure Collaboratore (piano di controllo) + Collaboratore dati Blob di archiviazione (piano dati, opzionale, per abilitare l'anteprima dei dati nello studio di Azure Machine Learning)
Azure Key Vault (quando si utilizza il modello di autorizzazioni Controllo degli accessi in base al ruolo) Collaboratore (piano di controllo) + Amministratore Key Vault (piano dati)
Azure Key Vault (quando si utilizza il modello di autorizzazioni Criteri di accesso) Collaboratore + qualsiasi permesso delle politiche di accesso escluso le operazioni di rimozione definitiva
Registro Azure Container Collaboratore
Azure Application Insights Collaboratore

Per la creazione automatizzata di assegnazioni di ruolo sulla tua identità gestita assegnata dall'utente, puoi utilizzare questo modello di ARM.

Suggerimento

Per un'area di lavoro con chiavi gestite dal cliente per la crittografia, è possibile passare un'identità gestita assegnata dall'utente per autenticare dalla risorsa di archiviazione a Key Vault. Usare i parametri user-assigned-identity-for-cmk-encryption (CLI) o user_assigned_identity_for_cmk_encryption (SDK) per passare l'identità gestita. Questa identità gestita può essere la stessa o diversa rispetto all'identità gestita primaria assegnata dall'utente dell'area di lavoro.

Per creare un'area di lavoro con più identità assegnate dall'utente, usare uno dei metodi seguenti:

SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

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

I cui contenuti di workspace_creation_with_multiple_UAIs.yml sono i seguenti:

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>

Per aggiornare le identità assegnate dall'utente per un'area di lavoro, inclusa l'aggiunta di una nuova o l'eliminazione di quelle esistenti, utilizza uno dei seguenti metodi:

SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

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

I cui contenuti di workspace_update_with_multiple_UAIs.yml sono i seguenti:

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>

Suggerimento

Per aggiungere una nuova identità assegnata dall'utente, è possibile specificare il nuovo ID dell'identità assegnata dall'utente nella sezione user_assigned_identities in aggiunta alle identità assegnate dall'utente esistenti; è richiesto inserire tutti gli ID delle identità assegnate dall'utente esistenti.
Per eliminare una o più identità assegnate dall'utente esistenti, è possibile inserire gli ID delle identità assegnate dall'utente che si desidera conservare nella sezione user_assigned_identities; gli altri ID delle identità assegnate dall'utente saranno eliminati.
Per aggiornare il tipo di identità da SAI a UAI|SAI, è possibile modificare il tipo da "assegnato dall'utente" a "assegnato dal sistema, assegnato dall'utente".

Cluster di elaborazione

Nota

I cluster di calcolo di Azure Machine Learning supportano solo una identità assegnata dal sistema o più identità assegnate dall'utente, non entrambe contemporaneamente.

L'identità gestita predefinita è l'identità gestita assegnata dal sistema o la prima identità gestita assegnata dall'utente.

Durante un'esecuzione sono previste due applicazioni di un'identità:

  1. Il sistema usa un'identità per configurare i montaggi di archiviazione dell'utente, il registro contenitori e gli archivi dati.

    • In questo caso, il sistema userà l'identità gestita predefinita.
  2. Si applica un'identità per accedere alle risorse dal codice per un processo inviato:

    • In questo caso, fornire il client_id corrispondente all'identità gestita che si vuole utilizzare per recuperare una credenziale.
    • In alternativa, ottenere l'ID del client dell'identità assegnata dall'utente tramite la variabile di ambiente DEFAULT_IDENTITY_CLIENT_ID.

    Ad esempio, per recuperare un token per un archivio dati con l'identità gestita predefinita:

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

Per configurare un cluster di elaborazione con identità gestita, utilizzare uno dei seguenti metodi:

SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

az ml compute create -f create-cluster.yml

I cui contenuti di create-cluster.yml sono i seguenti:

$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"

Per confronto, l'esempio seguente proviene da un file YAML che crea un cluster che utilizza un'identità gestita assegnata dal 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

Se si ha un cluster di elaborazione esistente, è possibile cambiare tra identità gestita dall'utente e identità gestita dal sistema. Gli esempi seguenti dimostrano come cambiare la configurazione:

Identità gestita assegnata dall'utente

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"

Identità gestita assegnata dal 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

Archiviazione di dati

Quando si crea un archivio dati che utilizza l'accesso ai dati basato su identità, l'account Azure (token Microsoft Entra) viene utilizzato per confermare che si dispone dell'autorizzazione ad accedere al servizio di archiviazione. Nello scenario di accesso ai dati basato su identità, non vengono salvate credenziali di autenticazione. Solo le informazioni sull'account di archiviazione sono archiviate nell'archivio dati.

Al contrario, gli archivi dati che utilizzano l'autenticazione basata su credenziali archiviano in cache le informazioni di connessione, come la chiave dell'account di archiviazione o il token SAS, nell'insieme di credenziali delle chiavi associato all'area di lavoro. Questo approccio ha la limitazione che altri utenti dell'area di lavoro con autorizzazioni sufficienti possono recuperare tali credenziali, il che può essere motivo di preoccupazione per la sicurezza per alcune organizzazioni.

Per maggiori informazioni su come viene autenticato l'accesso ai dati, vedere l'articolo sull'Amministrazione dei dati. Per informazioni sulla configurazione dell'accesso ai dati basato su identità, vedere Crea archivio dati.

Ci sono due scenari in cui puoi applicare l'accesso ai dati basato su identità in Azure Machine Learning. Questi scenari sono adatti per l'accesso basato su identità quando si lavora con dati riservati e si ha bisogno di una gestione dell'accesso ai dati più granulare:

  • Accesso ai servizi di archiviazione
  • Eseguire training di modelli di machine learning

L'accesso basato su identità ti consente di utilizzare i controlli degli accessi in base ai ruoli (RBAC) per limitare quali identità, come utenti o risorse di calcolo, hanno accesso ai dati.

Accesso ai servizi di archiviazione

È possibile connettersi ai servizi di archiviazione tramite l'accesso ai dati basato sull'identità con gli archivi dati di Azure Machine Learning.

Quando si utilizza l'accesso basato sull'identità, Azure Machine Learning richiede il token Microsoft Entra per l'autenticazione dell'accesso ai dati, anziché conservare le credenziali nell'archivio dati. Questo approccio consente la gestione dell'accesso ai dati a livello di archiviazione e mantiene le credenziali riservate.

Lo stesso comportamento si applica quando si lavora con i dati in modo interattivo tramite un notebook di Jupyter sul computer locale o sull'istanza di ambiente di calcolo.

Nota

Le credenziali archiviate tramite l'autenticazione basata su credenziali includono ID di abbonamento, token di firma di accesso condiviso (SAS), chiavi di accesso alle risorse di archiviazione e informazioni sull'entità servizio, come gli ID client e gli ID tenant.

Per garantire una connessione sicura al proprio servizio di storage su Azure, Azure Machine Learning richiede di disporre dell'autorizzazione ad accedere all'archiviazione dei dati corrispondente.

Avviso

L'accesso tra tenant agli account di archiviazione non è supportato. Se è necessario l'accesso tra tenant per lo scenario, contattare l'alias del team di supporto dati di Azure Machine Learning all'indirizzo amldatasupport@microsoft.com per ricevere assistenza e ottenere una soluzione di codice personalizzata.

L'accesso ai dati basato sull'identità supporta connessioni solo ai seguenti servizi di archiviazione.

  • Archiviazione BLOB di Azure
  • Azure Data Lake Storage Gen1
  • Azure Data Lake Storage Gen2

Per accedere a questi servizi di archiviazione, è necessario disporre di almeno l'accesso come Lettore dei dati del BLOB di archiviazione sull'account di archiviazione. Solo i proprietari degli account di archiviazione possono modificare il livello di accesso tramite il portale Azure.

Accesso ai dati per processi di training di calcolo tramite identità gestita

Alcuni scenari di machine learning comportano l'utilizzo di dati privati. In tali casi, i data scientist potrebbero non avere accesso diretto ai dati come utenti di Microsoft Entra. In questo scenario, l'identità gestita di un calcolo può essere utilizzata per l'autenticazione dell'accesso ai dati. In questo scenario, i dati possono essere accessibili solo da un'istanza di ambiente di calcolo o un cluster di elaborazione per machine learning che esegue un processo di training. Con questo approccio, l'amministratore concede all'identità gestita dell'istanza di ambiente di calcolo o del cluster di elaborazione, le autorizzazioni del Lettore dei dati BLOB di archiviazione sulla risorsa di archiviazione. Non è necessario concedere l'accesso ai singoli data scientist.

Per abilitare l'autenticazione con l'identità gestita di calcolo:

  • Creare il calcolo con l'identità gestita abilitata. Vedere la sezione del cluster di elaborazione, o per l'istanza di ambiente di calcolo, la sezione Assegna identità gestita.

    Importante

    Se l'istanza di ambiente di calcolo è configurata anche per l'arresto per inattività, la suddetta non si arresterà a causa dell'inattività a meno che l'identità gestita non abbia accesso come collaboratore all'area di lavoro di Azure Machine Learning. Per altre informazioni sull'assegnazione delle autorizzazioni, vedere Gestire gli accessi all'area di lavoro di Azure Machine Learning.

  • Concedere all'identità gestita di calcolo almeno il ruolo Lettore dati BLOB di archiviazione nell'account di archiviazione.

  • Creare eventuali datastore con l'autenticazione basata sull'identità abilitata. Vedere Creare datastore.

Nota

Il nome dell'identità gestita dal sistema creata per l'istanza di ambiente di calcolo o il cluster sarà nel formato /workspace-name/computes/compute-name nell'ID di Microsoft Entra.

Una volta abilitata l'autenticazione basata sull'identità, l'identità gestita di calcolo viene utilizzata per impostazione predefinita quando si accede ai dati all'interno dei processi di training. Facoltativamente, è possibile autenticarsi con l'identità utente seguendo i passaggi descritti nella sezione successiva.

Per informazioni sull'uso della configurazione del controllo degli accessi in base al ruolo di Azure per l'archiviazione, vedere controlli degli accessi basati sui ruoli.

Accesso ai dati per processi di training di calcolo tramite identità utente

SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

Quando si effettua il training sui cluster di elaborazione di Azure Machine Learning, è possibile autenticarsi alla risorsa di archiviazione con il proprio token utente di Microsoft Entra.

Questa modalità di autenticazione consente di:

  • Impostare autorizzazioni con granularità fine, dove diversi utenti dell'area di lavoro possono avere accesso a diversi account di archiviazione o cartelle all'interno degli account di archiviazione.
  • Consentire ai data scientist di riutilizzare le autorizzazioni esistenti sui sistemi di archiviazione.
  • Verificare l'accesso alla risorsa di archiviazione poiché i log di archiviazione mostrano quali identità sono state utilizzate per accedere ai dati.

Importante

Questa funzionalità presenta le limitazioni seguenti

  • La funzionalità è supportata per gli esperimenti inviati tramite l'Interfaccia della riga di comando di Azure Machine Learning e Python SDK V2, ma non tramite ML Studio.
  • L'identità dell'utente e l'identità gestita del calcolo non possono essere utilizzate per l'autenticazione nello stesso processo.
  • Per i processi di pipeline, si raccomanda di impostare l'identità utente a livello dei singoli passaggi che verranno eseguiti su un calcolo, piuttosto che a livello della pipeline radice. Sebbene l'impostazione dell'identità sia supportata sia a livello della pipeline radice che dei passaggi, l'impostazione a livello dei passaggi ha la precedenza se entrambe sono impostate. Tuttavia, per le pipeline contenenti componenti di pipeline, l'identità deve essere impostata sui singoli passaggi che verranno eseguiti. L'identità impostata a livello della pipeline radice o del componente della pipeline non funzionerà. Pertanto, si suggerisce di impostare l'identità a livello dei singoli passaggi per semplicità.)

I seguenti passaggi descrivono come configurare l'accesso ai dati con identità utente per processi di training sui cluster di elaborazione tramite interfaccia della riga di comando.

  1. Concedere all'identità utente l'accesso alle risorse di archiviazione. Ad esempio, concedere l'accesso StorageBlobReader all'account di archiviazione specifico che si vuole utilizzare o concedere autorizzazioni basate su ACL a cartelle o file specifici in Azure Data Lake Gen 2.

  2. Creare un datastore di Azure Machine Learning senza credenziali memorizzate nella cache per l'account di archiviazione. Se un datastore ha credenziali memorizzate nella cache, come la chiave dell'account di archiviazione, queste credenziali vengono utilizzate invece dell'identità utente.

  3. Inviare un processo di training con la proprietà identità impostata su type: user_identity, come mostrato nella seguente specifica del processo. Durante il processo di training, l'autenticazione all'archiviazione avviene tramite identità utente che invia il processo.

    Nota

    Se la proprietà identità non è specificata e il datastore non ha credenziali memorizzate nella cache, l'identità gestita del calcolo diventa l'opzione di fallback.

    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
    

I seguenti passaggi descrivono come configurare l'accesso ai dati con identità utente per processi di training sui cluster di elaborazione tramite Python SDK.

  1. Concedere l'accesso ai dati e creare un datastore come descritto sopra per l'interfaccia della riga di comando.

  2. Inviare un processo di training con il parametro identità impostato su azure.ai.ml.UserIdentityConfiguration. Tale configurazione del parametro consente al processo di accedere ai dati per conto dell'utente che invia il processo.

    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 l'invio del processo con l'autenticazione abilitata tramite identità utente, gli snapshot del codice sono protetti contro manomissioni durante la convalida mediante checksum. Se si dispongono di componenti di pipeline esistenti e si intende utilizzarli con l'autenticazione abilitata tramite identità utente, potrebbe essere necessario ricaricarli. Altrimenti, il processo potrebbe non andare a buon fine durante la convalida mediante checksum.

Lavorare con reti virtuali

Per impostazione predefinita, Azure Machine Learning non può comunicare con un account di archiviazione che si trova dietro un firewall o in una rete virtuale.

È possibile configurare gli account di archiviazione per consentire l'accesso solo da reti virtuali specifiche. Questa configurazione richiede passaggi aggiuntivi per garantire che i dati non vengano divulgati al di fuori della rete. Questo comportamento è lo stesso per l'accesso ai dati basato su credenziali. Per altre informazioni, vedere Come impedire l'esfiltrazione dei dati.

Se l'account di archiviazione dispone di impostazioni di rete virtuale, ciò determina il tipo di identità e le autorizzazioni di accesso necessarie. Ad esempio, per l'anteprima dei dati e il profilo dei dati, le impostazioni della rete virtuale determinano quale tipo di identità viene utilizzato per autenticare l'accesso ai dati.

  • In scenari in cui solo determinati IP e subnet sono autorizzati ad accedere all'archiviazione, Azure Machine Learning utilizza l'identità del servizio gestita dell'area di lavoro per realizzare anteprime e profili dei dati.

  • Se l'archiviazione è ADLS Gen 2 o Blob e dispone di impostazioni di rete virtuale, i clienti possono utilizzare sia l'identità utente che l'identità del servizio gestita dell'area di lavoro a seconda delle impostazioni del datastore definite durante la creazione.

  • Se l'impostazione della rete virtuale è "Consenti ai servizi Azure nell'elenco dei servizi attendibili di accedere a questo account di archiviazione", allora viene utilizzata l'identità del servizio gestita dell'area di lavoro.

Scenario: Registro Azure Container senza utente amministratore

Quando si disabilita l'utente amministratore per il Registro Azure Container, Azure Machine Learning utilizza un'identità gestita per compilare ed eseguire il pull delle immagini Docker. Sono due i flussi di lavoro quando si configura Azure Machine Learning per utilizzare un Registro Azure Container con l'utente amministratore disabilitato:

  • Consentire ad Azure Machine Learning di creare l'istanza del Registro Azure Container e quindi disabilitare l'utente amministratore successivamente.
  • Portare un Registro Azure Container esistente con l'utente amministratore già disabilitato.

Azure Machine Learning con istanza del Registro Azure Container creata automaticamente

  1. Creare una nuova area di lavoro di Azure Machine Learning.

  2. Eseguire un'azione che richiede il Registro Azure Container. Ad esempio, il Esercitazione: Eseguire il training del primo modello.

  3. Ottenere il nome del Registro Azure Container creato dal cluster.

    SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

    az ml workspace show -w <my workspace> \
    -g <my resource group>
    --query containerRegistry
    

    Il comando restituisce un valore simile al testo seguente. È necessaria solo l'ultima parte del testo, ovvero il nome dell'istanza di Registro Azure Container:

    /subscriptions/<subscription id>/resourceGroups/<my resource group>/providers/MicrosoftContainerReggistry/registries/<ACR instance name>
    
  4. Aggiornare il Registro Azure Container per disabilitare l'utente amministratore:

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

Usare il proprio Registro Azure Container

Se l'utente amministratore del Registro Azure Container non è consentito dai criteri di sottoscrizione, è prima necessario creare Registro Azure Container senza utente amministratore, quindi associarlo all'area di lavoro. Inoltre, se si dispone di un Registro Azure Container con l'utente amministratore disabilitato, è possibile collegarlo all'area di lavoro.

Creare un Registro Azure Container dall'interfaccia della riga di comando di Azure senza impostare l'argomento --admin-enabled oppure dal portale di Azure senza abilitare l'utente amministratore. Quindi, durante la creazione dell'area di lavoro di Azure Machine Learning, specificare l'ID risorsa di Azure del Registro Azure Container. L'esempio seguente illustra la creazione di una nuova area di lavoro di Azure Machine Learning che usa un registro Azure Container esistente:

Suggerimento

Per ottenere il valore per il parametro --container-registry, usare il comando az acr show per visualizzare le informazioni del proprio Registro Azure Container. Il campo id contiene l'ID risorsa per Registro Azure Container.

SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

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

Creare l'ambiente di calcolo con identità gestita per accedere alle immagini Docker per il training

Per accedere al Registro Azure Container dell'area di lavoro, creare un cluster di elaborazione di Machine Learning con l'identità gestita assegnata dal sistema abilitata. È possibile abilitare l'identità dal portale di Azure o da Studio durante la creazione dell'ambiente di calcolo o dall'interfaccia della riga di comando di Azure usando quanto segue. Per altre informazioni, vedere come usare l'identità gestita con cluster di elaborazione.

SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

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

A un'identità gestita viene concesso automaticamente il ruolo ACRPull nel Registro Azure Container dell'area di lavoro per abilitare il pull delle immagini Docker per il training.

Nota

Se si crea l'ambiente di calcolo prima della creazione del Registro Azure Container dell'area di lavoro, è necessario assegnare manualmente il ruolo ACRPull.

Usare immagini Docker per l'inferenza

Dopo aver configurato il Registro Azure Container senza l'utente amministratore come descritto in precedenza, è possibile accedere alle immagini Docker per l'inferenza senza chiavi di amministratore dal servizio Azure Kubernetes. Quando si crea o si collega il servizio Azure Kubernetes all'area di lavoro, all'entità di servizio del cluster viene assegnato automaticamente l'accesso ACRPull all'area di lavoro del Registro Azure Container.

Nota

Se si usa il proprio cluster del servizio Azure Kubernetes, è necessario che abbia l'entità servizio abilitata invece dell'identità gestita.

Scenario: Usare un Registro Azure Container privato

Per impostazione predefinita, Azure Machine Learning usa immagini di base Docker provenienti da un repository pubblico gestito da Microsoft. Crea quindi l'ambiente di training o inferenza in base a tali immagini. Per altre informazioni, vedere Che cosa sono gli ambienti ML?.

Per usare un'immagine di base personalizzata interna all'azienda, è possibile usare le identità gestite per accedere al Registro Azure Container privato. Esistono due casi di utilizzo:

  • Usare l'immagine di base per il training così come è.
  • Creare un'immagine gestita di Azure Machine Learning con un'immagine personalizzata come base.

Eseguire il pull dell'immagine di base Docker nel cluster di elaborazione di apprendimento automatico per il training così come è

Creare un cluster di calcolo di elaborazione di apprendimento automatico con l'identità gestita assegnata dal sistema abilitata come descritto in precedenza. Determinare quindi l'ID entità dell'identità gestita.

SI APPLICA A:Estensione ML dell'interfaccia della riga di comando di Azure v2 (corrente)

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

Facoltativamente, è possibile aggiornare il cluster di elaborazione per assegnare un'identità gestita assegnata dall'utente:

SI APPLICA A:Estensione ML dell'interfaccia della riga di comando di Azure v2 (corrente)

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

Per consentire al cluster di elaborazione di eseguire il pull delle immagini di base, concedere all'identità del servizio gestito il ruolo ACRPull nel Registro Azure Container privato

SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

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>"

Infine, creare un ambiente e specificare la posizione dell'immagine di base nel file YAML dell'ambiente.

SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

$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>

È ora possibile usare l'ambiente in un processo di training.

Creare un ambiente gestito di Azure Machine Learning nell'immagine di base dal Registro Azure Container privato per il training o l'inferenza

SI APPLICA A:Estensione ML dell'interfaccia della riga di comando di Azure v2 (corrente)

In questo scenario il servizio Azure Machine Learning crea l'ambiente di training o inferenza in base a un'immagine di base fornita da un Registro Azure Container privato. Poiché l'attività di creazione delle immagini avviene nell'area di lavoro del Registro Azure Container tramite Attività del Registro Azure Container, è necessario eseguire più passaggi per consentire l'accesso.

  1. Creare l'identità gestita assegnata dall'utente e concederle l'accesso ACRPull al Registro Azure Container privato.

  2. Concedere all'identità gestita dell'area di lavoro un ruolo Operatore di identità gestite per l'identità gestita assegnata dall'utente del passaggio precedente. Questo ruolo consente all'area di lavoro di assegnare l'identità gestita assegnata dall'utente ad Attività del Registro Azure Container per la creazione dell'ambiente gestito.

    1. Ottenere l'ID entità dell'identità gestita assegnata dal sistema dell'area di lavoro:

      SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

      az ml workspace show -w <workspace name> -g <resource group> --query identityPrincipalId
      
    2. Concedere il ruolo Operatore di identità gestite:

      az role assignment create --assignee <principal ID> --role managedidentityoperator --scope <user-assigned managed identity resource ID>
      

      L'ID risorsa dell'identità gestita assegnata dall'utente corrisponde all'ID risorsa di Azure dell'identità assegnata dall'utente, nel formato /subscriptions/<subscription ID>/resourceGroups/<resource group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned managed identity name>.

  3. Specificare il Registro Azure Container esterno e l'ID client dell'identità gestita assegnata dall'utente nelle connessioni all'area di lavoro usando il comando az ml connection. Questo comando accetta un file YAML che fornisce informazioni sulla connessione. L'esempio seguente dimostra il formato per specificare un'identità gestita. Sostituire i valori client_id e resource_id con quelli relativi alla propria identità gestita:

    SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)

    name: test_ws_conn_cr_managed
    type: container_registry
    target: https://test-feed.com
    credentials:
      type: managed_identity
      client_id: client_id
      resource_id: resource_id
    

    Il comando seguente dimostra come utilizzare il file YAML per creare una connessione con la propria area di lavoro. Sostituire <yaml file>, <workspace name> e <resource group> con i valori per la configurazione:

    az ml connection create --file <yml file> --resource-group <resource group> --workspace-name <workspace>
    
  4. Al termine della configurazione, è possibile usare le immagini di base del Registro Azure Container privato durante la creazione di ambienti per il training o l'inferenza. Il frammento di codice seguente illustra come specificare il Re+ dell'immagine di base e il nome dell'immagine in una definizione di ambiente:

    SI APPLICA A: Python SDK azure-ai-ml v2 (corrente)

    $schema: https://azuremlschemas.azureedge.net/latest/environment.schema.json
    name: private-acr-example
    image: <acr url>/pytorch/pytorch:latest
    description: Environment created from private ACR.
    

Passaggi successivi