Подключения службы Azure DevOps: как их настроить и использовать

При использовании Azure DevOps для управления конвейерами инфраструктуры как кода (IaC) или обычных приложений CI/CD (непрерывные улучшения/непрерывная разработка) администратор облака должен потратить некоторое время на настройку конвейеров для аутентификации в Microsoft Azure для выполнения желаемых развертываний.. Иногда этот процесс упускают из виду, потому что он кажется тривиальным, когда у вас есть все привилегии. Давайте создадим простой конвейер выпуска с одной задачей развертывания шаблона ARM, как показано на изображении ниже, чтобы понять, как настраиваются подключения службы Azure DevOps.
При редактировании или создании нового конвейера выпуска нажмите «Задачи» (элемент 1), и под ним появится список задач. В нашем случае мы добавили пару развертываний шаблона ARM (пункт 2). По умолчанию при добавлении задача развертывания шаблона ARM потребует некоторого внимания. Это связано с подключением между Azure DevOps и платформой Azure (подписка или группа управления).
Выберите одну из доступных подписок в разделе «Доступные подписки Azure» и нажмите «Авторизовать».
Субъект-служба будет создана в фоновом режиме в клиенте Azure Active Directory. Имя по умолчанию будет иметь префикс, начинающийся с имени организации Azure DevOps, за которым следует тире «—» и имя проекта Azure DevOps.
Тот же субъект-служба будет добавлен в качестве роли участника на уровне подписки, как показано на изображении ниже.
Примечания с мест. Если вы открываете подписку и видите много записей, которые соответствуют вашей организации Azure DevOps и названиям проектов, вы знаете, откуда берутся эти записи.
Схема подключения к сервису
Дизайн должен соответствовать требованиям вашей организации. При использовании групп управления мы можем назначить сервисное подключение определенному уровню, и всем подпискам ниже автоматически будет назначено разрешение.
Некоторые компании предпочитают создавать сервисные подключения для каждой подписки. Это помогает контролировать представление любого заданного субъекта-службы для конкретной подписки. При настройке конвейера нам нужно выбрать те, которые соответствуют среде/подписке.
Правильный дизайн экономит время и решает проблему слишком большого количества сервисных подключений. Я всегда стараюсь, чтобы это число было как можно меньше. Таким образом, легко искать журналы и узнавать, какой процесс Azure DevOps развертывает тот или иной ресурс в Microsoft Azure.
Управление сервисными подключениями
Целью любого конвейера Azure DevOps является сокращение количества субъектов-служб и разрешений на уровне вашей подписки или группы управления, которые не требуются. Мы можем воспользоваться преимуществами подключений к службам в Azure DevOps, чтобы уменьшить количество записей разрешений в любой данной подписке.
Каждый раз, когда мы авторизуем новый конвейер в Azure DevOps, в рамках этого процесса будет создаваться новое подключение к службе.
Чтобы понять сервисные подключения, мы можем начать с создания нашего первого. Вот как это сделать. Войдите на портал Azure DevOps, перейдите к любому заданному проекту и щелкните Параметры проекта. В новой области «Настройки проекта» щелкните элемент подключения к службе, и отобразится список всех доступных подключений к службе. Чтобы создать новую, нажмите на кнопку «Новое подключение к услуге», расположенную в правом верхнем углу.
На новой странице выберите Azure Resource Manager и нажмите Далее. На новой странице выберите Service Principal (automatic) и нажмите Next.
Мы можем настроить область действия (подписка, группа управления или рабочая область машинного обучения), выбрать нужную группу управления и определить имя и описание на новой странице. Наконец, мы можем разрешить использование этого сервисного подключения всеми конвейерами в текущем проекте, установив флажок «Предоставить разрешение на доступ ко всем конвейерам» (пожалуйста, сделайте это). По завершении нажмите Сохранить.
Примечание. Если в вашем подходе используется область подписки, обязательно выберите подписку и выберите нужную подписку.
После создания подключения к службе мы можем щелкнуть по нему и двум важным ссылкам, чтобы сохранить его. Первый — Manage Service Connection Roles, который перенаправит нас на RBAC (управление доступом на основе ролей к данной подписке для проверки разрешений), а второй — Manage Service Principal — откроет новую страницу с блейд-сервер субъекта-службы, который используется для этого подключения к службе.
Самое главное — уметь идентифицировать сервисное подключение в RBAC и логах. Мы можем настроить это, нажав «Брендинг» (элемент 1), введя новое имя (элемент 2) и «Сохранить» (элемент 3).
Тестирование нового подключения к сервису
Теперь, когда мы создали новое подключение к службе на уровне группы управления и управляли новым именем (элемент 2), мы можем использовать новое подключение к службе. В результате мы можем увидеть все подписки, к которым имеют доступ сервисные соединения (пункт 3) с одной записью.
Совместное использование подключений службы Azure DevOps
Мы определили сервисное соединение, которое соответствует нашим требованиям безопасности. Мы пометили его соответствующим образом, и команда, потребляющая его на конвейере, довольна. Однако вы заметите, что подключение к сервису по умолчанию находится внутри определенного проекта, и это отстой, если мы попытаемся использовать это красивое подключение к сервису, над которым мы так усердно работали, что оно не будет отображаться.
В Azure DevOps есть функция совместного использования подключений к службам. Это удобно в организациях Azure DevOps с несколькими проектами, требующими одинаковых разрешений для развертывания кода в Azure. Процесс прост, перейдите к подключению к нужному сервису, нажмите кнопку … и выберите «Безопасность».
На новой странице перейдите к разрешениям проекта, нажмите кнопку + и выберите проект из списка. После этого подключение к сервису будет отображаться как Shared и будет доступно во всех определенных вами проектах.
Подключения службы Azure DevOps упрощают вашу жизнь
В этой статье мы рассмотрели простую, но фундаментальную функцию — подключение службы Azure DevOps. При правильном использовании это упрощает ваши разрешения RBAC на уровне подписки/группы управления, и есть вероятность, что вы не увидите много странных имен при просмотре своих разрешений.
Одно важное замечание: когда я писал раздел о дизайне этой статьи, использование групп управления для некоторых может стать серебряной пулей для решения всех проблем, верно? К сожалению, есть пара предостережений. Он отлично работает для развертываний ARM. Однако некоторые конвейерные задачи, такие как Key Vault, веб-приложение и т. д., ограничены уровнем подписки. По замыслу они не видят группы управления.
На изображении ниже мы смотрим на веб-приложение (элемент 1) и видим, что у области нет параметра, как в развертываниях ARM. Таким образом, нам, возможно, придется создать новое подключение службы для использования с этим типом ресурса.