Federazione delle identità del carico di lavoro

Questo articolo offre una panoramica della federazione delle identità del carico di lavoro per i carichi di lavoro software. L'uso della federazione delle identità del carico di lavoro consente di accedere alle risorse protette di Microsoft Entra senza dover gestire i segreti (per scenari supportati).

È possibile usare la federazione delle identità del carico di lavoro in scenari come GitHub Actions, carichi di lavoro in esecuzione in Kubernetes o carichi di lavoro in esecuzione nelle piattaforme di calcolo all'esterno di Azure.

Perché usare la federazione delle identità del carico di lavoro?

Guardare questo video per scoprire perché usare la federazione delle identità del carico di lavoro.

In genere, un carico di lavoro software (ad esempio un'applicazione, un servizio, uno script o un'applicazione basata su contenitori) richiede un'identità per autenticare e accedere alle risorse o comunicare con altri servizi. Quando questi carichi di lavoro vengono eseguiti in Azure, è possibile usare le identità gestite e la piattaforma Azure gestisce automaticamente le credenziali. Per un carico di lavoro software in esecuzione all'esterno di Azure, o quelli che vengono eseguiti in Azure ma utilizzano le registrazioni delle app per le loro identità, è richiesto usare le credenziali dell'applicazione (come un segreto o un certificato) per accedere alle risorse protette di Microsoft Entra (ad esempio Azure, Microsoft Graph, Microsoft 365 o risorse di terze parti). Queste credenziali rappresentano un rischio per la sicurezza e devono essere archiviate in modo sicuro e ruotato regolarmente. Se le credenziali scadono, si corre anche il rischio di tempi di inattività del servizio.

Si usa la federazione dell'identità del carico di lavoro per configurare un'identità gestita assegnata dall'utente o la registrazione dell'app in Microsoft Entra ID per considerare attendibili i token da un provider di identità esterno (IdP), ad esempio GitHub o Google. L'identità gestita assegnata dall'utente o la registrazione dell'app in Microsoft Entra ID diventa un'identità per i carichi di lavoro software in esecuzione, ad esempio nei flussi di lavoro Kubernetes o GitHub Actions locali. Dopo aver creato la relazione di trust, il carico di lavoro del software esterno scambia token attendibili dal provider di identità esterno per i token di accesso da Microsoft Identity Platform. Il carico di lavoro software usa tale token di accesso per accedere alle risorse protette di Microsoft Entra a cui è stato concesso l'accesso al carico di lavoro. Si elimina il carico di manutenzione della gestione manuale delle credenziali ed elimina il rischio di perdita di segreti o di scadenza dei certificati.

Scenari supportati

Per accedere alle risorse protette di Microsoft Entra tramite la federazione delle identità del carico di lavoro sono supportati gli scenari seguenti:

• Carichi di lavoro in esecuzione in qualsiasi cluster Kubernetes (servizio Azure Kubernetes), Amazon Web Services EKS, Google Kubernetes Engine (GKE) o locale. Stabilire una relazione di trust tra l'identità gestita assegnata dall'utente o l'app in Microsoft Entra ID e un carico di lavoro Kubernetes (descritto nella panoramica dell'identità del carico di lavoro).
• GitHub Actions. Prima di tutto, configurare una relazione di trust tra l'identità gestita assegnata dall'utente o l'applicazione in Microsoft Entra ID e un repository GitHub nell'interfaccia di amministrazione di Microsoft Entra o usando Microsoft Graph. Configurare quindi un flusso di lavoro di GitHub Actions per ottenere un token di accesso dal provider di identità Microsoft e accedere alle risorse di Azure.
• Carichi di lavoro in esecuzione su piattaforme di calcolo di Azure usando le identità delle app. Assegnare prima di tutto un'identità gestita assegnata dall'utente alla macchina virtuale di Azure o al servizio app. Quindi, configurare un rapporto di fiducia tra l'app e l'identità assegnata dall'utente.
• Google Cloud. Prima di tutto, configurare una relazione di trust tra l'identità gestita assegnata dall'utente o l'app in Microsoft Entra ID e un'identità in Google Cloud. Configurare quindi il carico di lavoro software in esecuzione in Google Cloud per ottenere un token di accesso dal provider di identità Microsoft e accedere alle risorse protette di Microsoft Entra. Vedere Accedere alle risorse protette di Microsoft Entra da un'app in Google Cloud.
• Carichi di lavoro in esecuzione in Amazon Web Services (AWS). Prima di tutto, configurare una relazione di trust tra l'identità gestita assegnata dall'utente o l'app in Microsoft Entra ID e un'identità in Amazon Cognito. Configurare quindi il carico di lavoro software in esecuzione in AWS per ottenere un token di accesso dal provider di identità Microsoft e accedere alle risorse protette di Microsoft Entra. Vedere Federazione dell'identità del carico di lavoro con AWS.
• Altri carichi di lavoro in esecuzione in piattaforme di calcolo all'esterno di Azure. Configurare una relazione di trust tra l'identità gestita o l'applicazione assegnata dall'utente in Microsoft Entra ID e l'IDP esterno per la piattaforma di calcolo. È possibile usare i token rilasciati da tale piattaforma per eseguire l'autenticazione con Microsoft Identity Platform e chiamare le API nell'ecosistema Microsoft. Usare il flusso delle credenziali client per ottenere un token di accesso da Microsoft Identity Platform, passando il token JWT del provider di identità anziché crearne uno usando un certificato archiviato.
• SPIFFE e SPIRE sono un set di standard open source indipendenti dalla piattaforma per fornire identità ai carichi di lavoro software distribuiti tra piattaforme e fornitori di cloud. Prima di tutto, configurare una relazione di trust tra l'identità gestita assegnata dall'utente o l'app in Microsoft Entra ID e un ID SPIFFE per un carico di lavoro esterno. Configurare quindi il carico di lavoro software esterno per ottenere un token di accesso dal provider di identità Microsoft e accedere alle risorse protette di Microsoft Entra. Vedere Federazione delle identità del carico di lavoro con SPIFFE e SPIRE.
• Creare una nuova connessione al servizio in Azure Pipelines (anteprima). Creare una connessione al servizio Azure Resource Manager usando la federazione dell'identità del carico di lavoro.

