Verwenden von Dienstprinzipalen und verwalteten Identitäten in Azure DevOps

Azure DevOps Services

Verwenden Sie einen Microsoft Entra-Serviceprinzipal oder eine verwaltete Identität für die Azure-DevOps-Automatisierung, die ohne Benutzer ausgeführt wird. Diese Anwendungsidentitäten sind nicht an ein Mitarbeiterkonto gebunden und erwerben kurzlebige Microsoft Entra Zugriffstoken anstelle von persönlichen Zugriffstoken (PATs).

Verwaltete Identitäten und Dienstprinzipale weisen unterschiedliche Anforderungen an die Verwaltung von Anmeldeinformationen auf:

Bevorzugen Sie eine verwaltete Identität für eine Azure gehostete Workload. Für einen Dienstprinzipal sollten Sie, wenn die Hostingumgebung dies unterstützt, die Workload-Identitätsföderation oder ein Zertifikat anstelle eines Clientgeheimnisses bevorzugen.

Grundlegendes zu Anwendungsidentitäten

Dienstprinzipale

Ein Dienstprinzipal ist die lokale Darstellung einer Anwendung in einem Microsoft Entra-Mandanten. Beim Registrieren einer Anwendung wird ein Dienstprinzipal in ihrem Heimmandanten erstellt. Eine Anwendung mit mehreren Mandanten kann außerdem in jedem Mandanten über einen Dienstprinzipal verfügen, der seine Zustimmung zur Anwendung erteilt.

Ein Dienstprinzipal kann sich wie folgt authentifizieren:

• Eine Verbundidentitäts-Anmeldeinformation, sofern von der Hostingplattform unterstützt.
• Ein Zertifikat.
• Ein geheimer Clientschlüssel, den Sie sicher speichern und drehen müssen.

Verwaltete Identitäten

Eine verwaltete Identität ist ein spezieller Dienstprinzipaltyp, dessen Anmeldeinformationen Azure verwaltet werden.

• Eine vom System zugewiesene verwaltete Identität gehört zu einer Azure Ressource und wird mit dieser Ressource gelöscht.
• Eine vom Benutzer zugewiesene verwaltete Identität ist eine separate Azure Ressource, die mehreren Ressourcen zugewiesen und unabhängig verwaltet werden kann.

Voraussetzungen

• Eine Azure DevOps Organisation, die mit einem Microsoft Entra Mandanten verbunden ist.
• Ein Dienstprinzipal oder eine verwaltete Identität im mit der Organisation verbundenen Mandanten.
• Berechtigung zum Hinzufügen von Benutzern zur Organisation. Ein Mitglied von Administratoren der Projektsammlung kann eine Identität hinzufügen. Ein Projekt- oder Teamadministrator kann eine Identität hinzufügen, wenn die Einladungsrichtlinie dies zulässt.
• Die Berechtigungen und Zugriffsebene, die für die Azure DevOps Ressourcen erforderlich sind, auf die die Identität zugreift.

Erstellen einer Identität

Wählen Sie den Identitätstyp aus, der der Hostingumgebung der Workload entspricht.

Erstellen eines Dienstprinzipals

1. Wählen Sie im Microsoft Entra Admin CenterApp-Registrierungen>Neue Registrierung aus.
2. Geben Sie einen beschreibenden Namen ein, und wählen Sie den unterstützten Kontotyp für Ihre Anwendung aus.
3. Lassen Sie Redirect URI für eine Service-zu-Service-Anwendung leer.
4. Fügen Sie einen Verbundidentitätsnachweis oder ein Zertifikat hinzu. Erstellen Sie ein Clientgeheimnis nur, wenn für die Workload keine sichereren Anmeldeinformationen genutzt werden können.

Weitere Informationen finden Sie unter Anwendungs- und Dienstprinzipalobjekte und Erstellen eines Dienstprinzipals.

Erstellen einer verwalteten Identität

So aktivieren Sie eine systemseitig zugewiesenen verwalteten Identität

1. Öffnen Sie im Azure-Portal die Azure Ressource, die Ihre Workload hosten soll.
2. Wählen Sie Identität>Systemseitig zugewiesen aus.
3. Legen Sie den Status auf "Ein" fest, und wählen Sie dann " Speichern" aus.

So erstellen und zuweisen Sie eine vom Benutzer zugewiesene verwaltete Identität:

