Share via

Korzystanie z jednostek usługi i tożsamości zarządzanych

  • Artykuł

Azure DevOps Services

Dodaj jednostki usługi Microsoft Entra i tożsamości zarządzane do organizacji usługi Azure DevOps, aby udzielić dostępu do zasobów organizacji. W przypadku wielu zespołów ta funkcja może być opłacalną i preferowaną alternatywą dla osobistych tokenów dostępu (PAT) podczas uwierzytelniania aplikacji, które przepływy pracy automatyzacji zasilania w firmie.

Informacje o jednostkach usługi i tożsamościach zarządzanych

Jednostki usługi to obiekty zabezpieczeń w aplikacji firmy Microsoft Entra, które definiują, co aplikacja może zrobić w danej dzierżawie. Są one konfigurowane w witrynie Azure Portal podczas procesu rejestracji aplikacji i skonfigurowane do uzyskiwania dostępu do zasobów platformy Azure, takich jak Azure DevOps. Dodając jednostki usługi do organizacji i konfigurując uprawnienia na ich podstawie, możemy określić, czy jednostka usługi jest autoryzowana do uzyskiwania dostępu do zasobów organizacji i które z nich.

Tożsamości zarządzane to inna funkcja firmy Microsoft Entra, która działa podobnie do jednostek usługi aplikacji. Te obiekty zapewniają tożsamości dla zasobów platformy Azure i umożliwiają łatwe korzystanie z usług obsługujących uwierzytelnianie Firmy Microsoft Entra w celu udostępniania poświadczeń. Jest to atrakcyjna opcja, ponieważ identyfikator Entra firmy Microsoft zajmuje się zarządzaniem poświadczeniami i rotacją. Podczas gdy konfiguracja tożsamości zarządzanej może wyglądać inaczej w witrynie Azure Portal, usługa Azure DevOps traktuje oba obiekty zabezpieczeń tak samo jak nowa tożsamość w organizacji ze zdefiniowanymi uprawnieniami. W pozostałej części tego artykułu odwołujemy się do tożsamości zarządzanych i jednostek usługi zamiennie jako jednostki usługi, chyba że określono.

Wykonaj poniższe kroki, aby uwierzytelnić te tożsamości w usłudze Azure DevOps, aby umożliwić im wykonywanie akcji w imieniu siebie.

Konfigurowanie tożsamości zarządzanych i jednostek usługi

Implementacja może się różnić, ale na wysokim poziomie poniższe kroki ułatwiają rozpoczęcie korzystania z jednostek usługi w przepływie pracy. Rozważ przejrzenie jednej z naszych przykładowych aplikacji , aby samodzielnie skorzystać z przykładu.

1. Tworzenie nowej tożsamości zarządzanej lub jednostki usługi aplikacji

Utwórz jednostkę usługi aplikacji lub tożsamość zarządzaną w witrynie Azure Portal.

Tworzenie jednostki usługi aplikacji

Podczas tworzenia nowej rejestracji aplikacji obiekt aplikacji jest tworzony w identyfikatorze Entra firmy Microsoft. Jednostka usługi aplikacji jest reprezentacją tego obiektu aplikacji dla danej dzierżawy. Podczas rejestrowania aplikacji jako aplikacji wielodostępnej istnieje unikatowy obiekt jednostki usługi reprezentujący obiekt aplikacji dla każdej dzierżawy, do której jest dodawana aplikacja.

Dalsze informacje:

Uwaga

Azure Active Directory nosi teraz nazwę Microsoft Entra ID. Aby uzyskać więcej informacji, zobacz Nowa nazwa usługi Azure AD.

Tworzenie tożsamości zarządzanej

