Использование субъектов-служб и управляемых удостоверений в Azure DevOps

Azure DevOps Services

Примечание.

Azure Active Directory теперь называется Microsoft Entra ID. Дополнительные сведения см. в разделе Новое название для Azure AD.

Добавьте субъекты-службы Microsoft Entra и управляемые удостоверения в организации Azure DevOps Services, чтобы предоставить доступ к ресурсам организации. Для многих команд эта функция может быть жизнеспособной и предпочтительной альтернативой личным маркерам доступа (PATs) при проверке подлинности приложений, которые рабочих процессов автоматизации питания в вашей компании.

Сведения о субъектах-службах и управляемых удостоверениях

Субъекты-службы — это объекты безопасности в приложении Microsoft Entra, определяющие, что может сделать приложение в данном клиенте. Они настраиваются в портал Azure во время регистрации приложения и настроены для доступа к ресурсам Azure, таким как Azure DevOps. Добавив субъект-службу в организацию и настроив разрешения на их основе, мы можем определить, авторизован ли субъект-служба для доступа к ресурсам организации и каким из них.

Управляемые удостоверения — это еще одна функция Microsoft Entra, которая действует аналогично субъектам-службам приложения. Эти объекты предоставляют удостоверения для ресурсов Azure и позволяют легко использовать службы, поддерживающие проверку подлинности Microsoft Entra для предоставления общего доступа к учетным данным. Это привлекательный вариант, так как идентификатор Microsoft Entra id заботится об управлении учетными данными и смене учетных данных. Хотя настройка управляемого удостоверения может отличаться в портал Azure, Azure DevOps обрабатывает оба объекта безопасности так же, как новое удостоверение в организации с определенными разрешениями. В остальной части этой статьи мы ссылаемся на управляемые удостоверения и субъекты-службы взаимозаменяемо в качестве субъекта-службы, если они не указаны.

Выполните следующие действия, чтобы пройти проверку подлинности этих удостоверений в Azure DevOps, чтобы разрешить им выполнять действия от имени себя.

Настройка управляемых удостоверений и субъектов-служб

Реализация может отличаться, но на высоком уровне следующие шаги помогут вам приступить к использованию субъектов-служб в рабочем процессе. Рассмотрим один из примеров приложений, которые следует использовать вместе с примером самостоятельно.

1. Создание нового управляемого удостоверения или субъекта-службы приложений

Создайте субъект-службу приложения или управляемое удостоверение в портал Azure.

Создание субъекта-службы приложений

При создании регистрации приложения объект приложения создается в идентификаторе Microsoft Entra. Субъект-служба приложения представляет этот объект приложения для данного клиента. При регистрации приложения в качестве мультитенантного приложения существует уникальный объект субъекта-службы, представляющий объект приложения для каждого клиента, к которому добавляется приложение.

Дополнительные сведения:

• Сведения об объектах приложения и субъекта-службы в Microsoft Entra ID
• Защита субъектов-служб
• Создание приложения Microsoft Entra и субъекта-службы с доступом к ресурсам с помощью портала

Создание управляемого удостоверения

Создание управляемых удостоверений в портал Azure значительно отличается от настройки приложений с помощью субъектов-служб. Прежде чем начать процесс создания, необходимо сначала рассмотреть тип управляемого удостоверения, который необходимо создать:

• Назначаемое системой управляемое удостоверение: некоторые службы Azure позволяют включить управляемое удостоверение непосредственно в экземпляре службы. При включении управляемого удостоверения, назначаемого системой, удостоверение создается в идентификаторе Microsoft Entra. Это удостоверение привязано к жизненному циклу этого экземпляра службы. Поэтому при удалении ресурса Azure автоматически удаляет удостоверение. Только один конкретный ресурс Azure может использовать это удостоверение для получения токенов Microsoft Entra ID.
• Назначаемое пользователем управляемое удостоверение можно также создать управляемое удостоверение как автономный ресурс Azure, создав управляемое удостоверение, назначаемое пользователем, и назначив его одному или нескольким экземплярам службы Azure. Если используются управляемые удостоверения, назначаемые пользователем, управление таким удостоверением осуществляется отдельно от ресурсов, которые его используют.

