Usare entità servizio e identità gestite in Azure DevOps

Servizi di Azure DevOps

Usare un'entità servizio di Microsoft Entra o un'identità gestita per l'automazione di Azure DevOps che viene eseguita senza l'intervento di un utente. Queste identità dell'applicazione non sono associate a un account dipendente e acquisiscono token di accesso di breve durata Microsoft Entra invece di token di accesso personali .

Le identità gestite e le entità servizio hanno requisiti di gestione delle credenziali diversi:

Preferire un'identità gestita per un carico di lavoro ospitato in Azure. Per un'entità servizio, è preferibile usare la federazione delle identità del carico di lavoro o un certificato invece di un segreto client quando l'ambiente di hosting lo supporta.

Comprendere le identità delle applicazioni

Principali del servizio

Un'entità servizio è la rappresentazione locale di un'applicazione in un tenant Microsoft Entra. La registrazione di un'applicazione crea un'entità servizio nel tenant di origine. Un'applicazione multi-tenant può anche avere un'entità di servizio in ciascun tenant che fornisce il consenso all'applicazione.

Un'entità servizio può autenticarsi tramite:

• Credenziali di identità federate, se supportate dalla piattaforma di hosting.
• Un certificato.
• Un segreto del client, che deve essere archiviato e ruotato in modo sicuro.

Identità gestite

Un'identità gestita è un tipo speciale di entità servizio le cui credenziali Azure gestisce.

• Un'identità gestita assegnata dal sistema appartiene a una risorsa Azure e viene eliminata con tale risorsa.
• Un'identità gestita assegnata dall'utente è una risorsa Azure separata che può essere assegnata a più risorse e gestita in modo indipendente.

Prerequisiti

• Un'organizzazione Azure DevOps connessa a un tenant di Microsoft Entra.
• Un'entità servizio principale o un'identità gestita nel tenant collegato all'organizzazione.
• Autorizzazione per aggiungere utenti all'organizzazione. Un membro di Project Collection Administrators può aggiungere un'identità. Un progetto o un amministratore del team può aggiungere un'identità quando i criteri di invito lo consentono.
• Autorizzazioni e livello di accesso necessari per le risorse Azure DevOps a cui accede l'identità.

Creare un'identità

Scegliere il tipo di identità corrispondente all'ambiente di hosting del carico di lavoro.

Creare un'entità servizio

1. Nella Interfaccia di amministrazione di Microsoft Entra selezionare Registrazioni app>Nuova registrazione.
2. Immettere un nome descrittivo e selezionare il tipo di account supportato per l'applicazione.
3. Lasciare vuoto l'URI di reindirizzamento per un'applicazione da servizio a servizio.
4. Aggiungere una credenziale o un certificato di identità federata. Creare un segreto del client solo quando il workload non può usare una credenziale più sicura.

Per altre informazioni, vedere Oggetti applicazione e entità servizio e Creare un'entità servizio.

Creare un'identità gestita

Per abilitare un'identità gestita assegnata dal sistema:

1. Nel portale di Azure aprire la risorsa Azure che ospita il carico di lavoro.
2. Selezionare Identità>.
3. Impostare Statosu Sì e quindi selezionare Salva.

Per creare e assegnare un'identità gestita assegnata dall'utente:

1. Nel portale di Azure creare una risorsa identità gestita.
2. Aprire la risorsa Azure che ospita il carico di lavoro.
3. Selezionare Identità>assegnata dall'utente>Aggiungi.
4. Selezionare l'identità gestita e quindi selezionare Aggiungi.

Per altre informazioni, vedere Gestire le identità gestite assegnate dall'utente.

Aggiungere l'identità a Azure DevOps

È necessario aggiungere esplicitamente un'identità applicativa a ogni organizzazione di Azure DevOps a cui accede. Aggiungere l'identità solo a un gruppo di Microsoft Entra non la rende disponibile in Azure DevOps.

1. In Azure DevOps selezionare Impostazioni organizzazione>Utenti.

2. Selezionare Aggiungi utenti.

3. Specificare il nome visualizzato dell'entità servizio o dell'identità gestita.