Tworzenie tożsamości zarządzanych w witrynie Azure Portal znacznie różni się od konfigurowania aplikacji z jednostkami usługi. Przed rozpoczęciem procesu tworzenia należy najpierw rozważyć typ tożsamości zarządzanej, którą chcesz utworzyć:

  • Tożsamość zarządzana przypisana przez system: niektóre usługi platformy Azure umożliwiają włączenie tożsamości zarządzanej bezpośrednio w wystąpieniu usługi. Po włączeniu tożsamości zarządzanej przypisanej przez system tożsamość jest tworzona w identyfikatorze Entra firmy Microsoft. Tożsamość jest powiązana z cyklem życia tego wystąpienia usługi. Po usunięciu zasobu platforma Azure automatycznie usunie tożsamość. Zgodnie z projektem tylko ten zasób platformy Azure może używać tej tożsamości do żądania tokenów z usługi Microsoft Entra ID.
  • Tożsamość zarządzana przypisana przez użytkownika Możesz również utworzyć tożsamość zarządzaną jako autonomiczny zasób platformy Azure, tworząc tożsamość zarządzaną przypisaną przez użytkownika i przypisując ją do co najmniej jednego wystąpienia usługi platformy Azure. W przypadku tożsamości zarządzanych przypisanych przez użytkownika tożsamość jest zarządzana oddzielnie od zasobów, które go używają.

Aby uzyskać więcej informacji, zobacz następujące artykuły i wideo:

Uwaga

Azure Active Directory nosi teraz nazwę Microsoft Entra ID. Aby uzyskać więcej informacji, zobacz Nowa nazwa usługi Azure AD.

2. Dodawanie jednostek usługi i zarządzanie nimi w organizacji usługi Azure DevOps

Po skonfigurowaniu jednostek usługi w centrum administracyjnym firmy Microsoft Entra należy wykonać to samo w usłudze Azure DevOps, dodając jednostki usługi do organizacji. Można je dodać za pośrednictwem strony Użytkownicy lub interfejsów API ServicePrincipalEntitlements. Ponieważ nie mogą się zalogować interaktywnie, konto użytkownika, które może dodawać użytkowników do organizacji, projektu lub zespołu, musi je dodać. Tacy użytkownicy obejmują Administracja istratory kolekcji projektów (PCA) lub Administracja istratory projektu i Administracja istratory zespołu, gdy są włączone zasady "Zezwalaj administratorom zespołu i projektu na zapraszanie nowych użytkowników".

Napiwek

Aby dodać jednostkę usługi do organizacji, wprowadź nazwę wyświetlaną aplikacji lub tożsamości zarządzanej. Jeśli zdecydujesz się programowo dodać jednostkę usługi za pośrednictwem interfejsu ServicePrincipalEntitlements API, pamiętaj, aby przekazać identyfikator obiektu jednostki usługi, a nie identyfikator obiektu aplikacji.

Jeśli jesteś pcA, możesz również udzielić jednostce usługi dostępu do określonych projektów i przypisać licencję. Jeśli nie jesteś pcA, musisz skontaktować się z PCA, aby zaktualizować wszystkie członkostwa w projekcie lub poziomy dostępu licencji.

Zrzut ekranu przedstawiający jednostki usługi i tożsamości zarządzane w centrum użytkowników.

Uwaga

Tożsamość zarządzana lub jednostka usługi dla dzierżawy, z którą jest połączona twoja organizacja, można dodać tylko tożsamość zarządzaną. Aby uzyskać dostęp do tożsamości zarządzanej w innej dzierżawie, zobacz obejście w często zadawanych pytaniach.

Po dodaniu jednostek usługi do organizacji można je traktować podobnie jak standardowe konta użytkowników. Uprawnienia można przypisywać bezpośrednio do jednostki usługi, dodawać do grup zabezpieczeń i zespołów, przypisywać je do dowolnego poziomu dostępu i usuwać je z organizacji. Można również użyć polecenia Service Principal Graph APIs , aby wykonać operacje CRUD na jednostkach usługi.

Uwaga

