Używanie zasad usługi i tożsamości zarządzanych w Azure DevOps

usługi Azure DevOps

Użyj nazwy głównej usługi Microsoft Entra lub tożsamości zarządzanej do automatyzacji usługi Azure DevOps działającej bez udziału użytkownika. Te tożsamości aplikacji nie są powiązane z kontem pracownika i uzyskują krótkotrwałe tokeny dostępu Microsoft Entra zamiast tokenów dostępu osobistego (PAT).

Tożsamości zarządzane i jednostki usługi mają różne wymagania dotyczące zarządzania poświadczeniami:

Preferuj tożsamość zarządzaną dla obciążenia hostowanego Azure. W przypadku nazwy głównej usługi preferuj federację tożsamości obciążeń lub certyfikat zamiast wpisu tajnego klienta, jeśli środowisko hostujące obsługuje taką możliwość.

Omówienie tożsamości aplikacji

Podmioty usługowe

Jednostka usługi to lokalna reprezentacja aplikacji w dzierżawie Microsoft Entra. Zarejestrowanie aplikacji powoduje utworzenie jednostki usługi w jej macierzystej dzierżawie. Aplikacja dla wielu dzierżaw może również mieć nazwę główną usługi w każdej dzierżawie, która udziela zgody na tę aplikację.

Jednostka usługi może uwierzytelniać się za pomocą:

• Poświadczenie tożsamości federacyjnej, jeśli jest obsługiwane przez platformę hostingową.
• Certyfikat.
• Sekret klienta, który należy bezpiecznie przechowywać i regularnie zmieniać.

Tożsamości zarządzane

Tożsamość zarządzana to specjalny typ nazwy głównej usługi, którego poświadczeniami zarządza platforma Azure.

• Tożsamość zarządzana przypisana przez system należy do jednego zasobu Azure i zostanie usunięta z tym zasobem.
• Tożsamość zarządzana przypisana przez użytkownika to oddzielny zasób Azure, który można przypisać do wielu zasobów i zarządzać niezależnie.

Wymagania wstępne

• Organizacja Azure DevOps połączona z dzierżawą Microsoft Entra.
• Jednostka usługi głównej lub tożsamość zarządzana w dzierżawcy połączonym z organizacją.
• Uprawnienie do dodawania użytkowników do organizacji. Członek grupy Project Collection Administrators może dodać tożsamość. Administrator projektu lub zespołu może dodać tożsamość, gdy zezwalają na to zasady zaproszeń .
• Uprawnienia i poziom dostępu wymagany dla zasobów Azure DevOps, do których uzyskuje dostęp tożsamość.

Tworzenie tożsamości

Wybierz typ tożsamości, który odpowiada środowisku hostowania obciążenia roboczego.

Tworzenie głównej jednostki usługi

1. W centrum administracyjne Microsoft Entra wybierz pozycję Rejestracje aplikacji>Nowa rejestracja.
2. Wprowadź opisową nazwę i wybierz obsługiwany typ konta dla aplikacji.
3. Pozostaw URI przekierowania puste w przypadku aplikacji typu service-to-service.
4. Dodaj poświadczenie tożsamości federacyjnej lub certyfikat. Utwórz klucz tajny klienta tylko wtedy, gdy obciążenie robocze nie może używać silniejszego poświadczenia.

Aby uzyskać więcej informacji, zobacz Application and service principal objects (Obiekty aplikacji i jednostki usługi ) i Create a service principal (Tworzenie jednostki usługi).

Tworzenie tożsamości zarządzanej

Aby włączyć tożsamość zarządzaną przypisaną przez system:

1. W portalu Azure otwórz zasób Azure hostujący obciążenie.
2. Wybierz Tożsamość>.
3. Ustaw pozycję Stan na Wł., a następnie wybierz pozycję Zapisz.

Aby utworzyć tożsamość zarządzaną przypisaną przez użytkownika i przypisać ją:

1. W portalu Azure utwórz zasób tożsamości zarządzanej.
2. Otwórz zasób Azure hostujący obciążenie.
3. Wybierz pozycje Tożsamość>>.
4. Wybierz tożsamość zarządzaną, a następnie wybierz pozycję Dodaj.

