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 rete virtuale 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 dei modelli: 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 di training di Machine Learning
• Pipeline di apprendimento automatico
• Modelli di Machine Learning

Per proteggere le risorse, considerare questi metodi:

• Autenticazione e autorizzazione

  • Usare entità servizio o identità gestite anziché l'autenticazione interattiva.
  • Usare 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 altre informazioni, vedere What is the new API platform on Azure Resource Manager (Informazioni sulla 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 raccogliere e aggregare dati , ad esempio metriche e log, da varie origini in una piattaforma dati comune per l'analisi, la visualizzazione e gli 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 offre una posizione centralizzata per lavorare con tutti gli artefatti creati quando si usa Azure Machine Learning.

Quando si crea una nuova area di lavoro, vengono create automaticamente le risorse di Azure seguenti 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 set di principi guida che migliorano la qualità di un carico di lavoro quando applicato. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Sicurezza

La sicurezza offre maggiori garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della 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 Panoramica del pilastro di 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 altre informazioni, vedere Panoramica del pilastro dell'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. Rete virtuale consente a molti tipi di risorse di Azure di comunicare in modo più sicuro tra loro, internet e 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 e endpoint privato di Azure

collegamento privato consente l'accesso tramite un endpoint privato nella rete virtuale alle opzioni PaaS (Platform as a Service), ad esempio un'area di lavoro di Azure Machine Learning e Archiviazione di Azure e ai servizi di proprietà dei clienti ospitati in Azure e di proprietà del partner. 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 sono:

• 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 vuole comunque usare l'API v1 o i criteri aziendali che impediscono l'invio di comunicazioni su reti pubbliche, è possibile abilitare il v1_legacy_mode_enabled parametro , 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 offre un servizio DNS affidabile e più sicuro 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 private, è possibile usare nomi di dominio personalizzati anziché i nomi forniti da Azure. La risoluzione DNS in una zona DNS privata 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 le impostazioni DNS per risolvere gli indirizzi IP degli endpoint privati dal nome di dominio completo (FQDN) del stringa di connessione.

È possibile collegare una zona DNS privata 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. Ai fini della connettività, le due reti virtuali funzionano come una sola. Il traffico tra macchine virtuali e 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 jump host

Per altre informazioni, vedere Connettersi 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 spedirlo 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 in Azure Macchine virtuali.

• 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 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 Container è 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 terraform seguente illustra 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, vedere 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 altre informazioni, vedere Nessun indirizzo IP pubblico per le istanze di calcolo.

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
• Acceleratore di soluzioni Azure MLOps (v2)
• Prezzi di Azure Rete virtuale
• Prezzi per Azure DevOps

Risorse correlate

• Framework delle operazioni di Machine Learning (MLOps) per migliorare il ciclo di vita di Machine Learning con Azure Machine Learning
• Proteggere un'area di lavoro di Azure Machine Learning con reti virtuali
• Agenti di Azure Pipelines