Proteggere le soluzioni MLOps con la sicurezza di rete di Azure

Machine Learning DevOps (MLOps), evidenziato per la prima volta in Hidden Technical Debt in Machine Learning Systems nel 2015, sta crescendo rapidamente. Il mercato per MLOps dovrebbe raggiungere $ 4 miliardi entro il 2025. Nel frattempo, lavorare per proteggere le soluzioni MLOps sta diventando più importante.

Questo articolo descrive come proteggere le soluzioni MLOps usando funzionalità di sicurezza di rete di Azure, ad esempio Azure Rete virtuale, peering di rete, collegamento privato di Azure e DNS di Azure. Illustra anche come usare:

• Azure Pipelines per accedere alle risorse nella rete virtuale
• Le configurazioni necessarie di Registro Azure Container e istanze di calcolo e cluster di Azure Machine Learning in una rete virtuale.

Infine, questo articolo descrive i costi dell'uso dei servizi di sicurezza di rete.

Architettura

Scaricare un file di Visio di questa architettura.

Flusso di dati

Il diagramma dell'architettura mostra una soluzione MLOps di esempio.

• La rete virtuale denominata VNET AML consente di proteggere l'area di lavoro di Azure Machine Learning e le risorse associate.

• L'host jump, Azure Bastion e gli agenti self-hosted appartengono a un'altra rete virtuale denominata BASTION VNET. Questa disposizione simula la presenza di un'altra soluzione che richiede l'accesso alle risorse all'interno della rete virtuale di Azure Machine Learning.

• Con il supporto del peering di rete virtuale e delle zone DNS private, Azure Pipelines può essere eseguito su agenti self-host e attivare le pipeline di Azure Machine Learning pubblicate nell'area di lavoro di Azure Machine Learning per eseguire il training, valutare e registrare i modelli di Machine Learning.

• Infine, il modello viene distribuito in endpoint online o endpoint batch supportati dalle risorse di calcolo di Azure Machine Learning o servizio Azure Kubernetes cluster.

Componenti

La soluzione MLOps di esempio è costituita da questi componenti:

• Archiviazione dati: Archiviazione BLOB di Azure per l'archiviazione dei dati.
• Training, convalida e registrazione del modello: area di lavoro di Azure Machine Learning
• Distribuzione del modello: endpoint e servizio Azure Kubernetes di Azure Machine Learning
• Monitoraggio del modello: Monitoraggio di Azure per Application Insights
• Pipeline MLOps: Azure DevOps e Azure Pipelines

Questo scenario di esempio usa anche i servizi seguenti per proteggere la soluzione MLOps:

• Azure Key Vault
• Criteri di Azure
• Rete virtuale

Dettagli dello scenario

MLOps è un set di procedure all'intersezione tra Machine Learning, DevOps e progettazione dei dati che mira a distribuire e gestire modelli di Machine Learning nell'ambiente di produzione in modo affidabile ed efficiente.

Il diagramma seguente illustra un modello di processo MLOps semplificato. Questo modello offre una soluzione che automatizza la preparazione dei dati, il training del modello, la valutazione del modello, la registrazione del modello, la distribuzione del modello e il monitoraggio.

Quando si implementa una soluzione MLOps, è possibile proteggere queste risorse:

• Pipeline DevOps
• Dati sul training di machine learning
• Pipeline di apprendimento automatico
• Modelli di Machine Learning

Per proteggere le risorse, considerare questi metodi:

• Autenticazione e autorizzazione

  • Usare le entità servizio o le identità gestite anziché l'autenticazione interattiva.
  • Utilizzare il controllo degli accessi in base al ruolo per definire l'ambito dell'accesso di un utente alle risorse.

