Sugli accessi la domanda ricorrente non è «chi ha cliccato», ma «quale identità sta parlando con lo storage». È una distinzione che in data science si può ignorare per mesi e che in produzione si paga subito: un job che funziona dal notebook di chi l’ha scritto e fallisce con un errore di autorizzazione quando lo lancia la pipeline notturna è quasi sempre un problema di identità del compute, non di codice. La seconda metà del lavoro è decidere da dove ci si arriva, al workspace e dal workspace.

Tre identità da non confondere

Il provider di identità è Microsoft Entra ID, e nel giro ci sono tre soggetti distinti.

Il primo è l’identità del workspace: una managed identity system-assigned con lo stesso nome della risorsa, usata per l’autenticazione servizio-a-servizio verso le risorse associate — Contributor sul workspace, Storage Blob Data Contributor sullo storage account, accesso a chiavi, segreti e certificati del key vault, Contributor sul container registry. Nessun utente può usare quel token. Fatto d’esame: per i workspace creati dopo il 19 novembre 2024 questa identità riceve sul resource group il ruolo Azure AI Administrator invece di Contributor, perché più stretto; un workspace più vecchio si converte con az ml workspace update --allow-roleassignment-on-rg true. In alternativa il workspace può usare una user-assigned managed identity.

Il secondo è l’identità del compute, ed è il nodo. La managed identity di un compute cluster è indipendente da quella del workspace ed esiste per accedere a risorse — tipicamente datastore protetti — a cui chi sottomette il job potrebbe non avere accesso. Quando progetti i permessi per una pipeline automatizzata, i ruoli sui dati vanno all’identità che esegue, non a chi preme il pulsante. Assegnare una user-assigned identity a un cluster richiede permessi di scrittura sul compute più il ruolo Managed Identity Operator sull’identità stessa.

Il terzo è l’identità dell’utente o del service principal che chiama le API, quella su cui si assegnano i ruoli del workspace. Due eccezioni escono dal recinto di Entra ID e RBAC: l’accesso SSH ai compute usa coppie di chiavi, e gli online endpoint si autenticano con chiave, con token di Azure Machine Learning oppure con token Entra.

Ruoli integrati e ruoli personalizzati

I ruoli predefiniti del workspace sono cinque. AzureML Data Scientist fa tutto dentro il workspace tranne creare o eliminare compute e modificare il workspace stesso. AzureML Compute Operator crea, gestisce, elimina e usa i compute. Reader, Contributor e Owner sono i ruoli Azure generici; per i registry esiste in più AzureML Registry User. Si combinano: Data Scientist più Compute Operator dà una persona autonoma che si crea il proprio cluster. Attenzione a Reader: la documentazione dice che può elencare gli asset incluse le credenziali dei datastore, quindi non è un ruolo neutro da dare a chi vuole «solo guardare».

Quando i ruoli integrati non bastano si scrive un ruolo custom come definizione JSON con Name, IsCustom, Actions, NotActions e AssignableScopes, e lo si crea con az role definition create --role-definition ruolo.json. Il pattern tipico è concedere tutto sul workspace e togliere in NotActions la creazione o cancellazione dei compute e le azioni di Microsoft.Authorization. Due trappole: le action di v1 e v2 hanno percorsi diversi — workspaces/experiments contro workspaces/jobs, workspaces/modules contro workspaces/components — quindi un ruolo scritto per la v1 non copre la v2 senza wildcard; e le operazioni sulle quote richiedono permessi a livello di sottoscrizione, non di workspace.

Sul piano operativo: assegna i ruoli a gruppi di sicurezza Entra invece che a singoli utenti, così deleghi la gestione ai group owner ed eviti di avvicinarti al limite di role assignment della sottoscrizione. E metti in conto la latenza: l’aggiornamento di un ruolo custom può impiegare da 15 minuti a un’ora, e i permessi in cache restano validi fino a un’ora. Chi debugga un 403 subito dopo aver corretto un ruolo spesso sta guardando la cache.

Chiudere la rete: managed virtual network e private endpoint

I due meccanismi di rete rispondono a direzioni diverse. La managed virtual network di Azure Machine Learning protegge il traffico in uscita dal workspace e dai compute gestiti — serverless, cluster, compute instance, managed online endpoint, batch endpoint. Una Azure Virtual Network tua, con un private endpoint verso il workspace, protegge l’accesso in entrata: i client si collegano al workspace dalla rete privata. I due approcci si usano insieme, non in alternativa.

La managed virtual network ha tre modalità di isolamento: allow_internet_outbound, allow_only_approved_outbound e disabled. Le transizioni non sono libere: da allow_internet_outbound non si torna a disabled, e da allow_only_approved_outbound non si torna a allow_internet_outbound. È una decisione di architettura, non un interruttore.

# workspace.yml
managed_network:
  isolation_mode: allow_only_approved_outbound
  outbound_rules:
    - name: pypi
      destination: 'pypi.org'
      type: fqdn

Le regole di uscita sono di tre tipi: service_tag, fqdn e private_endpoint. Service tag e FQDN valgono solo in modalità approved-outbound, e le regole FQDN sono implementate con Azure Firewall, quindi aggiungono un costo. La rete gestita non nasce subito: il provisioning è differito al primo compute, con un’attesa dichiarata di circa 30 minuti, o si forza con az ml workspace provision-network o --provision-network-now. Ordine importante: disabilita l’accesso pubblico prima di provisionare la rete gestita, altrimenti i private endpoint del workspace potrebbero non venire creati automaticamente. Azure Policy rende infine obbligatoria la configurazione, per esempio imponendo il private endpoint su ogni workspace.

Da ricordare per l esame

  • L’identità che deve avere i permessi sui dati è quella del compute che esegue il job, non quella di chi lo sottomette.
  • Dal 19 novembre 2024 la managed identity system-assigned del workspace riceve Azure AI Administrator sul resource group al posto di Contributor.
  • Reader può leggere le credenziali dei datastore; AzureML Data Scientist non può creare compute; AzureML Compute Operator sì.
  • Managed virtual network protegge il traffico in uscita dai compute gestiti; un private endpoint in una tua virtual network protegge l’accesso in entrata al workspace.
  • Le modalità sono allow_internet_outbound, allow_only_approved_outbound e disabled, e alcune transizioni sono irreversibili; le regole fqdn e service_tag funzionano solo in approved-outbound.