Дополнительные сведения см. в следующих статьях и видео:

• Что такое управляемые удостоверения для ресурсов Azure?
• Управление управляемыми удостоверениями, назначаемыми пользователем
• Настройка управляемых удостоверений для ресурсов Azure на виртуальной машине с помощью портал Azure

2. Добавление субъекта-службы в организацию Azure DevOps

После настройки субъектов-служб в Центре администрирования Microsoft Entra необходимо сделать то же самое в Azure DevOps, добавив субъекты-службы в вашу организацию. Их можно добавить на странице "Пользователи" или с помощью API ServicePrincipalEntitlements. Так как они не могут входить в интерактивном режиме, учетная запись пользователя, которая может добавлять пользователей в организацию, проект или команду, должна добавить их. Такие пользователи включают администраторов коллекции проектов (PCA) или администраторов проектов и администраторов команд, когда включена политика "Разрешить администраторам команд и проектов приглашать новых пользователей".

Совет

Чтобы добавить субъект-службу в организацию, введите отображаемое имя приложения или управляемого удостоверения. Если вы решили программно добавить субъект-службу через ServicePrincipalEntitlements API, обязательно передайте идентификатор объекта субъекта-службы, а не идентификатор объекта приложения.

Если вы являетесь PCA, вы также можете предоставить субъекту-службе доступ к определенным проектам и назначить лицензию. Если вы не pcA, необходимо обратиться к PCA, чтобы обновить все членства в проекте или уровни доступа к лицензиям.

Примечание.

Вы можете добавить только управляемое удостоверение или субъект-службу для клиента, к которому подключена ваша организация. Чтобы получить доступ к управляемому удостоверению в другом клиенте, ознакомьтесь с обходным решением в разделе часто задаваемых вопросов.

3. Настройка разрешений для субъекта-службы

После добавления субъектов-служб в организацию их можно обрабатывать аналогично стандартным учетным записям пользователей. Вы можете назначить разрешения непосредственно субъекту-службе, добавить его в группы безопасности и команды, назначить его любому уровню доступа и удалить его из организации. Можно также использовать Service Principal Graph APIs для выполнения операций CRUD с субъектами-службами.

Это может отличаться от способа настройки разрешений приложения в приложении Microsoft Entra для других ресурсов Azure. Azure DevOps не зависит от настройки "Разрешения приложения", доступной для регистрации приложений через портал Azure. Эти разрешения приложения применяют разрешения для субъекта-службы во всех организациях, связанных с клиентом, и не имеют знаний о дополнительных разрешениях организации, проекта или объекта, доступных в Azure DevOps. Чтобы предложить субъекты-службы более детализированные разрешения, мы опираемся на собственную модель разрешений вместо этого с помощью идентификатора Entra.

4. Управление субъектом-службой

Управление субъектами-службами отличается от учетных записей пользователей следующими ключевыми способами:

• Субъекты-службы не имеют сообщений электронной почты и таким образом, они не могут быть приглашены в организацию по электронной почте.
• Правила групп для лицензирования в настоящее время не применяются к субъектам-службам. Если вы хотите назначить уровень доступа субъекту-службе, лучше всего сделать это напрямую.
• Хотя субъекты-службы можно добавить в группы Microsoft Entra (в портал Azure), у нас есть текущее техническое ограничение, предотвращающее возможность отображения их в списке членов группы Microsoft Entra. Это ограничение не верно для групп Azure DevOps. Это говорится, что субъект-служба по-прежнему наследует все разрешения группы, заданные на основе группы Microsoft Entra, к которой они принадлежат.
• Не все пользователи в группе Microsoft Entra немедленно входят в организацию Azure DevOps, так как администратор создает группу и добавляет в нее группу Microsoft Entra. У нас есть процесс под названием "материализация", который происходит после первого входа пользователя из группы Microsoft Entra в организацию. Пользователь, войдите в организацию, позволяет определить, какие пользователи должны предоставлять лицензию. Так как вход недоступна для субъектов-служб, администратор должен явно добавить его в организацию, как описано ранее.
• Вы не можете изменить отображаемое имя субъекта-службы или аватар в Azure DevOps.
• Субъект-служба считается лицензией для каждой организации, к ней добавляется, даже если выбрано выставление счетов с несколькими организациями .