• Sicurezza di rete

  • Usare Rete virtuale per isolare parzialmente o completamente l'ambiente dalla rete Internet pubblica per ridurre la superficie di attacco e il potenziale di esfiltrazione dei dati.
    • Nell'area di lavoro di Azure Machine Learning, se si usa ancora l'interfaccia della riga di comando di Azure Machine Learning v1 e Azure Machine Learning Python SDK v1 (ad esempio l'API v1), aggiungere un endpoint privato all'area di lavoro per fornire isolamento di rete per tutti gli elementi, ad eccezione delle operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) nell'area di lavoro o nelle risorse di calcolo.
    • Per sfruttare le nuove funzionalità di un'area di lavoro di Azure Machine Learning, usare l'interfaccia della riga di comando di Azure Machine Learning v2 e Azure Machine Learning Python SDK v2 (ad esempio l'API v2), in cui l'abilitazione di un endpoint privato nell'area di lavoro non fornisce lo stesso livello di isolamento della rete. Tuttavia, la rete virtuale continuerà a proteggere i dati di training e i modelli di Machine Learning. È consigliabile valutare l'API v2 prima di adottarla nelle soluzioni aziendali. Per maggiori informazioni, consultare la sezione Che cos'è la nuova piattaforma API in Azure Resource Manager?

• Crittografia dei dati

  • Crittografare i dati di training in transito e inattivi usando chiavi di accesso gestite dalla piattaforma o gestite dal cliente.

• Criteri e monitoraggio

  • Usare Criteri di Azure e Microsoft Defender per il cloud per applicare i criteri.
  • Usare Monitoraggio di Azure per raccoglie e aggregare i dati (come le metriche e i log) provenienti da diverse origini in una piattaforma dati comune, nella quale è possibile usare tali dati a scopo di analisi, visualizzazione e creazione di avvisi.

L'area di lavoro di Azure Machine Learning è la risorsa di primo livello per Azure Machine Learning e il componente principale di una soluzione MLOps. L'area di lavoro fornisce una posizione centralizzata per lavorare con tutti gli artefatti creati durante l'uso del servizio Azure Machine Learning.

Quando si crea una nuova area di lavoro, vengono create automaticamente le seguenti risorse di Azure usate dall'area di lavoro:

• Azure Application Insights
• Registro Azure Container
• Azure Key Vault
• Account di archiviazione di Azure

Potenziali casi d'uso

Questa soluzione si adatta agli scenari in cui un cliente usa una soluzione MLOps per distribuire e gestire modelli di Machine Learning in un ambiente più sicuro. I clienti possono provenire da diversi settori, ad esempio produzione, telecomunicazioni, vendita al dettaglio, assistenza sanitaria e così via. Ad esempio:

• Un gestore di telecomunicazioni consente di proteggere le immagini, i dati e i modelli di Machine Learning di un cliente nel sistema di monitoraggio video per i punti vendita al dettaglio.

• Un produttore di motori necessita di una soluzione più sicura per proteggere i dati e i modelli di Machine Learning delle sue factory e dei suoi prodotti per il sistema che usa visione artificiale per rilevare i difetti nelle parti.

Le soluzioni MLOps per questi scenari e altri potrebbero usare aree di lavoro di Azure Machine Learning, Archiviazione BLOB di Azure, servizio Azure Kubernetes, Registro Container e altri servizi di Azure.

È possibile usare tutto o parte di questo esempio per qualsiasi scenario simile con un ambiente MLOps distribuito in Azure e usa le funzionalità di sicurezza di Azure per proteggere le risorse pertinenti. Il cliente originale per questa soluzione è nel settore delle telecomunicazioni.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che migliorano la qualità di un carico di lavoro, quando applicati. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Sicurezza

La sicurezza offre più garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Si consideri come proteggere la soluzione MLOps a partire dalla progettazione dell'architettura. Gli ambienti di sviluppo potrebbero non necessitare di una sicurezza significativa, ma è importante negli ambienti di gestione temporanea e di produzione.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

La configurazione di Rete virtuale è gratuita, ma sono previsti addebiti per gli altri servizi che potrebbero essere necessari, ad esempio collegamenti privati, zone DNS e peering di rete virtuale. Nella tabella seguente vengono descritti gli addebiti per tali servizi e altri servizi che potrebbero essere necessari.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Per semplificare l'integrazione continua e il recapito continuo (CI/CD), la procedura consigliata consiste nell'usare strumenti e servizi per l'infrastruttura come codice (IaC), ad esempio Modelli di Terraform o Azure Resource Manager, Azure DevOps e Azure Pipelines.

Distribuire lo scenario

Le sezioni seguenti descrivono come distribuire, accedere e proteggere le risorse in questo scenario di esempio.

Rete virtuale

Il primo passaggio per proteggere l'ambiente MLOps consiste nel proteggere l'area di lavoro di Azure Machine Learning e le risorse associate. Un metodo efficace di protezione consiste nell'usare Rete virtuale. Una rete virtuale è il blocco costitutivo fondamentale per una rete privata in Azure. Le reti virtuali consentono a numerosi tipi di risorse di Azure di comunicare in modo più sicuro tra loro, con Internet e con le reti locali.

L'inserimento dell'area di lavoro di Azure Machine Learning e delle risorse associate in una rete virtuale consente di garantire che i componenti possano comunicare tra loro senza esporli alla rete Internet pubblica. In questo modo si riduce la superficie di attacco e si evita l'esfiltrazione dei dati.

Il frammento terraform seguente illustra come creare un cluster di calcolo per Azure Machine Learning, collegarlo a un'area di lavoro e inserirlo in una subnet di una rete virtuale.

resource "azurerm_machine_learning_compute_cluster" "compute_cluster" {
  name                          = "my_compute_cluster"
  location                      = "eastasia"
  vm_priority                   = "LowPriority"
  vm_size                       = "Standard_NC6s_v3"
  machine_learning_workspace_id = azurerm_machine_learning_workspace.my_workspace.id
  subnet_resource_id            = azurerm_subnet.compute_subnet.id
  ssh_public_access_enabled     = false
  scale_settings {
    min_node_count                       = 0
    max_node_count                       = 3
    scale_down_nodes_after_idle_duration = "PT30S"
  }
  identity {
    type = "SystemAssigned"
  }
}

Collegamento privato ed endpoint privato di Azure

Collegamento privato consente l'accesso tramite un endpoint privato nella rete virtuale alle opzioni PaaS (Platform as a Service) di Azure, ad esempio un'area di lavoro di Azure Machine Learning e Archiviazione di Azure, e ai servizi di proprietà del cliente e del partner ospitati in Azure. Un endpoint privato è un'interfaccia di rete che si connette solo a risorse specifiche, consentendo così di proteggersi dall'esfiltrazione di dati.

In questo scenario di esempio, sono presenti quattro endpoint privati associati alle opzioni PaaS di Azure e gestiti da una subnet nella rete virtuale di Azure Machine Learning, come illustrato nel diagramma dell'architettura. Di conseguenza, questi servizi sono accessibili solo alle risorse all'interno della stessa rete virtuale, rete virtuale di Azure Machine Learning. Questi servizi includono:

• Azure Machine Learning workspace (Area di lavoro di Azure Machine Learning)
• Archiviazione BLOB di Azure
• Registro Azure Container
• Azure Key Vault

Il frammento di codice Terraform seguente illustra come usare un endpoint privato per collegarsi a un'area di lavoro di Azure Machine Learning, che è più protetta dalla rete virtuale di conseguenza. Il frammento di codice mostra anche l'uso di una zona DNS privata, descritta in Zone DNS privato di Azure.

resource "azurerm_machine_learning_workspace" "aml_ws" {
  name                    = "my_aml_workspace"
  friendly_name           = "my_aml_workspace"
  location                = "eastasia"
  resource_group_name     = "my_resource_group"
  application_insights_id = azurerm_application_insights.my_ai.id
  key_vault_id            = azurerm_key_vault.my_kv.id
  storage_account_id      = azurerm_storage_account.my_sa.id
  container_registry_id   = azurerm_container_registry.my_acr_aml.id

  identity {
    type = "SystemAssigned"
  }
}

# Configure private DNS zones

resource "azurerm_private_dns_zone" "ws_zone_api" {
  name                = "privatelink.api.azureml.ms"
  resource_group_name = var.RESOURCE_GROUP
}

resource "azurerm_private_dns_zone" "ws_zone_notebooks" {
  name                = "privatelink.notebooks.azure.net"
  resource_group_name = var.RESOURCE_GROUP
}

# Link DNS zones to the virtual network

resource "azurerm_private_dns_zone_virtual_network_link" "ws_zone_api_link" {
  name                  = "ws_zone_link_api"
  resource_group_name   = "my_resource_group"
  private_dns_zone_name = azurerm_private_dns_zone.ws_zone_api.name
  virtual_network_id    = azurerm_virtual_network.aml_vnet.id
}

resource "azurerm_private_dns_zone_virtual_network_link" "ws_zone_notebooks_link" {
  name                  = "ws_zone_link_notebooks"
  resource_group_name   = "my_resource_group"
  private_dns_zone_name = azurerm_private_dns_zone.ws_zone_notebooks.name
  virtual_network_id    = azurerm_virtual_network.aml_vnet.id
}

# Configure private endpoints

resource "azurerm_private_endpoint" "ws_pe" {
  name                = "my_aml_ws_pe"
  location            = "eastasia"
  resource_group_name = "my_resource_group"
  subnet_id           = azurerm_subnet.my_subnet.id

  private_service_connection {
    name                           = "my_aml_ws_psc"
    private_connection_resource_id = azurerm_machine_learning_workspace.aml_ws.id
    subresource_names              = ["amlworkspace"]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "private-dns-zone-group-ws"
    private_dns_zone_ids = [azurerm_private_dns_zone.ws_zone_api.id, azurerm_private_dns_zone.ws_zone_notebooks.id]
  }

  # Add the private link after configuring the workspace
  depends_on = [azurerm_machine_learning_compute_instance.compute_instance, azurerm_machine_learning_compute_cluster.compute_cluster]
}

Il codice precedente per userà la piattaforma API v2 per azurerm_machine_learning_workspace impostazione predefinita. Se si desidera comunque usare l'API v1 o i criteri aziendali che impediscono l'invio di comunicazioni su reti pubbliche, è possibile abilitare il parametro v1_legacy_mode_enabled, come illustrato nel frammento di codice seguente. Se abilitato, questo parametro disabilita l'API v2 per l'area di lavoro.

resource "azurerm_machine_learning_workspace" "aml_ws" {
  ...
  public_network_access_enabled = false
  v1_legacy_mode_enabled  = true
}

Zone di DNS privato di Azure

DNS di Azure fornisce un servizio DNS più sicuro e affidabile per gestire e risolvere i nomi di dominio in una rete virtuale senza la necessità di aggiungere una soluzione DNS personalizzata. Usando le zone DNS privato, è possibile usare i propri nomi di dominio personalizzati anziché i nomi forniti da Azure. La risoluzione DNS in una zona DNS privato funziona solo da reti virtuali collegate.

Questa soluzione di esempio usa endpoint privati per l'area di lavoro di Azure Machine Learning e per le risorse associate, ad esempio Archiviazione di Azure, Azure Key Vault o Registro contenitori. Pertanto, è necessario configurare correttamente le impostazioni DNS per risolvere gli indirizzi IP degli endpoint privati dal nome di dominio completo (FQDN) della stringa di connessione.

È possibile collegare una zona DNS privato a una rete virtuale per risolvere domini specifici.

Il frammento terraform in collegamento privato e l'endpoint privato di Azure crea due zone DNS private usando i nomi di zona consigliati nella configurazione della zona DNS dei servizi di Azure:

• privatelink.api.azureml.ms
• privatelink.notebooks.azure.net

Peering reti virtuali

Il peering di rete virtuale consente l'accesso delle macchine virtuali jump-host (VM) o dell'agente self-hosted nella rete virtuale Azure Bastion alle risorse nella rete virtuale di Azure Machine Learning. Per facilitare la connettività, le due reti virtuali funzionano come una sola. Il traffico tra le macchine virtuali e le risorse di Azure Machine Learning nelle reti virtuali con peering usa l'infrastruttura backbone di Azure. Il traffico tra le reti virtuali viene instradato attraverso la rete privata di Azure.

Il frammento di codice Terraform seguente configura il peering di rete virtuale tra la rete virtuale di Azure Machine Learning e la rete virtuale Azure Bastion.

# Virtual network peering for AML VNET and BASTION VNET
resource "azurerm_virtual_network_peering" "vp_amlvnet_basvnet" {
  name                      = "vp_amlvnet_basvnet"
  resource_group_name       = "my_resource_group"
  virtual_network_name      = azurerm_virtual_network.amlvnet.name
  remote_virtual_network_id = azurerm_virtual_network.basvnet.id
  allow_virtual_network_access = true
  allow_forwarded_traffic      = true
}

resource "azurerm_virtual_network_peering" "vp_basvnet_amlvnet" {
  name                      = "vp_basvnet_amlvnet"
  resource_group_name       = "my_resource_group"
  virtual_network_name      = azurerm_virtual_network.basvnet.name
  remote_virtual_network_id = azurerm_virtual_network.amlvnet.id
  allow_virtual_network_access = true
  allow_forwarded_traffic      = true
}

Accedere alle risorse nella rete virtuale

Per accedere all'area di lavoro di Azure Machine Learning in una rete virtuale, ad esempio la rete virtuale di Azure Machine Learning in questo scenario, usare uno dei metodi seguenti:

• Gateway VPN di Azure
• Azure ExpressRoute
• Azure Bastion e la macchina virtuale host di salto

Per maggiori informazioni, consultare la sezione Connessione all'area di lavoro.

Eseguire Azure Pipelines che accede alle risorse nella rete virtuale

Azure Pipelines compila e testa automaticamente i progetti di codice e li mette a disposizione di altri utenti. Azure Pipelines combina CI/CD per testare e compilare il codice e inviarlo a qualsiasi destinazione.

Agenti ospitati in Azure e agenti self-hosted

La soluzione MLOps in questo scenario di esempio è costituita da due pipeline, che possono attivare pipeline di Azure Machine Learning e accedere alle risorse associate. Poiché l'area di lavoro di Azure Machine Learning e la risorsa associata si trovano in una rete virtuale, questo scenario deve fornire un modo per consentire a un agente di Azure Pipelines di accedervi. Un agente sta elaborando l'infrastruttura con software agente installato che esegue processi di Azure Pipelines uno alla volta. Esistono diversi modi per implementare l'accesso:

• Usare agenti self-hosted nella stessa rete virtuale o nella rete virtuale di peering, come illustrato nel diagramma dell'architettura.

• Usare gli agenti ospitati in Azure e aggiungere gli intervalli di indirizzi IP a un elenco di indirizzi consentiti nelle impostazioni del firewall dei servizi di Azure di destinazione.

• Usare gli agenti ospitati da Azure (come client VPN) e Gateway VPN.

Ognuna di queste scelte presenta vantaggi e svantaggi. La tabella seguente confronta gli agenti ospitati in Azure con gli agenti self-hosted.

In base ai confronti nella tabella e alle considerazioni sulla sicurezza e sulla complessità, questo scenario di esempio usa un agente self-hosted per Azure Pipelines per attivare le pipeline di Azure Machine Learning nella rete virtuale.

Per configurare un agente self-hosted, sono disponibili le opzioni seguenti:

• Installare l'agente sulle VM di Azure.

• Installare gli agenti in un set di scalabilità di macchine virtuali di Azure, che può essere ridimensionato automaticamente per soddisfare la domanda.

• Installare l'agente in un contenitore Docker. Questa opzione non è fattibile, perché questo scenario potrebbe richiedere l'esecuzione del contenitore Docker all'interno dell'agente per il training del modello di Machine Learning.

Il codice di esempio seguente effettua il provisioning di due agenti self-hosted creando macchine virtuali e estensioni di Azure:

resource "azurerm_linux_virtual_machine" "agent" {
  ...
}

resource "azurerm_virtual_machine_extension" "update-vm" {
  count                = 2
  name                 = "update-vm${format("%02d", count.index)}"
  publisher            = "Microsoft.Azure.Extensions"
  type                 = "CustomScript"
  type_handler_version = "2.1"
  virtual_machine_id   = element(azurerm_linux_virtual_machine.agent.*.id, count.index)

  settings = <<SETTINGS
    {
        "script": "${base64encode(templatefile("../scripts/terraform/agent_init.sh", {
          AGENT_USERNAME      = "${var.AGENT_USERNAME}",
          ADO_PAT             = "${var.ADO_PAT}",
          ADO_ORG_SERVICE_URL = "${var.ADO_ORG_SERVICE_URL}",
          AGENT_POOL          = "${var.AGENT_POOL}"
        }))}"
    }