1. Erstellen Sie im Azure-Portal eine Verwaltete Identitätsressource.
2. Öffnen Sie die Azure Ressource, die Ihre Workload hosten soll.
3. Wählen Sie Identität>>.
4. Wählen Sie die verwaltete Identität und dann "Hinzufügen" aus.

Weitere Informationen finden Sie unter Verwalten von benutzerseitig zugewiesenen verwalteten Identitäten.

Hinzufügen der Identität zu Azure DevOps

Sie müssen jeder Azure DevOps Organisation, auf die sie zugreift, explizit eine Anwendungsidentität hinzufügen. Das Hinzufügen der Identität nur zu einer Microsoft-Entra-Gruppe bedeutet nicht, dass sie in Azure DevOps verfügbar ist.

1. Wählen Sie in Azure DevOps "Organisationseinstellungen>Benutzer" aus.

2. Wählen Sie "Benutzer hinzufügen" aus.

3. Geben Sie den Anzeigenamen des Dienstprinzipals oder der verwalteten Identität ein.

4. Wählen Sie die erforderliche Zugriffsebene und Projekte aus. Azure Repos Zugriff erfordert basic oder eine höhere funktionale Zugriffsebene. Visual Studio Abonnementvorteile gelten nicht für Anwendungsidentitäten.

5. Klicken Sie auf Hinzufügen. Azure DevOps sendet keine Einladungs-E-Mail an eine Anwendungsidentität.

   

Um diesen Schritt zu automatisieren, verwenden Sie die Dienstprinzipalberechtigungs-API.

Zugriff konfigurieren

Azure DevOps verwendet nicht Microsoft Entra Anwendungsberechtigungen, um eine Anwendungsidentität zu autorisieren. Weisen Sie eine Zugriffsstufe, Azure DevOps Gruppenmitgliedschaften und Ressourcenberechtigungen wie für ein anderes Organisationsmitglied zu.

Befolgen Sie die folgenden Methoden:

• Weisen Sie die niedrigste Zugriffsebene zu, die das Szenario unterstützt.
• Fügen Sie die Identität zu einer zweckspezifischen Azure DevOps Gruppe hinzu, anstatt viele Berechtigungen direkt zuzuweisen.
• Gewähren Sie nur Zugriff auf die erforderlichen Projekte und Ressourcen.
• Überprüfen Sie regelmäßig die Berechtigungen und Gruppenmitgliedschaften der Identität.

Informationen zur programmgesteuerten Suche und Verwaltung finden Sie in der Service Principal Graph-API.

Abrufen und Verwenden eines Zugriffstokens

Fordern Sie ein Zugriffstoken für die Azure DevOps-Ressource an, und senden Sie es im Authorization Header als Bearertoken. Behandeln Sie Zugriffstoken als intransparent. Verlassen Sie sich nicht auf eine feste Gültigkeitsdauer und decodieren Sie keine Claims aus dem Token. Verwenden Sie das Anmeldeinformationsobjekt wieder, damit die Azure-Identitätsbibliothek Token zwischenspeichern und bei Bedarf ein neues Token abrufen kann.

Die folgenden .NET-Beispiele erfordern das Azure.Identity-Paket.

Dienstleiter mit Zertifikat

Legen Sie AZURE_CLIENT_ID, AZURE_CLIENT_CERTIFICATE_PATH und AZURE_TENANT_ID in der sicheren Konfiguration der Workload fest.

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());

Vom Benutzer zugewiesene verwaltete Identität

Legen Sie AZURE_CLIENT_ID auf die Client-ID der vom Benutzer zugewiesenen verwalteten Identität fest. Weisen Sie diese Identität der Azure Ressource zu, die die Anwendung hosten soll.

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());

Erstellen Sie für eine systemseitig zugewiesene verwaltete Identität die Anmeldeinformationen stattdessen mit ManagedIdentityId.SystemAssigned. Weitere Optionen zum Abrufen von Token finden Sie unter Microsoft Entra-Token abrufen.

Verwalten von Anwendungsidentitäten

Lizenzierung

• Weisen Sie jeder Anwendungsidentität direkt eine Zugriffsstufe zu.
• Jede Identität nutzt eine Lizenz in jeder Organisation, in der sie eine kostenpflichtige Zugriffsebene zugewiesen ist.
• Abrechnung für mehrere Organisationen und Vorteile eines Visual Studio-Abonnements für Benutzer gelten nicht für Anwendungsidentitäten.