5. Доступ к ресурсам Azure DevOps с помощью маркера идентификатора Microsoft Entra

Получение маркера идентификатора Microsoft Entra

Получение маркера доступа для управляемого удостоверения можно сделать, следуя инструкциям в документации по идентификатору Microsoft Entra. Дополнительные сведения см. в примерах для субъектов-служб и управляемых удостоверений.

Возвращаемый маркер доступа — это JWT с определенными ролями, которые можно использовать для доступа к ресурсам организации с помощью маркера в качестве носителя.

Использование маркера идентификатора Microsoft Entra для проверки подлинности в ресурсах Azure DevOps

В следующем примере видео мы переходим от проверки подлинности с помощью PAT к использованию маркера из субъекта-службы. Начнем с использования секрета клиента для проверки подлинности, а затем перейдите к использованию сертификата клиента.

• Хотя субъекты-службы можно добавить в группы идентификаторов Microsoft Entra (в портал Azure), у нас есть текущее техническое ограничение, предотвращающее возможность отображения их в списке участников группы идентификаторов Microsoft Entra. Это ограничение не верно для групп Azure DevOps. Это говорится, что субъект-служба по-прежнему наследует все разрешения группы, заданные поверх группы идентификаторов Microsoft Entra ID, к которой они принадлежат.
• Не все пользователи в группе идентификаторов Microsoft Entra немедленно входят в организацию Azure DevOps, так как администратор создает группу и добавляет в нее группу идентификаторов Microsoft Entra. У нас есть процесс "материализация", который происходит после первого входа пользователя из группы идентификаторов Microsoft Entra ID в организацию. Пользователь, войдите в организацию, позволяет определить, какие пользователи должны предоставлять лицензию. Так как вход недоступна для субъектов-служб, администратор должен явно добавить его в организацию, как описано ранее.
• Вы не можете изменить отображаемое имя субъекта-службы или аватар в Azure DevOps.
• Субъект-служба считается лицензией для каждой организации, к ней добавляется, даже если выбрано выставление счетов с несколькими организациями .

В другом примере показано, как подключиться к Azure DevOps с помощью управляемого удостоверения, назначаемого пользователем, в функции Azure.

Следуйте этим примерам, найдя код приложения в нашей коллекции примеров приложений.

Субъекты-службы можно использовать для вызова REST API Azure DevOps и выполнения большинства действий, но это ограничено следующими операциями:

• Субъекты-службы не могут быть владелец организации или создавать организации.
• Субъекты-службы не могут создавать маркеры, такие как личные маркеры доступа (PATs) или ключи SSH. Они могут создавать собственные маркеры идентификатора Microsoft Entra, и эти маркеры можно использовать для вызова REST API Azure DevOps.
• Мы не поддерживаем Azure DevOps OAuth для субъектов-служб.

Примечание.

Вы можете использовать только идентификатор приложения, а не URI ресурсов, связанные с Azure DevOps для создания маркеров.

Вопросы и ответы

Общие

Вопрос. Почему вместо PAT следует использовать субъект-службу или управляемое удостоверение?