SETTINGS
}

Come illustrato nel blocco di codice precedente, lo script Terraform chiama agent_init.sh, illustrato nel blocco di codice seguente, per installare il software agente e le librerie necessarie nella macchina virtuale dell'agente in base ai requisiti del cliente.

#!/bin/sh
# Install other required libraries 
...

# Creates directory and downloads Azure DevOps agent installation files
# Find more agent versions at https://github.com/microsoft/azure-pipelines-agent/releases
AGENT_VERSION="3.240.1"
sudo mkdir /myagent 
cd /myagent
sudo wget https://vstsagentpackage.azureedge.net/agent/${AGENT_VERSION}/vsts-agent-linux-x64-${AGENT_VERSION}.tar.gz
sudo tar zxvf ./vsts-agent-linux-x64-${AGENT_VERSION}.tar.gz
sudo chmod -R 777 /myagent

# Unattended installation
sudo runuser -l ${AGENT_USERNAME} -c '/myagent/config.sh --unattended  --url ${ADO_ORG_SERVICE_URL} --auth pat --token ${ADO_PAT} --pool ${AGENT_POOL}'

cd /myagent
#Configure as a service
sudo ./svc.sh install ${AGENT_USERNAME}
#Start service
sudo ./svc.sh start

Usare il registro contenitori nella rete virtuale