Azure Active Directory nosi teraz nazwę Microsoft Entra ID. Aby uzyskać więcej informacji, zobacz Nowa nazwa usługi Azure AD.

Zarządzanie jednostkami usługi różni się od kont użytkowników w następujący sposób:

  • Jednostki usługi nie mają wiadomości e-mail i w związku z tym nie mogą być zapraszane do organizacji za pośrednictwem poczty e-mail.
  • Reguły grupy dotyczące licencjonowania nie mają obecnie zastosowania do jednostek usługi. Jeśli chcesz przypisać poziom dostępu do jednostki usługi, najlepiej jest to zrobić bezpośrednio.
  • Jednostki usługi można dodawać do grup firmy Microsoft Entra (w witrynie Azure Portal), ale mamy bieżące ograniczenie techniczne uniemożliwiające wyświetlanie ich na liście członków grupy Firmy Microsoft Entra. To ograniczenie nie jest prawdziwe w przypadku grup usługi Azure DevOps. Oznacza to, że jednostka usługi nadal dziedziczy wszystkie uprawnienia grupy ustawione na podstawie grupy Microsoft Entra, do której należą.
  • Nie wszyscy użytkownicy w grupie Microsoft Entra są natychmiast częścią organizacji usługi Azure DevOps tylko dlatego, że administrator tworzy grupę i dodaje do niej grupę Firmy Microsoft Entra. Mamy proces o nazwie "materializacja", który występuje po pierwszym zalogowaniu użytkownika z grupy Microsoft Entra do organizacji. Użytkownik logujący się do organizacji pozwala nam określić, którzy użytkownicy powinni otrzymać licencję. Ponieważ logowanie nie jest możliwe dla jednostek usługi, administrator musi jawnie dodać go do organizacji zgodnie z wcześniejszym opisem.
  • Nie można zmodyfikować nazwy wyświetlanej ani awatara jednostki usługi w usłudze Azure DevOps.
  • Jednostka usługi liczy się jako licencja dla każdej organizacji, do których jest dodawana, nawet jeśli wybrano rozliczenia w wielu organizacjach.

3. Uzyskiwanie dostępu do zasobów usługi Azure DevOps przy użyciu tokenu identyfikatora entra firmy Microsoft

Uzyskiwanie tokenu identyfikatora entra firmy Microsoft

Uzyskanie tokenu dostępu dla tożsamości zarządzanej można wykonać zgodnie z dokumentacją identyfikatora entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz przykłady jednostek usługi i tożsamości zarządzanych.

Zwrócony token dostępu to JWT ze zdefiniowanymi rolami, które mogą służyć do uzyskiwania dostępu do zasobów organizacji przy użyciu tokenu jako elementu nośnego.

Używanie tokenu identyfikatora Entra firmy Microsoft do uwierzytelniania w zasobach usługi Azure DevOps

W poniższym przykładzie wideo przechodzimy od uwierzytelniania za pomocą tokenu PAT do używania tokenu z jednostki usługi. Zaczynamy od używania klucza tajnego klienta do uwierzytelniania, a następnie przechodzimy do korzystania z certyfikatu klienta.

Uwaga