Ответ. Многие из наших клиентов ищут субъект-службу или управляемое удостоверение, чтобы заменить существующий PAT (личный маркер доступа). Такие PAT часто принадлежат учетной записи службы (общей учетной записи группы), которая использует их для проверки подлинности приложения с помощью ресурсов Azure DevOps. PaTs должны быть трудоемко поворачиваются каждые так часто (минимум 180 дней). Так как PATs — это просто маркеры носителя, то есть строки маркеров, представляющие имя пользователя и пароль, они невероятно рискованные использовать, так как они могут легко попасть в руки неправильного человека. Срок действия маркеров Microsoft Entra истекает каждый час и должен быть повторно создан с помощью маркера обновления, чтобы получить новый маркер доступа, который ограничивает общий фактор риска при утечке.

Невозможно использовать субъект-службу для создания личного маркера доступа.

Вопрос. Каковы ограничения скорости для субъектов-служб и управляемых удостоверений?

Ответ. В настоящее время субъекты-службы и управляемые удостоверения имеют те же ограничения скорости, что и пользователи.

Вопрос. Будет ли использовать эту функцию дороже?

Ответ. Субъекты-службы и управляемые удостоверения оцениваются так же, как пользователи, на основе уровня доступа. Одно из важных изменений относится к обработке "выставления счетов с несколькими организациями" для субъектов-служб. Пользователи считаются только одной лицензией, независимо от того, сколько организаций они в ней. Субъекты-службы считаются одной лицензией для каждой организации, в которую входит пользователь. Этот сценарий аналогичен стандартному "выставлению счетов на основе назначений пользователей".

Вопрос. Можно ли использовать субъект-службу или управляемое удостоверение с Помощью Azure CLI?

Ответ. Да. В любом месте, где запрашивается доступ к PAT в Azure CLI , также можно принять маркеры доступа к идентификатору Microsoft Entra. В этих примерах описано, как можно передать маркер Microsoft Entra для проверки подлинности с помощью CLI.

# 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

Теперь давайте получим маркер Microsoft Entra (UUID 499b84ac-1321-427f-aa17-267ca6975798ресурса Azure DevOps) и попытаемся вызвать API Azure DevOps, передав его в заголовки в виде Bearer маркера:

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

Теперь вы можете использовать az cli команды для обычных.

Вопрос. Можно ли добавить управляемое удостоверение из другого клиента в мою организацию?

Ответ. Вы можете добавить управляемое удостоверение только из того же клиента, к которому подключена ваша организация. Однако у нас есть обходное решение, позволяющее настроить управляемое удостоверение в клиенте ресурсов, где находятся все ресурсы. Затем вы можете включить его использование субъектом-службой в целевом клиенте, где подключена ваша организация. Выполните следующие действия в качестве обходного решения.