Esistono alcuni prerequisiti per la protezione di un'area di lavoro di Azure Machine Learning in una rete virtuale. Per altre informazioni, consulta Prerequisiti. Registro contenitori è un servizio obbligatorio quando si usa un'area di lavoro di Azure Machine Learning per eseguire il training e la distribuzione dei modelli.

In questo scenario di esempio, per assicurarsi che l'agente self-hosted possa accedere al registro contenitori nella rete virtuale, si usa il peering di rete virtuale e si aggiunge un collegamento di rete virtuale per collegare la zona DNS privata, privatelink.azurecr.io, alla rete virtuale Azure Bastion. Il frammento di codice Terraform seguente mostra l'implementazione.

# Azure Machine Learning Container Registry is for private access 
# by the Azure Machine Learning workspace
resource "azurerm_container_registry" "acr" {
  name                     = "my_acr"
  resource_group_name      = "my_resource_group"
  location                 = "eastasia"
  sku                      = "Premium"
  admin_enabled            = true
  public_network_access_enabled = false
}

resource "azurerm_private_dns_zone" "acr_zone" {
  name                     = "privatelink.azurecr.io"
  resource_group_name      = "my_resource_group"
}

resource "azurerm_private_dns_zone_virtual_network_link" "acr_zone_link" {
  name                  = "link_acr"
  resource_group_name   = "my_resource_group"
  private_dns_zone_name = azurerm_private_dns_zone.acr_zone.name
  virtual_network_id    = azurerm_virtual_network.amlvnet.id
}