4. Selezionare il livello di accesso e i progetti necessari. Per accedere ad Azure Repos è necessario il livello di accesso Basic o superiore. I vantaggi dell'abbonamento a Visual Studio non si applicano alle identità applicative.

5. Seleziona Aggiungi. Azure DevOps non invia un messaggio di posta elettronica di invito a un'identità dell'applicazione.

   

Per automatizzare questo passaggio, utilizzare l'API dei diritti dell'entità servizio.

Configurazione dell'accesso

Azure DevOps non usa le autorizzazioni dell'applicazione Microsoft Entra per autorizzare un'identità dell'applicazione. Assegnate un livello di accesso, le appartenenze ai gruppi di Azure DevOps e le autorizzazioni per le risorse, proprio come fareste per un altro membro dell'organizzazione.

Seguire queste procedure:

• Assegnare il livello di accesso più basso che supporta lo scenario.
• Aggiungere l'identità a un gruppo di Azure DevOps specifico per lo scopo anziché assegnare direttamente molte autorizzazioni.
• Concedere l'accesso solo ai progetti e alle risorse necessari.
• Esaminare regolarmente le autorizzazioni e l'appartenenza ai gruppi dell'identità.

Per la ricerca e la gestione tramite codice, vedi la API Graph per l'entità servizio.

Acquisire e usare un token di accesso

Richiedere un token di accesso per la risorsa Azure DevOps e inviarlo nell'intestazione Authorization come token di connessione. Considerare i token di accesso come opachi. Non fare affidamento su una durata fissa né decodificare le dichiarazioni dal token. Riutilizzare l'oggetto credenziale in modo che la libreria di identità Azure possa memorizzare nella cache i token e acquisire un nuovo token quando necessario.

Gli esempi .NET seguenti richiedono il pacchetto Azure.Identity.

Principale di servizio con certificato

Impostare AZURE_TENANT_ID, AZURE_CLIENT_IDe AZURE_CLIENT_CERTIFICATE_PATH nella configurazione sicura del carico di lavoro.

using Azure.Core;
using Azure.Identity;
using System.Net.Http.Headers;

string RequiredSetting(string name) =>
    Environment.GetEnvironmentVariable(name)
    ?? throw new InvalidOperationException($"Missing {name}.");

// Create a service-principal credential from a certificate.
var credential = new ClientCertificateCredential(
    RequiredSetting("AZURE_TENANT_ID"),
    RequiredSetting("AZURE_CLIENT_ID"),
    RequiredSetting("AZURE_CLIENT_CERTIFICATE_PATH"));

var token = await credential.GetTokenAsync(new TokenRequestContext(
    new[] { "https://app.vssps.visualstudio.com/.default" }));

// Call Azure DevOps with the Microsoft Entra token.
using var client = new HttpClient();
client.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", token.Token);
var response = await client.GetAsync(
    "https://dev.azure.com/{organization}/_apis/projects?api-version=7.1");
response.EnsureSuccessStatusCode();
Console.WriteLine(await response.Content.ReadAsStringAsync());

Identità gestita assegnata dall'utente

Impostare AZURE_CLIENT_ID sull'ID client dell'identità gestita assegnata dall'utente. Assegnare tale identità alla risorsa Azure che ospita l'applicazione.

using Azure.Core;
using Azure.Identity;
using System.Net.Http.Headers;

var managedIdentityClientId =
    Environment.GetEnvironmentVariable("AZURE_CLIENT_ID")
    ?? throw new InvalidOperationException("Missing AZURE_CLIENT_ID.");

// Select the user-assigned identity explicitly.
var credential = new ManagedIdentityCredential(
    ManagedIdentityId.FromUserAssignedClientId(managedIdentityClientId));
var token = await credential.GetTokenAsync(new TokenRequestContext(
    new[] { "https://app.vssps.visualstudio.com/.default" }));

// Call Azure DevOps with the Microsoft Entra token.
using var client = new HttpClient();
client.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", token.Token);
var response = await client.GetAsync(
    "https://dev.azure.com/{organization}/_apis/projects?api-version=7.1");
response.EnsureSuccessStatusCode();
Console.WriteLine(await response.Content.ReadAsStringAsync());