Aby uzyskać więcej informacji, zobacz Zarządzanie zarządzanymi tożsamościami przypisanymi przez użytkownika.

Dodawanie tożsamości do Azure DevOps

Musisz jawnie dodać tożsamość aplikacji do każdej organizacji Azure DevOps, do której ta aplikacja uzyskuje dostęp. Dodanie tożsamości tylko do grupy Microsoft Entra nie powoduje udostępnienia jej w Azure DevOps.

1. W Azure DevOps wybierz pozycję Ustawienia organizacji>Użytkownicy.

2. Wybierz pozycję Dodaj użytkowników.

3. Wprowadź nazwę wyświetlaną jednostki usługi lub tożsamości zarządzanej.

4. Wybierz wymagany poziom dostępu i projekty. Azure Repos dostęp wymaga poziomu dostępu podstawowego lub wyższego poziomu funkcjonalności. Korzyści z subskrypcji Visual Studio nie dotyczą tożsamości aplikacji.

5. Wybierz opcję Dodaj. Usługa Azure DevOps nie wysyła wiadomości e-mail z zaproszeniem do tożsamości aplikacyjnej.

   

Aby zautomatyzować ten krok, użyj interfejsu API Service Principal Entitlements.

Konfiguracja dostępu

Azure DevOps nie używa uprawnień aplikacji Microsoft Entra do autoryzowania tożsamości aplikacji. Przypisz poziom dostępu, członkostwa w grupach platformy Azure DevOps oraz uprawnienia do zasobów tak, jak w przypadku innego członka organizacji.

Postępuj zgodnie z następującymi rozwiązaniami:

• Przypisz najniższy poziom dostępu, który obsługuje scenariusz.
• Dodaj tożsamość do grupy Azure DevOps przeznaczonej do określonego celu, zamiast bezpośrednio przypisywać wiele uprawnień.
• Udzielanie dostępu tylko do wymaganych projektów i zasobów.
• Regularnie przeglądaj uprawnienia tożsamości i członkostwa w grupach.

W przypadku programistycznego wyszukiwania i zarządzania zobacz interfejs Service Principal interfejs Graph API.

Uzyskiwanie i używanie tokenu dostępu

Zażądaj tokenu dostępu dla zasobu Azure DevOps i wyślij go w nagłówku Authorization jako token elementu nośnego. Traktuj tokeny dostępu jako nieprzezroczyste. Nie należy polegać na stałym czasie ważności tokenu ani dekodować z niego deklaracji. Ponownie użyj obiektu poświadczeń, aby biblioteka tożsamości Azure mogła buforować tokeny i uzyskiwać nowy token w razie potrzeby.

Poniższe przykłady platformy .NET wymagają pakietu Azure.Identity.

Główny pracownik z certyfikatem

Ustaw AZURE_TENANT_ID, AZURE_CLIENT_ID i AZURE_CLIENT_CERTIFICATE_PATH w bezpiecznej konfiguracji obciążenia roboczego.

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

Tożsamość zarządzana przypisana użytkownikowi

Ustaw wartość AZURE_CLIENT_ID na identyfikator klienta tożsamości zarządzanej przypisanej przez użytkownika. Przypisz tożsamość do zasobu Azure, który hostuje aplikację.

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

W przypadku tożsamości zarządzanej przypisanej przez system zamiast tego utwórz poświadczenie przy użyciu ManagedIdentityId.SystemAssigned. Aby uzyskać więcej opcji pozyskiwania tokenów, zobacz Uzyskiwanie tokenów Microsoft Entra.

Zarządzanie tożsamościami aplikacji

Licensing

• Przypisz poziom dostępu bezpośrednio do każdej tożsamości aplikacji.
• Każda tożsamość zużywa licencję w każdej organizacji, do której przypisano jej płatny poziom dostępu.
• Rozliczenia dla wielu organizacji i korzyści z subskrypcji Visual Studio dla użytkowników nie mają zastosowania do tożsamości aplikacji.

