Gestisci un set di scalabilità di macchine virtuali (VM scale set) e più Function App che devono accedere ad Azure Key Vault e ad Azure Storage con un'identità comune e riutilizzabile tra risorse e regioni. L'identità deve sopravvivere a qualsiasi singola risorsa. I carichi di lavoro devono anche ottenere token OAuth per chiamare un'API partner che si fida di Entra ID, senza archiviare segreti. Cosa dovresti fare? Ogni risposta corretta presenta una parte della soluzione.

La creazione di un'identità gestita assegnata dall'utente (user-assigned managed identity) è la soluzione corretta perché consente di avere un'identità comune e riutilizzabile tra più risorse (VM scale set e Function App) e regioni, che sopravvive alla singola risorsa. Assegnando i ruoli "Key Vault Secrets User" e "Storage Blob Data Contributor" a questa identità, si garantisce l'accesso necessario a Key Vault e Storage. Le identità gestite assegnate dal sistema non sono riutilizzabili tra risorse e non sopravvivono alla risorsa. Richiedere i token per l'API partner tramite l'endpoint dell'identità gestita (IMDS o endpoint del token di App Service) è corretto perché le identità gestite possono ottenere token OAuth per chiamare API protette da Entra ID senza la necessità di archiviare segreti. Una registrazione dell'app con un client secret richiederebbe la gestione e l'archiviazione di segreti, che la domanda cerca di evitare. L'API Azure AD Graph è obsoleta e non è la scelta appropriata per questo scenario.