ФОН
Мы собираемся настроить сервер развертывания, который будет использоваться для управления ресурсами Azure. Сервер развертывания будет запускать предопределенные сценарии PowerShell и развертывать ARM-шаблоны.
В этой статье описывается, как использовать субъекты службы и хранилища ключей, чтобы приложение, которое безопасно работает на сервере развертывания, могло выполнять сценарии развертывания.
ПРОБЛЕМА
Зачастую сервер развертывания будет обновляться с помощью сценариев, новых конвейеров, различных типов конфигурации, фрагментов кода, шаблонов и т. Д. При внесении изменений на сервере развертывания мы не хотим, чтобы секреты были раскрыты каким-либо образом.
ПРОХОДНЫЙ ВРЕМЯ ПОДХОД - API-интерфейс ТАМОЖЕННОГО ДОСТУПА
Функциональность, которую мы ищем, может быть реализована с помощью пользовательского API ключа доступа с непрерывным рабочим процессом:
На портале запросов на обслуживание билет развертывания подписывается
утверждающий
Сервер развертывания получает подписанный билет развертывания
Сервер развертывания отправляет подписанный билет в пользовательский доступ
ключ API и получает временный субъект службы и ключ доступа
Сервер развертывания выполняет сценарии (с временной службой
принципал)
Временный участник службы и ключ доступа автоматически
удален
ПОЧЕМУ API-интерфейс ТАМОЖЕННОГО ДОСТУПА?
API-интерфейс ключа доступа добавляет следующие возможности:
По сравнению с сервером развертывания, API занимает меньше места, и мы считаем, что обновления службы будут редкими и могут выполняться очень контролируемым образом.
API может предоставлять доступ к серверу развертывания в зависимости от конкретной потребности (подписка, группа ресурсов и т. Д.)
API может использовать цифровые подписи для проверки первоначального утверждающего билета
РЕКОМЕНДУЕМЫЙ ПОДХОД?
Каков рекомендуемый подход для реализации своевременного доступа для сервера развертывания?