Nelle applicazioni cloud il problema più ricorrente non è “come autenticarsi”, ma “dove metto le credenziali senza doverle ruotare a mano”. Le managed identity risolvono esattamente questo: forniscono a una risorsa Azure un’identità in Microsoft Entra ID gestita interamente dalla piattaforma, senza segreti da custodire nel codice o nella configurazione.

Cos’è davvero una managed identity

Una managed identity è un tipo particolare di service principal, creato e mantenuto automaticamente da Azure. La differenza chiave rispetto a un service principal “classico” (quello generato da un app registration) è che non ha credenziali gestibili dall’utente: niente client secret né certificato da rinnovare. Azure si occupa da solo di emettere e ruotare le credenziali sottostanti.

Il flusso è coerente con il modello OAuth 2.0 client credentials: la risorsa (una VM, una Function App, un Container App) richiede un token a Entra ID tramite l’endpoint dell’Instance Metadata Service (IMDS) o le variabili d’ambiente iniettate dal runtime, e usa quel token come Bearer per chiamare qualsiasi servizio che accetti l’autenticazione Entra: Azure Key Vault, Azure Storage, Azure SQL, Microsoft Graph, e così via. Il pattern si chiama workload identity: l’identità è del carico di lavoro, non di una persona.

System-assigned vs user-assigned

La scelta architetturale centrale dell’esame è tra i due tipi di managed identity.

  • System-assigned: creata e legata al ciclo di vita di una singola risorsa. Attivandola su una VM, Azure genera un service principal dedicato a quella VM. È 1:1 — una sola risorsa la usa — e viene eliminata automaticamente quando la risorsa viene cancellata. Ideale quando l’identità serve a un solo componente e non deve sopravvivergli.

  • User-assigned: è una risorsa Azure autonoma, creata separatamente e con un proprio ciclo di vita. Può essere assegnata a più risorse contemporaneamente (relazione N:1) e continua a esistere anche se le risorse a cui è collegata vengono eliminate. È la scelta giusta quando più servizi devono condividere gli stessi permessi, o quando si vuole assegnare l’accesso prima di creare la risorsa (utile in pipeline IaC per evitare il problema dell’uovo e la gallina sui permessi RBAC al primo deploy).

Regola pratica: componente singolo e usa-e-getta → system-assigned; flotta di risorse con permessi uniformi o pre-provisioning → user-assigned.

Quando preferirle a un app registration con secret

Un app registration con client secret è ancora necessario per scenari come autenticazione di app multi-tenant, applicazioni che girano fuori da Azure (on-prem o altro cloud), o flussi utente-interattivi. Ma quando il carico gira dentro Azure e deve accedere a risorse Azure, la managed identity è quasi sempre preferibile:

  • zero secret in configurazione → nessun segreto che scade, trapela o finisce in un repository;
  • nessuna rotazione manuale → gestita da Azure;
  • superficie d’attacco ridotta → nessuna credenziale esfiltrabile.

Assegnare i permessi con Azure RBAC

Creare la managed identity non concede alcun accesso: l’identità nasce senza permessi. Occorre assegnarle esplicitamente un ruolo Azure RBAC sullo scope corretto (subscription, resource group o singola risorsa). Ad esempio, per far leggere segreti da un Key Vault (in modello RBAC) si assegna Key Vault Secrets User al principal della managed identity.

az role assignment create \
  --assignee-object-id <managed-identity-principal-id> \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope <resource-id>

Vale il principio del least privilege: assegnare il ruolo più stretto sullo scope più ristretto possibile.

Trappole tipiche d’esame

  • Scenario: elimini una VM con system-assigned identity a cui erano stati dati ruoli RBAC → l’identità viene distrutta insieme alla VM e le assegnazioni di ruolo diventano orfane. Se l’identità deve sopravvivere alla risorsa, usa user-assigned.
  • Scenario: più App Service devono accedere allo stesso Key Vault con permessi identici → user-assigned condivisa (una sola assegnazione RBAC da gestire), non tante system-assigned.
  • Scenario: hai abilitato la managed identity ma l’app riceve 403 Forbidden → manca l’assegnazione del ruolo Azure RBAC; abilitare l’identità non basta, va concesso l’accesso esplicitamente.
  • Scenario: app SaaS multi-tenant o servizio ospitato fuori da Azure → la managed identity non è utilizzabile, serve un app registration con credenziali.
  • Scenario: devi assegnare i permessi prima che la risorsa esista (deploy IaC) → user-assigned, che è creabile e assegnabile in modo indipendente dal ciclo di vita della risorsa target.