Isolamento rete virtuale gestita dell'area di lavoro

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

Azure Machine Learning offre supporto per l'isolamento della rete virtuale gestita (rete virtuale gestita). L'isolamento della rete virtuale gestita semplifica e automatizza la configurazione dell'isolamento rete con una rete virtuale gestita di Azure Machine Learning predefinita a livello di area di lavoro. La rete virtuale gestita protegge le risorse di Azure Machine Learning gestite, ad esempio istanze di calcolo, cluster di calcolo, calcolo serverless ed endpoint online gestiti.

La protezione dell'area di lavoro con una rete gestita garantisce l'isolamento di rete per l'accesso in uscita dall'area di lavoro e dai calcoli gestiti. Un Rete virtuale di Azure creato e gestito viene usato per fornire l'accesso in ingresso per l'isolamento della rete all'area di lavoro. Ad esempio, nell'Rete virtuale di Azure viene creato un endpoint privato per l'area di lavoro. Tutti i client che si connettono alla rete virtuale possono accedere all'area di lavoro tramite l'endpoint privato. Quando si eseguono processi in calcoli gestiti, la rete gestita limita ciò che l'ambiente di calcolo può accedere.

Architettura di Rete Virtuale gestita

Quando si abilita l'isolamento della rete virtuale gestita, viene creata una rete virtuale gestita per l'area di lavoro. Le risorse di calcolo gestite create per l'area di lavoro usano automaticamente questa rete virtuale gestita. La rete virtuale gestita può usare endpoint privati per le risorse di Azure usate dall'area di lavoro, ad esempio Archiviazione di Azure, Azure Key Vault e Registro Azure Container.

Esistono due diverse modalità di configurazione per il traffico in uscita dalla rete virtuale gestita:

Suggerimento

Indipendentemente dalla modalità in uscita usata, il traffico verso le risorse di Azure può essere configurato per l'uso di un endpoint privato. Ad esempio, è possibile consentire tutto il traffico in uscita verso Internet, ma limitare la comunicazione con le risorse di Azure aggiungendo regole in uscita per le risorse.

Modalità in uscita Descrizione Scenari
Consenti Internet in uscita Consentire tutto il traffico Internet in uscita dalla rete virtuale gestita. Si vuole accedere senza restrizioni alle risorse di Machine Learning su Internet, ad esempio pacchetti Python o modelli con training preliminare.1
Consenti solo il traffico in uscita approvato Il traffico in uscita è consentito specificando i tag del servizio. * Si vuole ridurre al minimo il rischio di esfiltrazione di dati, ma è necessario preparare tutti gli artefatti di apprendimento automatico necessari nell'ambiente privato.
* Si vuole configurare l'accesso in uscita a un elenco approvato di servizi, tag del servizio o FQDN.
Disabilitata Il traffico in ingresso e in uscita non è limitato o si usa la propria rete virtuale di Azure per proteggere le risorse. Si vuole che l'accesso pubblico e il traffico in uscita provenga dall'area di lavoro o si gestisce l'isolamento della rete con la propria rete virtuale di Azure.

1: È possibile usare le regole in uscita con la modalità Consentire solo connessioni in uscita approvate per ottenere lo stesso risultato dell'uso previsto dalla modalità di Consentire internet in uscita. Le differenze sono le seguenti:

  • È necessario aggiungere regole per ogni connessione in uscita che bisogna consentire.
  • L'aggiunta di regole in uscita FQDN aumenta i costi perché questo tipo di regola usa il Firewall di Azure. Per altre informazioni, vedere la pagina Prezzi.
  • Le regole predefinite per Consentire solo connessioni in uscita approvate sono progettate per ridurre al minimo il rischio di esfiltrazione di dati. Le regole in uscita aggiunte possono aumentare il rischio.

La rete virtuale gestita è preconfigurata con le regole predefinite necessarie. Viene configurato anche per le connessioni endpoint private all'area di lavoro, l'archiviazione predefinita dell'area di lavoro, il registro contenitori e l'insieme di credenziali delle chiavi se sono configurati come privati o la modalità di isolamento dell'area di lavoro è impostata per consentire solo connessioni in uscita approvate. Dopo aver scelto la modalità di isolamento, potrebbe essere necessario considerare solo altri requisiti in uscita da aggiungere.