Azure Active Directory nosi teraz nazwę Microsoft Entra ID. Aby uzyskać więcej informacji, zobacz Nowa nazwa usługi Azure AD.

  • Jednostki usługi można dodawać do grup identyfikatorów entra firmy Microsoft (w witrynie Azure Portal), ale mamy bieżące ograniczenie techniczne uniemożliwiające wyświetlanie ich na liście członków grupy Microsoft Entra ID. To ograniczenie nie jest prawdziwe w przypadku grup usługi Azure DevOps. Oznacza to, że jednostka usługi nadal dziedziczy wszystkie uprawnienia grupy ustawione na podstawie grupy Identyfikator Entra firmy Microsoft, do której należą.
  • Nie wszyscy użytkownicy w grupie Identyfikator entra firmy Microsoft są natychmiast częścią organizacji usługi Azure DevOps tylko dlatego, że administrator tworzy grupę i dodaje do niej grupę microsoft Entra ID. Mamy proces o nazwie "materializacja", który występuje po pierwszym zalogowaniu użytkownika z grupy Microsoft Entra ID do organizacji. Użytkownik logujący się do organizacji pozwala nam określić, którzy użytkownicy powinni otrzymać licencję. Ponieważ logowanie nie jest możliwe dla jednostek usługi, administrator musi jawnie dodać go do organizacji zgodnie z wcześniejszym opisem.
  • Nie można zmodyfikować nazwy wyświetlanej ani awatara jednostki usługi w usłudze Azure DevOps.
  • Jednostka usługi liczy się jako licencja dla każdej organizacji, do których jest dodawana, nawet jeśli wybrano rozliczenia w wielu organizacjach.

Inny przykład przedstawia sposób nawiązywania połączenia z usługą Azure DevOps przy użyciu tożsamości zarządzanej przypisanej przez użytkownika w ramach funkcji platformy Azure.

Uwaga

Azure Active Directory nosi teraz nazwę Microsoft Entra ID. Aby uzyskać więcej informacji, zobacz Nowa nazwa usługi Azure AD.

Postępuj zgodnie z tymi przykładami, wyszukując kod aplikacji w naszej kolekcji przykładowych aplikacji.

Jednostki usługi mogą służyć do wywoływania interfejsów API REST usługi Azure DevOps i wykonywania większości akcji, ale jest ograniczona do następujących operacji:

  • Jednostki usług nie mogą być właścicielami organizacji ani tworzeniem organizacji.
  • Jednostki usługi nie mogą tworzyć tokenów, takich jak osobiste tokeny dostępu (PAT) lub klucze SSH. Mogą oni wygenerować własne tokeny identyfikatora Entra firmy Microsoft, a te tokeny mogą służyć do wywoływania interfejsów API REST usługi Azure DevOps.
  • Nie obsługujemy usługi Azure DevOps OAuth dla jednostek usługi.

Uwaga

Do generowania tokenów można używać tylko identyfikatora aplikacji, a nie identyfikatorów URI zasobów skojarzonych z usługą Azure DevOps.

Często zadawane pytania

Ogólne

Pytanie: Dlaczego należy używać jednostki usługi lub tożsamości zarządzanej zamiast identyfikatora PAT?

1: Wielu naszych klientów szuka jednostki usługi lub tożsamości zarządzanej, aby zastąpić istniejący token dostępu (osobisty token dostępu). Takie sieci PAT często należą do konta usługi (udostępnionego konta zespołu), które używa ich do uwierzytelniania aplikacji za pomocą zasobów usługi Azure DevOps. PaTs muszą być pracochłonne obracane co tak często (co najmniej 180 dni). Ponieważ tokeny paTs są po prostu tokenami nośnymi, co oznacza ciągi tokenu reprezentujące nazwę użytkownika i hasło użytkownika, są one niezwykle ryzykowne do użycia, ponieważ mogą łatwo wpaść w ręce niewłaściwej osoby. Tokeny firmy Microsoft Entra wygasają co godzinę i muszą być ponownie generowane przy użyciu tokenu odświeżania, aby uzyskać nowy token dostępu, co ogranicza ogólny czynnik ryzyka po wycieku.

Nie można użyć jednostki usługi do utworzenia osobistego tokenu dostępu.

Pyt.: Jakie są limity szybkości dla jednostek usługi i tożsamości zarządzanych?

1: W tej chwili jednostki usługi i tożsamości zarządzane mają te same limity szybkości co użytkownicy.

Pyt.: Czy korzystanie z tej funkcji będzie kosztować więcej?