Cykl życia tożsamości

• Tożsamości aplikacji nie mają adresów e-mail i nie otrzymują zaproszeń.
• Nie mogą się zalogować interaktywnie ani używać portalu internetowego Azure DevOps.
• Nie mogą tworzyć kluczy PATs ani SSH, tworzyć organizacji ani używać przepływów protokołu OAuth Azure DevOps.
• Usunięcie tożsamości aplikacji z Microsoft Entra ID nie powoduje automatycznego usunięcia członkostwa Azure DevOps. Usuń nieaktualne tożsamości z usługi Azure DevOps w ramach wycofywania dostępu.

Dostęp warunkowy

Dostęp warunkowy dla tożsamości obciążeń może być przeznaczony dla jednostek usługi zgodnie z obsługiwanymi warunkami i wymaganiami dotyczącymi licencjonowania. Nie obsługuje tożsamości zarządzanych. Mechanizmy kontroli użytkownika, takie jak uwierzytelnianie wieloskładnikowe i zgodność urządzeń, nie mają zastosowania do tożsamości innych niż użytkownicy.

Najczęściej zadawane pytania

Dlaczego warto stosować tożsamość aplikacji zamiast PAT?

Tożsamość aplikacji nie jest powiązana z cyklem życia zatrudnienia użytkownika. Żąda on krótkotrwałych tokenów dostępu i może być zarządzany oddzielnie w Microsoft Entra ID i Azure DevOps. Tożsamości zarządzane nie wymagają klucza tajnego aplikacji. Jednostki usługi nadal wymagają zarządzania poświadczeniami, chyba że używają federacji tożsamości obciążenia.

Jakie limity szybkości mają zastosowanie?

Jednostki usługi i tożsamości zarządzane mają takie same limity liczby żądań w usłudze Azure DevOps jak użytkownicy.

Jak rozliczana jest tożsamość aplikacji?

Przypisz poziom dostępu na podstawie funkcji wymaganych dla konta. Poziom płatnego dostępu jest rozliczany oddzielnie w każdej organizacji. Licencjonowanie oparte na grupach, rozliczenia użytkowników w wielu organizacjach i korzyści z subskrypcji Visual Studio nie mają zastosowania.

Czy mogę dodać tożsamość użytkownika z innej dzierżawy?

Dodany obiekt jednostki usługi lub tożsamości zarządzanej musi istnieć w dzierżawie Microsoft Entra połączonej z organizacją Azure DevOps. Nie można dodać tożsamości zarządzanej bezpośrednio z innej dzierżawy.

Dlaczego tożsamość nie może uzyskać dostępu do repozytorium Azure Repos?

Upewnij się, że tożsamość ma poziom dostępu Basic lub wyższy, członkostwo w projekcie oraz uprawnienia dostępu do repozytorium. Dostęp uczestników projektu nie obejmuje Azure Repos.

Dlaczego program Azure DevOps nie może znaleźć nazwy głównej usługi?

W centrum administracyjne Microsoft Entra wybierz pozycję Aplikacje dla przedsiębiorstw, otwórz aplikację i użyj jej identyfikatora obiektu. Nie używaj identyfikatora obiektu z Rejestracje aplikacji.

Dlaczego interfejs Graph API zwraca pustą lub niekompletną listę?

Postępuj zgodnie z wartościami zwracanymi przez interfejs API continuationToken, dopóki nie będzie już zwracany token kontynuacji. Nazwa główna usługi może pojawić się na kolejnej stronie.

Jak rozwiązać problem TF401444: Sign-in required?

Dodaj tożsamość aplikacji jawnie do organizacji Azure DevOps, przypisz poziom dostępu i przyznaj wymagane uprawnienia do projektu i zasobu.

Powiązane artykuły

• Metody uwierzytelniania dla integracji Azure DevOps
• Uwierzytelnianie Microsoft Entra
• Przykładowe aplikacje dla jednostek usługi
• Interfejs API uprawnień obiektu Service Principal
• Uzyskiwanie dostępu do Azure DevOps przy użyciu tożsamości obciążenia