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

Question

Мне удалось заставить работать приведенный ниже код ( полный код здесь), чтобы использовать управляемую идентификацию Azure для аутентификации (через Visual Studio) и иметь доступ к учетной записи хранения Azure без использования учетных данных.

const string storageResource = "https://storage.azure.com/";

var authResult = await azureServiceTokenProvider.GetAuthenticationResultAsync(storageResource, cancellationToken: cancellationToken);

Коду удалось найти моего пользователя, вошедшего в Visual Studio, и использовать его для получения токена, и все идет хорошо.

Однако этот код выполняется как часть интеграционных тестов библиотеки в конвейере сборки DevOps Azure.

Я нашел субъект-службу, созданный при создании подключения службы к Azure в DevOps Azure, и дал ему то же самое Storage Blob Data Contributor Роль надеялся, что DevOps Azure будет использовать его для запуска кода, но безуспешно.

Итак, мой вопрос:

Как получить код, который выполняется в конвейере сборки DevOps Azure, чтобы иметь возможность аутентификации с использованием AzureServiceTokenProvider?

Кстати, сообщение об ошибке:

Microsoft.Azure.Services.AppAuthentication.AzureServiceTokenProviderException: Параметры: Строка подключения: [Строка подключения не указана], Ресурс: https://storage.azure.com/, Полномочия:. Сообщение об исключении: Попробовал следующие 3 способа получить токен доступа, но ни один из них не сработал. Параметры: Строка подключения: [Строка подключения не указана], Ресурс: https://storage.azure.com/, Полномочия:. Сообщение об исключении: Попытка получить токен с использованием идентификатора управляемой службы. Не удалось получить токен доступа. Не удалось после 5 попыток. MSI ResponseCode: BadRequest, Response: {"error":"invalid_request","error_description":"Identity not found" "} Параметры: Строка подключения: [Строка подключения не указана], Ресурс: https://storage.azure.com/, Орган власти:. Сообщение об исключении: Попытка получить токен с помощью Visual Studio. Не удалось получить токен доступа. Файл поставщика токена Visual Studio не найден в "C:\Users\VssAdministrator\AppData\Local.IdentityService\AzureServiceAuth\tokenprovider.json" Параметры: Строка подключения: [Строка подключения не указана], Ресурс: https://storage.azure.com/, орган:. Сообщение об исключении: попытался получить токен с помощью интерфейса командной строки Azure. Не удалось получить токен доступа. ОШИБКА: Пожалуйста, запустите "az login" для настройки учетной записи.

TearDown: System.NullReferenceException: ссылка на объект не установлена ​​для экземпляра объекта.

Answer 1

Когда вы создаете подключение к службе в Azure DevOps, вам предлагаются (на момент написания) 4 варианта.

• Субъект-служба (также известная как регистрация приложений в Azure Active Directory)
• Управление личностью
• Опубликовать профиль

Профиль публикации - это специальный механизм проверки подлинности службы приложений Azure, который позволяет публиковать через Kudu.

Управлять личностями несколько неправильно обозначены. Они используются, чтобы позволить виртуальной машине, на которой запущены ваши конвейеры Azure, выступать в качестве управляемого удостоверения этой виртуальной машины (затем вы предоставляете этому управляемому удостоверению доступ к ресурсам, к которым он должен иметь доступ на портале Azure). Это несколько отстает от того, как работают другие методы проверки подлинности, но я думаю, это имеет смысл, когда вы размещаете свои собственные конвейеры Azure на виртуальных машинах в Azure. У этого варианта есть этот нюанс.

В AzureServiceTokenProvider будет работать только в среде, которая выставляет MSI_ENDPOINT (он же IDENTITY_ENDPOINT). Размещенные конвейеры Azure DevOps не являются такими средами.

Принципы обслуживания - это то, что вы, скорее всего, будете использовать.

Принципы обслуживания бывают двух видов: автоматические и ручные. Опять же с неправильной маркировкой. На самом деле нет ничего автоматического с автоматическим вариантом, единственное, что происходит, - это то, что он подготавливает субъект-службу в вашем Azure AD для вас. Он предоставит принципалу службы роль участника на уровне подписки (что означает полный доступ ко всему в подписке, кроме управления доступом). Вы не должны предоставлять принципалам службы такой доступ. Это чрезмерно. Помните, что ваши субъекты обслуживания просто защищены учетными данными, и в случае их утечки они позволяют кому-либо нанести непоправимый вред.

Answer 2

Поскольку на этот вопрос пока нет ответа, вы можете попробовать следующее: попробуйте явно передать информацию о подключении в azureServiceTokenProvider. Теперь следующий кодовый блок предполагает, что вы используете общие секретные учетные данные для входа в Azure AD, но может быть расширен на любые описанные здесь методы - проверка подлинности между сервисами в Azure Key Vault с использованием.NET

var azureServicesAuthString = $"RunAs=App;AppId={AppId};TenantId={TenantId};AppKey={ClientSecret}";
tokenProvider = new AzureServiceTokenProvider(connectionString: azureServicesAuthString);
var authResult = await azureServiceTokenProvider.GetAuthenticationResultAsync(storageResource, cancellationToken: cancellationToken);

Answer 3

Вам потребуется создать служебное соединение типа " Проверка подлинности с помощью управляемого удостоверения", чтобы использовать управляемый идентификатор в конвейере DevOps.