1: Jednostki usługi i tożsamości zarządzane są wyceniane podobnie jak użytkownicy na podstawie poziomu dostępu. Jedną z godnych uwagi zmianą jest sposób traktowania "rozliczeń w wielu organizacjach" dla jednostek usługi. Użytkownicy są liczeni jako tylko jedna licencja, niezależnie od liczby organizacji, w których się znajdują. Jednostki usługi są liczone jako jedna licencja na każdą organizację, w której znajduje się użytkownik. Ten scenariusz jest podobny do standardowych "rozliczeń opartych na przypisaniach użytkowników".

Pyt.: Czy mogę użyć jednostki usługi lub tożsamości zarządzanej za pomocą interfejsu wiersza polecenia platformy Azure?

Ach: Tak! W dowolnym miejscu, w przypadku którego zostanie wyświetlony monit o dostęp paTs w interfejsie wiersza polecenia platformy Azure, można również zaakceptować tokeny dostępu identyfikatora Entra firmy Microsoft. Zapoznaj się z tymi przykładami, aby dowiedzieć się, jak można przekazać token entra firmy Microsoft w celu uwierzytelnienia przy użyciu interfejsu wiersza polecenia.

# To authenticate with a command: After typing this command, the az devops login will prompt you to enter a token. You can add an Entra ID token too! Not just a PAT.
az devops login

# To authenticate a service principal with a password or cert:
az login --service-principal -u <app-id> -p <password-or-cert> --tenant <tenant>

# To authenticate a managed identity:
az login --identity

Teraz uzyskajmy token entra firmy Microsoft (identyfikator UUID 499b84ac-1321-427f-aa17-267ca6975798zasobu usługi Azure DevOps) i spróbujmy wywołać interfejs API usługi Azure DevOps, przekazując go w nagłówkach jako Bearer token:

Write-Host "Obtain access token for Service Connection identity..."
$accessToken = az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query "accessToken" --output tsv