Per un'identità gestita assegnata dal sistema, costruire invece le credenziali con ManagedIdentityId.SystemAssigned . Per altre opzioni di acquisizione di token, vedere Acquisire token Microsoft Entra.

Gestire le identità dell'applicazione

Licenze

• Assegnare un livello di accesso direttamente a ogni identità dell'applicazione.
• Ogni identità usa una licenza in ogni organizzazione a cui è assegnato un livello di accesso a pagamento.
• La fatturazione multi-organizzazione e i vantaggi della sottoscrizione Visual Studio per gli utenti non si applicano alle identità dell'applicazione.

Ciclo di vita delle identità

• Le identità dell'applicazione non hanno indirizzi di posta elettronica e non ricevono inviti.
• Non possono accedere in modo interattivo o usare il portale Web di Azure DevOps.
• Non possono creare chiavi PAT o SSH, creare organizzazioni o usare Azure DevOps flussi OAuth.
• La rimozione di un'identità dell'applicazione da Microsoft Entra ID non rimuove automaticamente l'appartenenza Azure DevOps. Rimuovere le identità obsolete da Azure DevOps nell'ambito del deprovisioning.

Accesso condizionale

L'accesso condizionale per le identità del carico di lavoro può essere destinato alle entità servizio in base alle condizioni e ai requisiti di licenza supportati. Non supporta le identità gestite. I controlli utente, ad esempio l'autenticazione a più fattori e la conformità dei dispositivi, non si applicano alle identità non utente.

Domande frequenti

Perché usare un'identità dell'applicazione anziché un token di accesso personale?

Un'identità dell'applicazione non è associata al ciclo di vita dell'occupazione di un utente. Richiede token di accesso di breve durata e può essere regolato separatamente in Microsoft Entra ID e Azure DevOps. Le identità gestite non richiedono un segreto dell'applicazione. Le entità servizio richiedono ancora la gestione delle credenziali, a meno che non utilizzino la federazione delle identità del carico di lavoro.

Quali limiti di velocità si applicano?

Le entità servizio e le identità gestite hanno gli stessi limiti di velocità di Azure DevOps degli utenti.

Come viene fatturata un'identità applicativa?

Assegnare un livello di accesso in base alle funzionalità richieste dall'identità. Un livello di accesso a pagamento viene fatturato separatamente in ogni organizzazione. Le licenze basate sui gruppi, la fatturazione utente multi-organizzazione e i vantaggi della sottoscrizione Visual Studio non si applicano.

È possibile aggiungere un'identità da un tenant diverso?

L'entità servizio o l'oggetto identità gestita che aggiungi deve esistere nel tenant Microsoft Entra collegato all'organizzazione Azure DevOps. Non è possibile aggiungere un'identità gestita direttamente da un altro tenant.

Perché l'identità non può accedere a un repository di Azure Repos?

Verificare che l'identità disponga dell'accesso basic o superiore, dell'appartenenza al progetto e dell'autorizzazione per accedere al repository. L'accesso Stakeholder non comprende Azure Repos.

Perché Azure DevOps non riesce a trovare l'entità servizio?

Nella Interfaccia di amministrazione di Microsoft Entra selezionare Applicazioni aziendali, aprire l'applicazione e usarne l'ID oggetto. Non usare l'ID oggetto in Registrazioni app.

Perché il API Graph restituisce un elenco vuoto o incompleto?

Seguire i valori dell'API continuationToken fino a quando non viene restituito alcun token di continuazione. Un'entità servizio potrebbe essere visualizzata in una pagina successiva.

Come si risolve TF401444: Sign-in required?

Aggiungere l'identità dell'applicazione in modo esplicito all'organizzazione Azure DevOps, assegnare un livello di accesso e concedere le autorizzazioni necessarie per il progetto e le risorse.

Articoli correlati

• Metodi di autenticazione per le integrazioni di Azure DevOps
• autenticazione Microsoft Entra
• Applicazioni di esempio per le entità servizio
• API delle autorizzazioni dell'entità servizio
• Accedere ad Azure DevOps con un'identità del carico di lavoro