1. Создайте управляемое удостоверение, назначаемое пользователем, в портал Azure для клиента ресурсов.
2. Подключите его к виртуальной машине и назначьте этому управляемому удостоверению .
3. Создайте хранилище ключей и создайте сертификат (не может иметь тип PEM). При создании этого сертификата также создается секрет с тем же именем, который мы используем позже.
4. Предоставьте доступ к управляемому удостоверению, чтобы он смог прочитать закрытый ключ из хранилища ключей. Создайте политику доступа в хранилище ключей с разрешениями Get/List (в разделе "Секретные разрешения" и найдите управляемое удостоверение в разделе "Выбор субъекта".
5. Скачайте созданный сертификат в формате CER, который гарантирует, что он не содержит частную часть сертификата.
6. Создайте регистрацию приложения в целевом клиенте.
7. Отправьте скачанный сертификат в это новое приложение на вкладке "Сертификаты и секреты".
8. Добавьте субъект-службу этого приложения в организацию Azure DevOps, к которой мы хотим получить доступ и не забудьте настроить субъект-службу с любыми необходимыми разрешениями.
9. Чтобы получить маркер доступа Microsoft Entra из этого субъекта-службы, который использует сертификат управляемого удостоверения, см. следующий пример кода:

Примечание.

Необходимо регулярно менять сертификаты, как всегда.

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

Вопрос. Можно ли использовать субъект-службу для подключения к веб-каналам?

Ответ. Да, вы можете подключиться к любому веб-каналу Артефактов Azure с помощью субъекта-службы. В следующих примерах показано, как подключиться к маркеру идентификатора Microsoft Entra для NuGet, npm и Maven, но другие типы веб-каналов также должны работать.

Настройка проекта NuGet с помощью токена Microsoft Entra

1. Убедитесь, что у вас есть последняя версия NuGet.

2. Скачайте и установите поставщик учетных данных Azure Artifacts:

   • Windows

   • Linux или Mac

3. Добавьте файл nuget.config в проект в ту же папку, что и CSPROJ или файл .sln:

   • Веб-канал с областью действия проекта:

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

   • Веб-канал с областью действия организации:

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

4. Задайте переменную среды ARTIFACTS_CREDENTIALPROVIDER_FEED_ENDPOINTS, как показано ниже, указав URL-адрес веб-канала, идентификатор приложения (клиента) субъекта-службы и путь к сертификату субъекта-службы:

   • PowerShell:

     $env:ARTIFACTS_CREDENTIALPROVIDER_FEED_ENDPOINTS = @'
     {
       "endpointCredentials": [
         {
           "endpoint": "<FEED_URL>",
           "clientId": "<SERVICE_PRINCIPAL_APPLICATION_(CLIENT)_ID>",
           "clientCertificateFilePath": "<SERVICE_PRINCIPAL_CERTIFICATE_PATH>"
         }
       ]
     }
     '@
     

   • Bash:

     export ARTIFACTS_CREDENTIALPROVIDER_FEED_ENDPOINTS='{
       "endpointCredentials": [
         {
           "endpoint": "<FEED_URL>",
           "clientId": "<SERVICE_PRINCIPAL_APPLICATION_(CLIENT)_ID>",
           "clientCertificateFilePath": "<SERVICE_PRINCIPAL_CERTIFICATE_PATH>"
         }
       ]
     }'
     

Настройка проекта npm с токенами Microsoft Entra

Примечание.

Средство vsts-npm-auth не поддерживает маркеры доступа Microsoft Entra.

1. Добавьте в .npmrc проект тот же каталог, что и ваш package.json.

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

2. Получите маркер доступа для субъекта-службы или управляемого удостоверения.

3. Добавьте этот код в ${user.home}/.npmrc заполнитель [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] и замените маркер доступа на предыдущий шаг.

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

Настройка проекта Maven с токенами Microsoft Entra

1. Добавьте репозиторий как в ваши, так pom.xml<repositories> и <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. Получите маркер доступа для субъекта-службы или управляемого удостоверения.

3. Добавьте или измените settings.xml файл и ${user.home}/.m2 замените заполнитель [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] маркером доступа на предыдущем шаге.

   <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

Вопрос. Можно ли использовать субъект-службу для публикации расширений в Visual Studio Marketplace?

Ответ. Да. Выполните следующие действия.

1. Добавьте субъект-службу в качестве участника в учетную запись издателя. Идентификатор субъекта-службы можно получить из своего профиля с помощью профилей — Get. Затем вы можете добавить субъект-службу в качестве члена издателя с помощью идентификатора из предыдущего шага.

2. Публикация расширения с помощью TFX CLI с помощью sp. Выполните следующую команду TFX CLI, чтобы использовать маркер доступа к поставщику службы :

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

Pipelines

Вопрос. Можно ли использовать управляемое удостоверение в подключении к службе? Как проще повернуть секреты для субъекта-службы в подключении к службе? Можно ли вообще не хранить секреты в подключении к службе?

поддержка Azure федерации удостоверений рабочей нагрузки с помощью протокола OpenID Connect, что позволяет создавать подключения к службам без секретов в Azure Pipelines, поддерживаемые субъектами-службами или управляемыми удостоверениями с федеративными учетными данными в идентификаторе Microsoft Entra. В рамках выполнения конвейер может обмениваться собственным внутренним маркером с маркером Microsoft Entra, тем самым получая доступ к ресурсам Azure. После реализации этот механизм рекомендуется в продукте по сравнению с другими типами подключений служб Azure, которые существуют сегодня. Этот механизм также можно использовать для настройки развертывания без секретов с любым другим поставщиком услуг, совместимым с OIDC. Этот механизм находится в предварительной версии.