Write-Host "Use access token with Azure DevOps REST API to list projects in the organization..."
$apiVersion = "7.1-preview.1"
$uri = "https://dev.azure.com/${yourOrgname}/_apis/projects?api-version=${apiVersion}"
$headers = @{
    Accept = "application/json"
    Authorization = "Bearer $accessToken"
}
Invoke-RestMethod -Uri $uri -Headers $headers -Method Get | Select-Object -ExpandProperty value ` | Select-Object id, name

Teraz możesz używać az cli poleceń w zwykły sposób.

Pyt.: Czy mogę dodać tożsamość zarządzaną z innej dzierżawy do mojej organizacji?

1: Tożsamość zarządzana można dodać tylko z tej samej dzierżawy, z którą jest połączona Twoja organizacja. Mamy jednak obejście, które umożliwia skonfigurowanie tożsamości zarządzanej w "dzierżawie zasobów", gdzie znajdują się wszystkie zasoby. Następnie możesz zezwolić na korzystanie z niej przez jednostkę usługi w "dzierżawie docelowej", w której twoja organizacja jest połączona. Wykonaj następujące kroki jako obejście:

  1. Utwórz tożsamość zarządzaną przypisaną przez użytkownika w witrynie Azure Portal dla dzierżawy zasobów.
  2. Połączenie ją do maszyny wirtualnej i przypisz do niej tę tożsamość zarządzaną.
  3. Utwórz magazyn kluczy i wygeneruj certyfikat (nie może być typu "PEM"). Podczas generowania tego certyfikatu jest również generowany wpis tajny o tej samej nazwie, którego używamy później.
  4. Udziel dostępu do tożsamości zarządzanej, aby mógł odczytywać klucz prywatny z magazynu kluczy. Utwórz zasady dostępu w magazynie kluczy z uprawnieniami "Get/List" (w obszarze "Uprawnienia wpisu tajnego" i wyszukaj tożsamość zarządzaną w obszarze "Wybierz podmiot zabezpieczeń".
  5. Pobierz utworzony certyfikat w formacie CER, co gwarantuje, że nie zawiera prywatnej części certyfikatu.
  6. Utwórz nową rejestrację aplikacji w dzierżawie docelowej.
  7. Przekaż pobrany certyfikat do tej nowej aplikacji na karcie "Certyfikaty i wpisy tajne".
  8. Dodaj jednostkę usługi tej aplikacji do organizacji usługi Azure DevOps, do której chcesz uzyskać dostęp, i pamiętaj, aby skonfigurować jednostkę usługi z wymaganymi uprawnieniami.
  9. Aby uzyskać token dostępu firmy Microsoft Entra z tej jednostki usługi, która korzysta z certyfikatu tożsamości zarządzanej, zobacz następujący przykład kodu:

Uwaga

Należy regularnie wymieniać certyfikaty, tak jak zawsze.

public static async Task<string> GetSecret(string keyVaultName, string secretName)
{
	var keyVaultUri = new Uri("https://" + keyVaultName + ".vault.azure.net");
	var client = new SecretClient(keyVaultUri, new ManagedIdentityCredential());
	var keyVaultSecret = await client.GetSecretAsync(secretName);

	var secret = keyVaultSecret.Value;
	return secret.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(string applicationClientID, string appTenantId)
{
	IConfidentialClientApplication app;

	byte[] privateKeyBytes = Convert.FromBase64String(GetSecret(keyVaultName, secretName));
	X509Certificate2 certificateWithPrivateKey = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

	app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
		.WithCertificate(certificateWithPrivateKey)
		.WithAuthority(new Uri(string.Format(CultureInfo.InvariantCulture, "https://login.microsoftonline.com/{0}", appTenantId)))
		.Build();
	app.AddInMemoryTokenCache();

	string AdoAppClientID = "499b84ac-1321-427f-aa17-267ca6975798/.default";
	string[] scopes = new string[] { AdoAppClientID };

	var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();

	return result;
}

Artifacts

Pyt.: Czy mogę użyć jednostki usługi do nawiązania połączenia z kanałami informacyjnymi?

1: Tak, możesz nawiązać połączenie z dowolnym źródłem danych usługi Azure Artifacts za pomocą jednostki usługi. W poniższych przykładach pokazano, jak nawiązać połączenie z tokenem identyfikatora Entra firmy Microsoft dla pakietów NuGet, npm i Maven, ale inne typy kanałów informacyjnych również powinny działać.

Konfiguracja projektu NuGet przy użyciu tokenu Microsoft Entra

  1. Dodaj plik nuget.config do projektu w tym samym folderze co plik csproj lub .sln .

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="FeedName" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" />
  </packageSources>
</configuration>

  2. Pobierz token identyfikatora entra firmy Microsoft dla jednostki usługi.

  3. Uruchom następujące polecenie, aby uwierzytelnić się przy użyciu poświadczeń, a następnie dodaj token przy użyciu polecenia setapikey. To polecenie dodaje źródło źródła danych do pliku nuget.config:

    nuget sources add -name <FEED_NAME> -source <SOURCE_URL> -username <USERNAME> -password <PASSWORD>

nuget setapikey <YOUR_ACCESS_TOKEN> -source <SOURCE_URL>

Konfiguracja projektu npm przy użyciu tokenów firmy Microsoft Entra

Uwaga

Narzędzie vsts-npm-auth nie obsługuje tokenów dostępu firmy Microsoft Entra.

  1. Dodaj element .npmrc do projektu w tym samym katalogu co plik package.json.

    registry=https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/registry/ 
always-auth=true

  2. Uzyskaj token dostępu dla jednostki usługi lub tożsamości zarządzanej.

  3. Dodaj ten kod do pliku ${user.home}/.npmrc i zastąp symbol zastępczy [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] tokenem dostępu z poprzedniego kroku.

    //pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/:_authToken=[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]

Konfiguracja projektu Maven z tokenami firmy Microsoft Entra

  1. Dodaj repozytorium zarówno pom.xmldo sekcji, <repositories> jak i <distributionManagement> .

    <repository>
  <id>Fabrikam</id>
  <url>https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/maven/v1</url>
  <releases>
    <enabled>true</enabled>
  </releases>
  <snapshots>
    <enabled>true</enabled>
  </snapshots>
</repository>

  2. Uzyskaj token dostępu dla jednostki usługi lub tożsamości zarządzanej.

  3. Dodaj lub edytuj settings.xml plik w ${user.home}/.m2 pliku i zastąp symbol zastępczy [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] tokenem dostępu z poprzedniego kroku.

    <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                              https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>Fabrikam</id>
      <username>Fabrikam</username>
      <password>[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]</password>
    </server>
  </servers>
</settings>

Marketplace

Pyt.: Czy mogę użyć jednostki usługi do publikowania rozszerzeń w witrynie Visual Studio Marketplace?

Odpowiedź: Tak. Wykonaj poniższe kroki.

  1. Dodaj jednostkę usługi jako element członkowski do konta wydawcy. Identyfikator jednostki usługi można uzyskać z jego profilu przy użyciu opcji Profile — Pobierz. Następnie możesz dodać jednostkę usługi jako element członkowski do wydawcy przy użyciu identyfikatora z poprzedniego kroku.

  2. Publikowanie rozszerzenia za pomocą interfejsu wiersza polecenia TFX przy użyciu dostawcy usług. Wykonaj następujące polecenie interfejsu wiersza polecenia TFX, aby użyć tokenu dostępu sp:

tfx extension publish --publisher my-publisher --vsix my-publisher.my-extension-1.0.0.vsix --auth-type pat -t <AAD_ACCESS_TOKEN>

Pipelines

Pyt.: Czy mogę użyć tożsamości zarządzanej w ramach połączenia z usługą? Jak można łatwiej wymieniać wpisy tajne dla jednostki usługi w połączeniu z usługą? Czy można całkowicie uniknąć przechowywania wpisów tajnych w połączeniu z usługą?

pomoc techniczna platformy Azure federacji tożsamości obciążenia przy użyciu protokołu openID Połączenie, który umożliwia tworzenie połączeń usługi bez wpisów tajnych w usłudze Azure Pipelines wspieranych przez jednostki usługi lub tożsamości zarządzane z poświadczeniami federacyjnymi w usłudze Microsoft Entra ID. W ramach wykonywania potok może wymienić własny token wewnętrzny za pomocą tokenu Firmy Microsoft Entra, co pozwala uzyskać dostęp do zasobów platformy Azure. Po zaimplementowaniu ten mechanizm jest zalecany w produkcie w przypadku innych typów połączeń usług platformy Azure, które istnieją już dzisiaj. Ten mechanizm może również służyć do konfigurowania wdrożeń wolnych od wpisów tajnych z dowolnym innym dostawcą usług zgodnym ze standardem OIDC. Ten mechanizm jest w wersji zapoznawczej.

Repos

Pyt.: Czy mogę użyć jednostki usługi do wykonywania operacji git, takich jak klonowanie repozytorium?

Odp.: Zapoznaj się z poniższym przykładem przekazywania tokenu identyfikatora Entra firmy Microsoft jednostki usługi zamiast tokenu PAT do sklonowania repozytorium git w skrypcie programu PowerShell.

$ServicePrincipalAadAccessToken = 'Entra ID access token of a service principal'
git -c http.extraheader="AUTHORIZATION: bearer $ServicePrincipalAadAccessToken" clone https://dev.azure.com/{yourOrgName}/{yourProjectName}/_git/{yourRepoName}

Napiwek

Aby zachować bezpieczeństwo tokenu, użyj menedżerów poświadczeń, aby nie trzeba było wprowadzać poświadczeń za każdym razem. Zalecamy usługę Git Credential Manager, która może akceptować tokeny microsoft Entra (czyli tokeny OAuth tożsamości microsoft) zamiast paT, jeśli zmienna środowiskowa zostanie zmieniona.

Pomocna porada dotycząca pobierania tokenu dostępu z interfejsu wiersza polecenia platformy Azure w celu wywołania pobierania usługi Git:

  1. Otwórz konfigurację repozytorium Git:
git config -e
  1. Dodaj następujące wiersze, w których identyfikator UUID zasobu usługi Azure DevOps to 499b84ac-1321-427f-aa17-267ca6975798:
[credential]
    helper = "!f() { test \"$1\" = get && echo \"password=$(az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query accessToken -o tsv)\"; }; f"
  1. Przetestuj, czy działa przy użyciu:
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Potencjalne błędy

Nie można utworzyć jednostki usługi o identyfikatorze obiektu "{provided objectId}"

Nie ma jednostki usługi z dzierżawą połączoną z provided objectId twoją organizacją. Jedną z typowych przyczyn jest przekazanie identyfikatora obiektu rejestracji aplikacji zamiast identyfikatora obiektu jednostki usługi. Pamiętaj, że jednostka usługi jest obiektem reprezentującym aplikację dla danej dzierżawy, a nie samą aplikacją. Element service principal object ID można znaleźć na stronie "Aplikacje dla przedsiębiorstw" dzierżawy. Wyszukaj nazwę aplikacji i wybierz wynik "Aplikacja dla przedsiębiorstw", który zwraca. Ten wynik jest stroną jednostki usługi/aplikacji dla przedsiębiorstw i można użyć identyfikatora obiektu znalezionego na tej stronie, aby utworzyć jednostkę usługi w usłudze Azure DevOps.

Odmowa dostępu: użytkownik {ID of the caller identity} potrzebuje następujących uprawnień w zasobie Użytkownicy, aby wykonać tę akcję: Dodaj użytkowników

Ten błąd może być spowodowany jedną z następujących przyczyn:

  • Nie jesteś właścicielem organizacji, administratora kolekcji projektów ani administratora projektu lub zespołu.
  • Jesteś administratorem projektu lub zespołu, ale zasady "Zezwalaj administratorom zespołu i projektu na zapraszanie nowych użytkowników" są wyłączone.
  • Jesteś administratorem projektu lub zespołu, który może zaprosić nowych użytkowników, ale próbujesz przypisać licencję podczas zapraszania nowego użytkownika. Administratorzy projektu lub zespołu nie mogą przypisywać licencji do nowych użytkowników. Każdy nowy zaproszony użytkownik zostanie dodany na domyślnym poziomie dostępu dla nowych użytkowników. Skontaktuj się z pca, aby zmienić poziom dostępu do licencji.

Interfejs API listy wykresów usługi Azure DevOps zwraca pustą listę, mimo że wiemy, że w organizacji istnieją jednostki usługi

Interfejs API listy wykresów usługi Azure DevOps może zwracać pustą listę, nawet jeśli jest jeszcze więcej stron, które mają zostać zwrócone. Użyj elementu , continuationToken aby wykonać iteracje na listach i w końcu można znaleźć stronę, na której są zwracane jednostki usługi. continuationToken Jeśli element zostanie zwrócony, oznacza to, że za pośrednictwem interfejsu API jest dostępnych więcej wyników. Chociaż planujemy ulepszyć tę logikę, w tej chwili możliwe jest, że pierwsze wyniki X zwracają puste.

TF401444: Zaloguj się co najmniej raz jako {tenantId'tenantId\servicePrincipalObjectId'} w przeglądarce internetowej, aby umożliwić dostęp do usługi.

Jeśli jednostka usługi nie została zaproszona do organizacji, może wystąpić następujący błąd. Upewnij się, że jednostka usługi została dodana do odpowiedniej organizacji i ma wszystkie uprawnienia wymagane do uzyskania dostępu do wszystkich wymaganych zasobów.