Funzionamento

Creare una relazione di trust tra il provider di identità esterno e un'identità gestita assegnata dall'utente o un'applicazione in Microsoft Entra ID. La credenziale dell'identità federata viene usata per indicare quale token dal provider di identità esterno deve essere considerato attendibile dall'applicazione o dall'identità gestita. Si configura un'identità federata:

• In un'identità gestita assegnata dall'utente tramite l'interfaccia di amministrazione di Microsoft Entra, l'interfaccia della riga di comando di Azure, Azure PowerShell, Azure SDK e i modelli di Azure Resource Manager (ARM). Il carico di lavoro esterno usa il token di accesso per accedere alle risorse protette di Microsoft Entra senza dover gestire i segreti (in scenari supportati). I passaggi per la configurazione della relazione di trust variano a seconda dello scenario e dell'IdP esterno.
• In una registrazione dell'app nell'interfaccia di amministrazione di Microsoft Entra o tramite Microsoft Graph. Questa configurazione consente di ottenere un token di accesso per l'applicazione senza dover gestire i segreti all'esterno di Azure. Per ulteriori informazioni, scopri come configurare un'app per affidarsi a un provider di identità esterno e come configurare l'affidabilità tra un'app e un'identità gestita assegnata all'utente .

Il flusso di lavoro per lo scambio di un token esterno per un token di accesso è lo stesso, tuttavia, per tutti gli scenari. Il diagramma seguente illustra il flusso di lavoro generale di un carico di lavoro che scambia un token esterno per un token di accesso e quindi accede alle risorse protette di Microsoft Entra.

1. Il carico di lavoro esterno (ad esempio un flusso di lavoro di GitHub Actions) richiede un token dal provider di identità esterno (ad esempio GitHub).
2. Il provider di identità esterno rilascia un token al carico di lavoro esterno.
3. Il carico di lavoro esterno (l'azione di accesso in un flusso di lavoro GitHub, ad esempio) invia il token a Microsoft Identity Platform e richiede un token di accesso.
4. Microsoft Identity Platform controlla la relazione di trust nell'identità gestita assegnata dall'utente o nella registrazione dell'app e convalida il token esterno rispetto all'URL dell'autorità di certificazione OIDC (OpenID Connect) nell'IDP esterno.
5. Quando i controlli vengono soddisfatti, Microsoft Identity Platform rilascia un token di accesso al carico di lavoro esterno.
6. Il carico di lavoro esterno accede alle risorse protette di Microsoft Entra usando il token di accesso da Microsoft Identity Platform. Un flusso di lavoro di GitHub Actions, ad esempio, usa il token di accesso per pubblicare un'app Web in app Azure Servizio.

Microsoft Identity Platform archivia solo le prime 100 chiavi di firma quando vengono scaricate dall'endpoint OIDC dell'IdP esterno. Se il provider di identità esterno espone più di 100 chiavi di firma, è possibile che si verifichino errori quando si usa la federazione dell'identità del carico di lavoro.

Vedere anche

• Come creare, eliminare, recuperare o aggiornare le credenziali di identità federate su un'identità gestita assegnata dall'utente o le credenziali di identità federate su una registrazione dell'app.
• Configurare un'identità gestita assegnata dall'utente come credenziale di identità federata nella registrazione di un'app.
• Leggere la panoramica dell'identità del carico di lavoro per informazioni su come configurare un carico di lavoro Kubernetes per ottenere un token di accesso dal provider di identità Microsoft e accedere alle risorse protette di Microsoft Entra.
• Leggere la documentazione di GitHub Actions per altre informazioni sulla configurazione del flusso di lavoro di GitHub Actions per ottenere un token di accesso dal provider di identità Microsoft e accedere alle risorse protette di Microsoft Entra.
• Come Microsoft Entra ID usa la concessione di credenziali client OAuth 2.0 e un'asserzione client rilasciata da un altro IdP per ottenere un token.
• Per informazioni sul formato richiesto di JWT creati da provider di identità esterni, vedere il formato di asserzione.