Размещенный агент сборки Azure DevOps MSI - PullRequest
0 голосов
/ 25 ноября 2018

У меня есть проект ASP.Net Core 2.1 с тестовым проектом, который содержит несколько интеграционных тестов, для которых требуется / требуется доступ к удостоверению управляемой службы Azure для успешной работы (получение секретов из KeyVault).Я использую размещенный агент сборки Azure DevOps VS2017 для создания проекта для развертывания в службу приложений Azure.Проблема, с которой я сталкиваюсь, заключается в том, что когда тесты запускаются после конвейера сборки, они терпят неудачу, так как доступ MSI недоступен на размещенном агенте сборки.Как я могу настроить соответствующий доступ MSI, необходимый для размещенного агента сборки?Возможно ли это сделать с помощью задачи Powershell или чего-то подобного?

Спасибо!

1 Ответ

0 голосов
/ 27 ноября 2018

Чтобы сделать шаг назад, вы, возможно, уже знаете это, но просто для объяснения моего мыслительного процесса:

Представьте себе, что управляемые идентификаторы услуг - это просто принцип обслуживания (т. Е. Учетные записи служб), которых вы не знаете.пароль и, кроме того, этот пользователь создан для вас и управляется Microsoft.

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

Есть хорошие и плохие новости.Хорошая новость заключается в том, что размещенные агенты, по крайней мере, при использовании задачи Azure PowerShell поставляются с принципалом службы, во многом подобно MSI, пароль которого вы не знаете (если не добавляете секрет), но они приходят заранее для вас.

А в настройках «фазы» вы можете включить «Разрешить доступ через скрипт к токену OAuth», который обеспечивает последующее индивидуальное подключение к Azure RM.

Плохая новость заключается в том, что Microsoft.Azure.Библиотека Services.AppAuthentication, которую, как я полагаю, вы используете, если вы используете MSI, не имеет строки подключения, которая разрешает токен доступа, у нее есть только секрет клиента.

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

Слабым местом является то, что теперь у вас есть положение, когда у субъекта службы агента развертывания теперь есть пароль, которыйкто-то знает, что раньше это было просто вуду между Azure DevOps и Active Directory.

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

Вы можете установить библиотеки AppAuthentication через строки подключения, хранящиеся в настройках среды, что означает отсутствие необходимости изменять код: https://docs.microsoft.com/en-us/azure/key-vault/service-to-service-authentication#connection-string-support

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...