Identitätslebenszyklus

• Anwendungsidentitäten verfügen nicht über E-Mail-Adressen und empfangen keine Einladungen.
• Sie können sich nicht interaktiv anmelden oder das Azure DevOps-Webportal verwenden.
• Sie können keine PATs oder SSH-Schlüssel erstellen, Organisationen erstellen oder Azure DevOps OAuth-Flüsse verwenden.
• Das Entfernen einer Anwendungsidentität aus Microsoft Entra ID entfernt ihre Mitgliedschaft in Azure DevOps nicht automatisch. Entfernen Sie veraltete Identitäten aus Azure DevOps als Teil der Deprovisionierung.

Bedingter Zugriff

Bedingter Zugriff für Workloadidentitäten kann unter den unterstützten Bedingungen und Lizenzanforderungen auf Dienstprinzipale angewendet werden. Verwaltete Identitäten werden nicht unterstützt. Benutzersteuerelemente wie mehrstufige Authentifizierung und Gerätekompatibilität gelten nicht für Nicht-Benutzeridentitäten.

Häufig gestellte Fragen

Warum eine Anwendungsidentität anstelle eines PAT verwenden?

Eine Anwendungsidentität ist nicht an den Beschäftigungslebenszyklus eines Benutzers gebunden. Er fordert kurzlebige Zugriffstoken an und kann in Microsoft Entra ID und Azure DevOps separat geregelt werden. Verwaltete Identitäten erfordern keinen geheimen Anwendungsschlüssel. Für Service Principals ist weiterhin eine Verwaltung von Anmeldeinformationen erforderlich, sofern sie keinen Workload-Identitätsverbund verwenden.

Welche Tariflimits gelten?

Dienstprinzipale und verwaltete Identitäten weisen die gleichen Azure DevOps Ratengrenzwerte wie Benutzer auf.

Wie wird eine Anwendungsidentität in Rechnung gestellt?

Weisen Sie basierend auf den Features, die die Identitätsanforderungen erfüllen, eine Zugriffsstufe zu. In jeder Organisation wird eine kostenpflichtige Zugriffsebene separat in Rechnung gestellt. Gruppenbasierte Lizenzierung, Benutzerabrechnung mit mehreren Organisationen und Visual Studio Abonnementvorteile gelten nicht.

Kann ich eine Identität von einem anderen Mandanten hinzufügen?

Das von Ihnen hinzugefügte Dienstprinzipal- oder verwaltete Identitätsobjekt muss im Microsoft Entra Mandanten vorhanden sein, der mit der Azure DevOps Organisation verbunden ist. Sie können keine verwaltete Identität direkt aus einem anderen Mandanten hinzufügen.

Warum kann die Identität nicht auf ein Azure-Repos-Repository zugreifen?

Vergewissern Sie sich, dass die Identität über den grundlegenden Zugriff oder höher, die Mitgliedschaft im Projekt und die Berechtigung für den Zugriff auf das Repository verfügt. Der Zugriff auf die Projektbeteiligten umfasst nicht Azure Repos.

Warum kann Azure DevOps meinen Dienstprinzipal nicht finden?

Wählen Sie in der Microsoft Entra Admin Center Enterprise-Anwendungen aus, öffnen Sie die Anwendung, und verwenden Sie dessen Objekt-ID. Verwenden Sie die Objekt-ID nicht aus App-Registrierungen.

Warum gibt die Graph-API eine leere oder unvollständige Liste zurück?

Folgen Sie den Werten der API, bis kein Fortsetzungstoken continuationToken zurückgegeben wird. Ein Dienstprinzipal kann auf einer späteren Seite angezeigt werden.

Wie behebe ich TF401444: Sign-in required?

Fügen Sie die Anwendungsidentität explizit zur Azure DevOps Organisation hinzu, weisen Sie eine Zugriffsstufe zu, und erteilen Sie die erforderlichen Projekt- und Ressourcenberechtigungen.

Verwandte Artikel

• Authentifizierungsmethoden für Azure DevOps Integrationen
• Microsoft Entra-Authentifizierung
• Beispielanwendungen für Dienstprinzipale
• Dienstprinzipalberechtigungen-API
• Zugreifen auf Azure DevOps mit einer Workloadidentität