resource "azurerm_private_endpoint" "acr_ep" {
  name                = "acr_pe"
  resource_group_name = "my_resource_group"
  location            = "eastasia"
  subnet_id           = azurerm_subnet.aml_subnet.id

  private_service_connection {
    name                           = "acr_psc"
    private_connection_resource_id = azurerm_container_registry.acr.id
    subresource_names              = ["registry"]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "private-dns-zone-group-app-acr"
    private_dns_zone_ids = [azurerm_private_dns_zone.acr_zone.id]
  }
}

Questo scenario di esempio garantisce anche che il registro contenitori abbia un ruolo Collaboratore per l'identità gestita assegnata dal sistema dell'area di lavoro di Azure Machine Learning.

Usare un cluster di calcolo o un'istanza nella rete virtuale

Un cluster di calcolo o un'istanza di Azure Machine Learning in una rete virtuale richiede un gruppo di sicurezza di rete con alcune regole specifiche per la subnet. Per un elenco di tali regole, consultare la sezione Limitazioni.

Si noti anche che per il cluster di calcolo o l'istanza è ora possibile rimuovere l'indirizzo IP pubblico, che consente di garantire una migliore protezione per le risorse di calcolo nella soluzione MLOps. Per maggiori informazioni, consultare la sezione Nessun indirizzo IP pubblico per le istanze di ambiente di calcolo (anteprima).

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Gary Wang | Principal Software Engineer

Altri contributori:

• Gary Moore | Programmatore/writer

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Documentazione di Terraform in Azure
• Esempi di Terraform per Azure Machine Learning Enterprise
• Repository GitHub di Azure MLOps v2
• Prezzi della rete virtuale di Azure
• Prezzi per Azure DevOps

Risorse correlate

• Proteggere un'area di lavoro di Azure Machine Learning con reti virtuali
• Agenti di Azure Pipelines