Il diagramma seguente mostra una rete virtuale gestita configurata per consentire internet in uscita:

Diagramma dell'isolamento della rete virtuale gestita configurato per Internet in uscita.

Il diagramma seguente mostra una rete virtuale gestita configurata per consentire solo il traffico in uscita approvato:

Nota

In questa configurazione, l'archiviazione, l'insieme di credenziali delle chiavi e il registro contenitori usati dall'area di lavoro vengono contrassegnati come privati. Poiché vengono contrassegnati come privati, viene usato un endpoint privato per comunicare con questi.

Diagramma dell'isolamento della rete virtuale gestita configurato per consentire solo l'approvazione in uscita.

Nota

Una volta configurata un'area di lavoro della rete virtuale gestita per consentire internet in uscita, l'area di lavoro non può essere riconfigurata in modo che sia disabilitata. Analogamente, dopo che un'area di lavoro di rete virtuale gestita è configurata per consentire solo connessioni in uscita approvate, l'area di lavoro non può essere riconfigurata per consentire internet in uscita. Tenere presente questo aspetto quando si seleziona la modalità di isolamento della rete virtuale gestita nell'area di lavoro.

Studio di Azure Machine Learning

Se si vuole usare il notebook integrato o creare dei set di dati nell'account di archiviazione predefinito da Studio, il client deve accedere all'account di archiviazione predefinito. Creare un endpoint privato o un endpoint di servizio per l'account di archiviazione predefinito nella rete virtuale di Azure usata dai client.