Repos

Вопрос. Можно ли использовать субъект-службу для выполнения операций git, таких как клонирование репозитория?

Ответ. См. следующий пример того, как мы передали маркер идентификатора Microsoft Entra субъекта-службы вместо GIT клонировать репозиторий в скрипте 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}

Совет

Чтобы обеспечить безопасность маркера, используйте диспетчеры учетных данных, чтобы не вводить учетные данные каждый раз. Мы рекомендуем Git Credential Manager, который может принимать токены Microsoft Entra (то есть токены Microsoft Identity OAuth) вместо PATS, если переменная среды изменена.

Полезный совет по получению маркера доступа из Azure CLI для вызова получения git:

1. Откройте конфигурацию Git репозитория:

git config -e

1. Добавьте следующие строки, где идентификатор 00000000-0000-0000-0000-000000000000UUID ресурса Azure DevOps:

[credential]
    helper = "!f() { test \"$1\" = get && echo \"password=$(az account get-access-token --resource     00000000-0000-0000-0000-000000000000 --query accessToken -o tsv)\"; }; f" 

1. Проверьте, работает ли он с помощью:

GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Потенциальные ошибки

Не удалось создать субъект-службу с идентификатором объекта "{provided objectId}"

Субъект-служба отсутствует в provided objectId клиенте, подключенном к вашей организации. Одна из распространенных причин заключается в том, что вы передаете идентификатор объекта регистрации приложения, а не идентификатор объекта субъекта-службы. Помните, что субъект-служба — это объект, представляющий приложение для данного клиента, это не само приложение. Его service principal object ID можно найти на странице корпоративных приложений клиента. Найдите имя приложения и выберите результат Enterprise Application, который возвращается. Этот результат является страницей субъекта-службы или корпоративного приложения, и вы можете использовать идентификатор объекта, найденный на этой странице, для создания субъекта-службы в Azure DevOps.

Доступ запрещен: {ID of the caller identity} требует следующих разрешений для пользователей ресурсов для выполнения этого действия: добавление пользователей

Эта ошибка может быть вызвана одной из следующих причин:

• Вы не являетесь владельцем организации, администратора коллекции проектов или администратора группы.
• Вы являетесь администратором проекта или команды, но политика "Разрешить администраторам команд и проектов приглашать новых пользователей" отключена.
• Вы являетесь администратором проекта или команды, который может пригласить новых пользователей, но вы пытаетесь назначить лицензию при приглашении нового пользователя. Администраторы проекта или команды не могут назначать лицензию новым пользователям. Любой новый приглашенный пользователь добавляется на уровне доступа по умолчанию для новых пользователей. Обратитесь к PCA, чтобы изменить уровень доступа к лицензии.

API списка графов Azure DevOps возвращает пустой список, даже если мы знаем, что в организации есть субъекты-службы.

API списка графов Azure DevOps может возвращать пустой список, даже если для возврата все еще есть больше страниц пользователей. continuationToken Используйте для итерации по спискам, и вы можете в конечном итоге найти страницу, на которой возвращаются субъекты-службы. continuationToken Если возвращается, это означает, что через API доступны дополнительные результаты. Хотя у нас есть планы улучшить эту логику, на данный момент возможно, что первые результаты X возвращают пустые.

TF401444. Войдите по крайней мере один раз как {tenantId'tenantId\servicePrincipalObjectId'} в веб-браузере, чтобы включить доступ к службе.

Если субъект-служба не был приглашен в организацию, может возникнуть следующая ошибка. Убедитесь, что субъект-служба добавляется в соответствующую организацию и имеет все разрешения, необходимые для доступа к любым необходимым ресурсам.

Связанные статьи

• Ссылка на примеры приложений
• Справочник по API прав субъектов-служб
• Справочник по API Graph субъекта-службы