Parte dello studio di Azure Machine Learning viene eseguita in locale nel Web browser del client e comunica direttamente con l'archiviazione predefinita per l'area di lavoro. La creazione di un endpoint privato o di un endpoint di servizio (per l'account di archiviazione predefinito) nella rete virtuale del client garantisce che il client possa comunicare con l'account di archiviazione.

Per altre informazioni sulla creazione di un endpoint privato o di un endpoint di servizio, vedere gli articoli Connettersi privatamente a un account di archiviazione ed Endpoint di servizio.

Prerequisiti

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

  • Una sottoscrizione di Azure. Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare. Provare la versione gratuita o a pagamento di Azure Machine Learning.

  • Il provider di risorse Microsoft.Network deve essere registrato per la sottoscrizione di Azure. Questo provider di risorse viene usato dall'area di lavoro quando si creano endpoint privati per la rete virtuale gestita.

    Per informazioni sulla registrazione dei provider di risorse, vedere Risoluzione degli errori di registrazione del provider di risorse.

  • L'identità di Azure usata per la distribuzione di una rete gestita richiede le azioni di controllo degli accessi in base al ruolo di Azure seguenti per creare endpoint privati:

    • Microsoft.MachineLearningServices/workspaces/privateEndpointConnections/read
    • Microsoft.MachineLearningServices/workspaces/privateEndpointConnections/write
  • L'interfaccia della riga di comando di Azure e l'estensione ml per l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Installare, configurare e usare l'interfaccia della riga di comando (v2).

    Suggerimento

    La rete virtuale gestita di Azure Machine Learning è stata introdotta il 23 maggio 2023. Se si ha una versione precedente dell'estensione ml, potrebbe essere necessario aggiornarla affinché gli esempi riportati in questo articolo funzionino. Per aggiornare l'estensione, usare il comando seguente dell'interfaccia della riga di comando di Azure:

    az extension update -n ml
    
  • Gli esempi dell'interfaccia della riga di comando in questo articolo presuppongono che si usi la shell Bash (o compatibile). Ad esempio, un sistema Linux o un sottosistema Windows per Linux.

  • Gli esempi dell'interfaccia della riga di comando di Azure in questo articolo usano ws per rappresentare il nome dell'area di lavoro e rg per rappresentare il nome del gruppo di risorse. Modificare questi valori in base alle esigenze quando si usano i comandi con la sottoscrizione di Azure.

  • Grazie all'interfaccia della riga di comando di Azure e alla rete virtuale gestita, SSH funziona con un IP pubblico, ma SSH non funziona con un IP privato.

Nota

Se si usa l'area di lavoro UAI, assicurarsi di aggiungere il ruolo Collaboratore di rete alla propria identità. Per altre informazioni, vedere Identità gestita assegnata dall'utente.

Configurare una rete virtuale gestita per consentire internet in uscita

Suggerimento

La creazione della rete virtuale gestita viene posticipata fino a quando non viene creata una risorsa di calcolo o il provisioning non viene avviato manualmente. Quando si consente la creazione automatica, la creazione automatica può richiedere circa 30 minuti per creare la prima risorsa di calcolo perché esegue anche il provisioning della rete. Per altre informazioni, vedere Effettuare manualmente il provisioning della rete.

Importante

Se si prevede di inviare processi Spark serverless, è necessario avviare manualmente il provisioning. Per altre informazioni, vedere la sezioneconfigurare i processi Spark serverless.

Per configurare una rete virtuale gestita che consente le comunicazioni internet in uscita, è possibile usare il parametro --managed-network allow_internet_outbound o un file di configurazione YAML che contiene le voci seguenti:

managed_network:
  isolation_mode: allow_internet_outbound

È anche possibile definire le regole in uscita ad altri servizi di Azure su cui si basa l'area di lavoro. Queste regole definiscono endpoint privati che consentono a una risorsa di Azure di comunicare in modo sicuro con la rete virtuale gestita. La regola seguente illustra l'aggiunta di un endpoint privato a una risorsa BLOB di Azure.

managed_network:
  isolation_mode: allow_internet_outbound
  outbound_rules:
  - name: added-perule
    destination:
      service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>
      spark_enabled: true
      subresource_target: blob
    type: private_endpoint

È possibile configurare una rete virtuale gestita usando i comandi az ml workspace create o az ml workspace update:

  • Creazione di una nuova area di lavoro:

    Nell'esempio seguente viene creata una nuova area di lavoro. Il parametro --managed-network allow_internet_outbound configura una rete virtuale gestita per l'area di lavoro:

    az ml workspace create --name ws --resource-group rg --managed-network allow_internet_outbound
    

    Per creare un'area di lavoro usando invece un file YAML, usare il parametro --file e specificare il file YAML che contiene le impostazioni di configurazione:

    az ml workspace create --file workspace.yaml --resource-group rg --name ws
    

    L'esempio YAML seguente definisce un'area di lavoro con una rete virtuale gestita:

    name: myworkspace
    location: EastUS
    managed_network:
      isolation_mode: allow_internet_outbound
    
  • Aggiornare un'area di lavoro esistente:

    Avviso

    Prima di aggiornare un'area di lavoro esistente per usare una rete virtuale gestita, è necessario eliminare tutte le risorse di calcolo per l'area di lavoro. Sono inclusi l'istanza di calcolo, il cluster di elaborazione e gli endpoint online gestiti.

    Nell'esempio seguente viene aggiornata un'area di lavoro esistente. Il parametro --managed-network allow_internet_outbound configura una rete virtuale gestita per l'area di lavoro:

    az ml workspace update --name ws --resource-group rg --managed-network allow_internet_outbound
    

    Per aggiornare un'area di lavoro esistente usando il file YAML, usare il parametro --file e specificare il file YAML che contiene le impostazioni di configurazione:

    az ml workspace update --file workspace.yaml --name ws --resource-group MyGroup
    

    L'esempio YAML seguente definisce una rete virtuale gestita dell'area di lavoro. Viene inoltre illustrato come aggiungere una connessione di un endpoint privato a una risorsa usata dall'area di lavoro; in questo esempio, un endpoint privato per un archivio BLOB:

    name: myworkspace
    managed_network:
      isolation_mode: allow_internet_outbound
      outbound_rules:
      - name: added-perule
        destination:
          service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>
          spark_enabled: true
          subresource_target: blob
        type: private_endpoint
    

Configurare una rete virtuale gestita per consentire solo il traffico in uscita approvato

Suggerimento

Il provisioning della rete virtuale gestita viene eseguito automaticamente quando si crea una risorsa di calcolo. Quando si consente la creazione automatica, potrebbero essere necessari circa 30 minuti per creare la prima risorsa di calcolo perché esegue anche il provisioning della rete. Se sono state configurate regole in uscita FQDN, la prima regola FQDN aggiunge circa 10 minuti al tempo di provisioning. Per altre informazioni, vedere Effettuare manualmente il provisioning della rete.

Importante

Se si prevede di inviare processi Spark serverless, è necessario avviare manualmente il provisioning. Per altre informazioni, vedere la sezioneconfigurare i processi Spark serverless.

Per configurare una rete virtuale gestita che consenta solo le comunicazioni in uscita approvate, è possibile usare il parametro --managed-network allow_only_approved_outbound o un file di configurazione YAML contenente le voci seguenti:

managed_network:
  isolation_mode: allow_only_approved_outbound

È anche possibile definire regole in uscita per definire le comunicazioni in uscita approvate. È possibile creare una regola in uscita per un tipo di service_tag, fqdn e private_endpoint. La regola seguente illustra l'aggiunta di un endpoint privato a una risorsa BLOB di Azure, un tag del servizio ad Azure Data Factory e un FQDN a pypi.org:

Importante

  • L'aggiunta di traffico in uscita per un tag del servizio o FQDN è valida solo quando la rete virtuale gestita è configurata su allow_only_approved_outbound.
  • Se si aggiungono regole in uscita, Microsoft non può garantire l'esfiltrazione di dati.

Avviso

Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.

managed_network:
  isolation_mode: allow_only_approved_outbound
  outbound_rules:
  - name: added-servicetagrule
    destination:
      port_ranges: 80, 8080
      protocol: TCP
      service_tag: DataFactory
    type: service_tag
  - name: add-fqdnrule
    destination: 'pypi.org'
    type: fqdn
  - name: added-perule
    destination:
      service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>
      spark_enabled: true
      subresource_target: blob
    type: private_endpoint

È possibile configurare una rete virtuale gestita usando i comandi az ml workspace create o az ml workspace update:

  • Creazione di una nuova area di lavoro:

    L'esempio seguente usa il parametro --managed-network allow_only_approved_outbound per configurare la rete virtuale gestita:

    az ml workspace create --name ws --resource-group rg --managed-network allow_only_approved_outbound
    

    Il file YAML seguente definisce un'area di lavoro con una rete virtuale gestita:

    name: myworkspace
    location: EastUS
    managed_network:
      isolation_mode: allow_only_approved_outbound
    

    Per creare un'area di lavoro usando il file YAML, usare il parametro --file:

    az ml workspace create --file workspace.yaml --resource-group rg --name ws
    
  • Aggiornare un'area di lavoro esistente

    Avviso

    Prima di aggiornare un'area di lavoro esistente per usare una rete virtuale gestita, è necessario eliminare tutte le risorse di calcolo per l'area di lavoro. Sono inclusi l'istanza di calcolo, il cluster di elaborazione e gli endpoint online gestiti.

    L'esempio seguente usa il parametro --managed-network allow_only_approved_outbound per configurare la rete virtuale gestita per un'area di lavoro esistente:

    az ml workspace update --name ws --resource-group rg --managed-network allow_only_approved_outbound
    

    Il file YAML seguente definisce una rete virtuale gestita per l'area di lavoro. Illustra anche come aggiungere una rete in uscita approvata alla rete virtuale gestita. In questo esempio viene aggiunta una regola in uscita per entrambi i tag del servizio:

    Avviso

    Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.

    name: myworkspace_dep
    managed_network:
      isolation_mode: allow_only_approved_outbound
      outbound_rules:
      - name: added-servicetagrule
        destination:
          port_ranges: 80, 8080
          protocol: TCP
          service_tag: DataFactory
        type: service_tag
      - name: add-fqdnrule
        destination: 'pypi.org'
        type: fqdn
      - name: added-perule
        destination:
          service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>
          spark_enabled: true
          subresource_target: blob
        type: private_endpoint
    

Configurare per i processi Spark serverless

Suggerimento

I passaggi descritti in questa sezione sono necessari solo se si prevede di inviare processi Spark serverless. Se non si intende inviare processi Spark serverless, è possibile ignorare questa sezione.

Per abilitare i processi Spark serverless per la rete virtuale gestita, è necessario eseguire le azioni seguenti:

  • Configurare una rete virtuale gestita per l'area di lavoro e aggiungere un endpoint privato in uscita per l'account di archiviazione di Azure.
  • Dopo aver configurato la rete virtuale gestita, eseguirne il provisioning e contrassegnarlo per consentire i processi Spark.
  1. Configurare un endpoint privato in uscita.

    Usare un file YAML per definire la configurazione della rete virtuale gestita e aggiungere un endpoint privato per l'account di archiviazione di Azure. Impostare anche spark_enabled: true:

    Suggerimento

    Questo esempio riguarda una rete virtuale gestita configurata usando isolation_mode: allow_internet_outbound per consentire il traffico Internet. Se si vuole consentire solo connessioni in uscita approvate, usare isolation_mode: allow_only_approved_outbound.

    name: myworkspace
    managed_network:
      isolation_mode: allow_internet_outbound
      outbound_rules:
      - name: added-perule
        destination:
          service_resource_id: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>
          spark_enabled: true
          subresource_target: blob
        type: private_endpoint
    

    È possibile usare un file di configurazione YAML con il comando az ml workspace update specificando il parametro --file e il nome del file YAML. Ad esempio, il comando seguente aggiorna un'area di lavoro esistente usando un file YAML denominato workspace_pe.yml:

    az ml workspace update --file workspace_pe.yml --resource_group rg --name ws
    

    Nota

    Quando l'opzione Consentire solo connessioni in uscita approvate è abilitata (isolation_mode: allow_only_approved_outbound), le dipendenze del pacchetto conda definite nella configurazione della sessione Spark non riusciranno a essere installate. Per risolvere questo problema, caricare un file wheel del pacchetto Python completo senza dipendenze esterne in un account di archiviazione di Azure e creare un endpoint privato in questo account di archiviazione. Usare il percorso del file wheel del pacchetto Python come parametro py_files nel processo Spark. L'impostazione di una regola in uscita FQDN non consente di ignorare questo problema perché la propagazione delle regole FQDN non è supportata da Spark.

  2. Effettuare il provisioning della rete virtuale gestita.

    Nota

    Se l'area di lavoro è già configurata per un endpoint pubblico(ad esempio con una rete virtuale di Azure) e ha l'accesso alla rete pubblica abilitata, è necessario disabilitarla prima di effettuare il provisioning della rete virtuale gestita. Se non si disabilita l'accesso alla rete pubblica durante il provisioning della rete virtuale gestita, è possibile che gli endpoint privati per l'endpoint gestito non vengano creati correttamente.

    L'esempio seguente illustra come effettuare il provisioning di una rete virtuale gestita per i processi Spark serverless usando il parametro --include-spark.

    az ml workspace provision-network -g my_resource_group -n my_workspace_name --include-spark
    

Effettuare manualmente il provisioning di una rete virtuale gestita

Il provisioning della rete virtuale gestita viene eseguito automaticamente quando si crea una risorsa di calcolo. Quando si fa affidamento sul provisioning automatico, possono essere necessari circa 30 minuti per creare la prima risorsa di calcolo perché viene eseguito anche il provisioning della rete. Se sono state configurate regole in uscita FQDN (disponibili solo con la modalità Consentire solo traffico approvato), la prima regola FQDN aggiunge circa 10 minuti al tempo di provisioning. Se si dispone di un ampio set di regole in uscita di cui eseguire il provisioning nella rete gestita, il provisioning può richiedere più tempo. L'aumento del tempo di provisioning può causare il timeout della prima creazione di calcolo o la prima distribuzione dell'endpoint online gestito.

Per ridurre il tempo di attesa ed evitare potenziali errori di timeout, è consigliabile effettuare manualmente il provisioning della rete gestita. Attendere quindi il completamento del provisioning prima di creare una risorsa di calcolo o una distribuzione di endpoint online gestita.

L'esempio seguente illustra come effettuare il provisioning di una rete virtuale gestita.

Suggerimento

Se si prevede di inviare processi Spark serverless, aggiungere il parametro --include-spark.

az ml workspace provision-network -g my_resource_group -n my_workspace_name

Per verificare che il provisioning sia stato completato, usare il comando seguente:

az ml workspace show -n my_workspace_name -g my_resource_group --query managed_network

Configurare la creazione di immagini

Quando registro Azure Container per l'area di lavoro si trova dietro una rete virtuale, non può essere usato per compilare direttamente immagini Docker. Configurare invece l'area di lavoro per usare un cluster di elaborazione o un'istanza di ambiente calcolo per compilare immagini.

Importante

La risorsa di elaborazione usato per compilare le immagini Docker deve essere in grado di accedere ai repository di pacchetti utilizzati per eseguire il training e la distribuzione dei modelli. Se si usa una rete configurata per consentire solo il traffico approvato in uscita, potrebbe essere necessario aggiungere regole che consentano l'accesso ai repository pubblici o usare pacchetti Python privati.

Per aggiornare un'area di lavoro per usare un cluster di elaborazione o un'istanza di ambiente calcolo per compilare immagini Docker, usare il comando az ml workspace update con il parametro --image-build-compute:

az ml workspace update --name ws --resource-group rg --image-build-compute mycompute

Gestire le regole in uscita

Per elencare le regole in uscita della rete virtuale gestita per un'area di lavoro, usare il comando seguente:

az ml workspace outbound-rule list --workspace-name ws --resource-group rg

Per visualizzare i dettagli di una regola in uscita della rete virtuale gestita, usare il comando seguente:

az ml workspace outbound-rule show --rule rule-name --workspace-name ws --resource-group rg

Per rimuovere una regola in uscita dalla rete virtuale gestita, usare il comando seguente:

az ml workspace outbound-rule remove --rule rule-name --workspace-name ws --resource-group rg

Elenco delle regole obbligatorie

Suggerimento

Queste regole vengono aggiunte automaticamente alla rete virtuale gestita.

Endpoint privati:

  • Quando la modalità di isolamento della rete virtuale gestita è Allow internet outbound, le regole in uscita dell'endpoint privato vengono create automaticamente come regole necessarie dalla rete virtuale gestita per l'area di lavoro e le risorse associate all'accesso alla rete pubblica disabilitata (insieme di credenziali delle chiavi, account di archiviazione, registro contenitori, area di lavoro di Azure Machine Learning).
  • Quando la modalità di isolamento per la rete virtuale gestita è Allow only approved outbound, le regole in uscita dell'endpoint privato vengono create automaticamente come regole necessarie dalla rete virtuale gestita per l'area di lavoro e le risorse associateindipendentemente dalla modalità di accesso alla rete pubblica per tali risorse (Insieme di credenziali delle chiavi, account di archiviazione, registro contenitori, area di lavoro di Azure Machine Learning).

Regole dei tag del servizio in uscita:

  • AzureActiveDirectory
  • AzureMachineLearning
  • BatchNodeManagement.region
  • AzureResourceManager
  • AzureFrontDoor
  • MicrosoftContainerRegistry
  • AzureMonitor

Regole dei tag del servizio in ingresso :

  • AzureMachineLearning

Elenco di regole in uscita specifiche dello scenario

Scenario: accedere ai pacchetti di apprendimento automatico pubblici

Per consentire l'installazione di pacchetti Python per il training e la distribuzione, aggiungere regole FQDN in uscita per consentire il traffico verso i nomi host seguenti:

Avviso

Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.

Nota

Questo non è un elenco completo degli host necessari per tutte le risorse di Python su Internet, ma solo dei più usati. Ad esempio, se è necessario accedere a un repository GitHub o a un altro host, occorre identificare e aggiungere gli host necessari per tale scenario.

Nome host Scopo
anaconda.com
*.anaconda.com
Usato per installare i pacchetti predefiniti.
*.anaconda.org Usato per ricevere i dati del repository.
pypi.org Usato per elencare le dipendenze dall'indice predefinito, se presenti e se l'indice non viene sovrascritto dalle impostazioni utente. Se l'indice è sovrascritto, è necessario consentire anche *.pythonhosted.org.
pytorch.org
*.pytorch.org
Usato da alcuni esempi basati su PyTorch.
*.tensorflow.org Usato da alcuni esempi basati su Tensorflow.

Scenario: usare il Visual Studio Code per desktop o web con l'istanza di ambiente calcolo

Se si prevede di usare Visual Studio Code con Azure Machine Learning, aggiungere regole FQDN in uscita per consentire il traffico agli host seguenti:

Avviso

Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.

  • *.vscode.dev
  • vscode.blob.core.windows.net
  • *.gallerycdn.vsassets.io
  • raw.githubusercontent.com
  • *.vscode-unpkg.net
  • *.vscode-cdn.net
  • *.vscodeexperiments.azureedge.net
  • default.exp-tas.com
  • code.visualstudio.com
  • update.code.visualstudio.com
  • *.vo.msecnd.net
  • marketplace.visualstudio.com
  • vscode.download.prss.microsoft.com

Scenario: usare endpoint batch

Se si prevede di usare endpoint batch di Azure Machine Learning per la distribuzione, aggiungere regole di endpoint privato in uscita per consentire il traffico verso le risorse secondarie seguenti per l'account di archiviazione predefinito:

  • queue
  • table
  • Endpoint privato a Servizi di Azure AI
  • Endpoint privato in Azure AI Search

Scenario: usare modelli HuggingFace

Se si prevede di usare modelli HuggingFace con Azure Machine Learning, aggiungere regole di FQDN in uscita per consentire il traffico verso gli host seguenti:

Avviso

Le regole in uscita del nome di dominio completo vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Per altre informazioni, vedere Prezzi.

  • docker.io
  • *.docker.io
  • *.docker.com
  • production.cloudflare.docker.com
  • cdn.auth0.com
  • cdn-lfs.huggingface.co

Scenario: abilitare l'accesso da indirizzi IP selezionati

Se si vuole abilitare l'accesso da indirizzi IP specifici, usare le azioni seguenti:

  1. Aggiungere una regola di endpoint privato in uscita per consentire il traffico all'area di lavoro di Azure Machine Learning. Ciò consente alle istanze di calcolo create nella rete virtuale gestita di accedere all'area di lavoro.

    Suggerimento

    Non è possibile aggiungere questa regola durante la creazione dell'area di lavoro, perché l'area di lavoro non esiste ancora.

  2. Abilitare l'accesso alla rete pubblica all'area di lavoro. Per altre informazioni, vedere l’accesso alla rete pubblica abilitato.

  3. Aggiungere gli indirizzi IP al firewall per Azure Machine Learning. Per altre informazioni, vedere abilitare l'accesso solo dagli intervalli IP.

Endpoint privati

Gli endpoint privati sono attualmente supportati per i servizi di Azure seguenti:

  • Azure Machine Learning
  • Registri di Azure Machine Learning
  • Archiviazione di Azure (tutti i tipi di risorse secondarie)
  • Registro Azure Container
  • Azure Key Vault
  • Servizi di Azure AI
  • Azure AI Search (in precedenza Ricerca cognitiva)
  • Azure SQL Server
  • Azure Data Factory
  • Azure Cosmos DB (tutti i tipi di risorse secondarie)
  • Hub eventi di Azure
  • Cache Redis di Azure
  • Azure Databricks
  • Database di Azure per MariaDB
  • Database di Azure per PostgreSQL
  • Database di Azure per MySQL
  • Istanza gestita di SQL di Azure
  • Gestione API di Azure

Quando si crea un endpoint privato, si specifica il tipo di risorsa e la risorsa secondaria a cui si connette l'endpoint. Alcune risorse hanno più tipi e risorse secondarie. Per altre informazioni, vedere che cos'è un endpoint privato.

Quando si crea un endpoint privato per le risorse di dipendenza di Azure Machine Learning, ad esempio Archiviazione di Azure, Registro Azure Container e Azure Key Vault, la risorsa può trovarsi in una sottoscrizione di Azure diversa. Tuttavia, la risorsa deve trovarsi nello stesso tenant dell'area di lavoro di Azure Machine Learning.

Importante

Quando si configurano endpoint privati per una rete virtuale gestita di Azure Machine Learning, gli endpoint privati vengono creati solo quando viene creato il primo calcolo o quando viene forzato il provisioning della rete virtuale gestita. Per altre informazioni sull'uso forzato del provisioning della rete virtuale gestita, vedere Configurare i processi Spark serverless.

Prezzi

La funzionalità di rete virtuale gestita di Azure Machine Learning è gratuita. Tuttavia, vengono addebitati i costi per le seguenti risorse usate dalla rete virtuale gestita:

  • Collegamento privato di Azure: gli endpoint privati usati per proteggere le comunicazioni tra la rete virtuale gestita e le risorse di Azure si basano sul collegamento privato di Azure. Per altre informazioni sui prezzi, vedere Prezzi di Collegamento privato di Azure.

  • Regole in uscita FQDN: le regole in uscita FQDN vengono implementate tramite Firewall di Azure. Se si usano regole FQDN in uscita, gli addebiti per Firewall di Azure vengono aggiunti alla fatturazione. Il provisioning di Firewall di Azure (SKU standard) viene effettuato da Azure Machine Learning.

    Importante

    Il firewall non viene creato fino a quando non si aggiunge una regola FQDN in uscita. Per altre informazioni sui prezzi, vedere Prezzi di Firewall di Azure e visualizzare i prezzi per la versione standard.

Limiti

  • Dopo aver abilitato l'isolamento della rete virtuale gestita dell'area di lavoro, non è possibile disabilitarlo.
  • La rete virtuale gestita usa la connessione endpoint privato per accedere alle risorse private. Non è possibile avere un endpoint privato e un endpoint di servizio contemporaneamente per le risorse di Azure, ad esempio un account di archiviazione. È consigliabile usare endpoint privati in tutti gli scenari.
  • La rete virtuale gestita viene eliminata quando l'area di lavoro viene eliminata.
  • La protezione dell'esfiltrazione di dati viene abilitata automaticamente per l'unica modalità in uscita approvata. Se si aggiungono altre regole in uscita, ad esempio i nomi di dominio completi, Microsoft non può garantire la protezione dall'esfiltrazione di dati a tali destinazioni in uscita.
  • La creazione di un cluster di elaborazione in un'area diversa da quella dell'area di lavoro non è supportata quando si usa una rete virtuale gestita.
  • Kubernetes e macchine virtuali collegate non sono supportate in una rete virtuale gestita di Azure Machine Learning.
  • L'uso delle regole in uscita FQDN aumenta il costo della rete virtuale gestita perché le regole FQDN usano Firewall di Azure. Per altre informazioni, vedere Prezzi.

Migrazione delle risorse di calcolo

Se è presente un'area di lavoro e si vuole abilitare la rete virtuale gestita per tale area di lavoro, non è al momento disponibile alcun percorso di migrazione supportato per le risorse di calcolo gestite esistenti. È necessario eliminare tutte le risorse di calcolo gestite esistenti e ricrearle dopo aver abilitato la rete virtuale gestita. L'elenco seguente contiene le risorse di calcolo che devono essere eliminate e ricreate:

  • Cluster di elaborazione
  • Istanza di calcolo
  • Cluster Kubernetes
  • Endpoint online gestiti

Passaggi successivi