Комплексное управление в Azure при использовании CI/CD

При разработке модели управления для вашей организации важно помнить, что Azure Resource Manager — это только один способ управления ресурсами. Azure DevOps, а также процессы непрерывной интеграции и автоматизации непрерывной доставки (CI/CD) могут стать непреднамеренной уязвимостью в безопасности, если их не защитить должным образом. Эти ресурсы должны быть защищены зеркальным отображением модели управления доступом на основе ролей (RBAC), используемой для Resource Manager.

Концепция комплексного управления не зависит от поставщика. Реализация, описанная здесь, использует Azure DevOps, но альтернативные варианты также кратко упоминаются.

Потенциальные варианты использования

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

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

• Группы Microsoft Entra, которые соответствуют бизнес-доменам и моделям разрешений
  Организация имеет множество вертикальных бизнес-доменов, таких как "фрукты" и "овощи", которые работают в значительной степени независимо. В каждом бизнес-домене имеются два уровня доступа или привилегии, которые соответствуют отдельным группам *-admins или *-devs в Microsoft Entra. Это позволяет нацеливаться на разработчиков при настройке разрешений в облаке.

• Среды развертывания
  Каждая команда имеет две среды:

  • Производство. Только администраторы имеют повышенные привилегии.
  • Непроизводственный Все разработчики имеют повышенные привилегии (для поощрения экспериментов и инноваций).

• Цели автоматизации
  Каждое приложение должно реализовать Azure DevOps не только для непрерывной интеграции (CI), но и для непрерывного развертывания (CD). Например, развертывания могут быть автоматически активированы изменениями в репозитории Git.

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

На этой упрощенной схеме показано, как ветви в репозитории Git соотносятся с разработческой, промежуточной и рабочей средами.

Скачайте SVG этой схемы.

Architecture

На этой схеме показано, как связывание с Resource Manager и CI/CD с идентификатором Microsoft Entra является ключом к комплексной модели управления.

Скачайте SVG этой архитектуры.

Замечание

Чтобы упростить понимание концепции, схема иллюстрирует только домен "veggies". Домен "fruits" будет выглядеть аналогично и использовать те же правила именования.

Рабочий процесс

Нумеровка отражает порядок, в котором ИТ-администраторы и архитекторы предприятий думают о своих облачных ресурсах и настраивают их облачные ресурсы.

1. Идентификатор Microsoft Entra

   Мы интегрируем Azure DevOps с Microsoft Entra ID, чтобы иметь единую платформу для удостоверения. Это означает, что разработчик использует одну и ту же учетную запись Microsoft Entra для Azure DevOps и Resource Manager. Пользователи не добавляются по отдельности. Вместо этого членство назначается группами Microsoft Entra, чтобы мы могли удалить доступ разработчика к ресурсам на одном шаге, удалив членство в группах Microsoft Entra. Для каждого домена мы создадим:

   • Группы Microsoft Entra. Две группы на домен (описаны далее на шаге 4 и 5 далее в этой статье).
   • Субъекты-службы. Один явный сервисный принципал для каждой среды.

2. Рабочая среда

   Чтобы упростить развертывание, эта эталонная реализация использует группу ресурсов для представления рабочей среды. На практике следует использовать другую подписку.

   Привилегированный доступ к этой среде ограничен только администраторами.

3. среды разработки

   Чтобы упростить развертывание, эта эталонная реализация использует группу ресурсов для представления среды разработки. На практике следует использовать другую подписку.

4. Назначения ролей в Resource Manager

   Хотя имена групп Microsoft Entra подразумевают роль, элементы управления доступом не применяются до настройки назначения ролей . При этом роль назначается субъекту Microsoft Entra для определенной области. Например, разработчики имеют роль участника в рабочей среде.

   Объект Microsoft Entra	Среда разработки (Resource Manager)	Продуктивная среда (Менеджер ресурсов)
   veggies-devs-group	Owner	Читатель
   veggies-admins-group	Владелец	Владелец
   veggies-ci-dev-sp	Пользовательская роль *	–
   veggies-ci-prod-sp	–	Произвольная роль *

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

   Чтобы понять причину назначений отдельных ролей, ознакомьтесь с разделом рекомендаций далее в этой статье.

5. Назначения групп безопасности в Azure DevOps

   Группы безопасности работают так же, как роли в системе Resource Manager. Воспользуйтесь встроенными ролями и ролью Соавтор для разработчиков по умолчанию. Администраторы получают назначение группе безопасности администратора проекта для повышенных разрешений, позволяя им настраивать разрешения безопасности.

   Обратите внимание, что Azure DevOps и Resource Manager имеют разные модели разрешений:

   • Azure Resource Manager использует модель аддитивных разрешений .
   • Azure DevOps использует модель с минимальными разрешениями .

   По этой причине членство в -admins-devs группах должно быть взаимоисключающим. В противном случае затронутые лица будут иметь меньше доступа, чем ожидалось в Azure DevOps.

   Имя группы	Роль менеджера ресурсов	Роль Azure DevOps
   fruits-all	–	–
   fruits-devs	Contributor	Contributor
   fruits-admins	Владелец	Администраторы проектов
   veggies-all	–	–
   veggies-devs	Contributor	Contributor
   veggies-admins	Владелец	Администраторы проектов
   infra-all	–	–
   infra-devs	Contributor	Contributor
   infra-admins	Владелец	Администраторы проектов

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

   Чтобы понять причину назначений отдельных ролей, ознакомьтесь с разделом рекомендаций далее в этой статье.

6. Сервисные подключения

   В Azure DevOps Service Connection — это универсальная оболочка доступа для учетных данных. Мы создаём подключение службы, которое содержит идентификатор и секрет основных данных службы. Администраторы проектов могут настроить доступ к этому защищенному ресурсу при необходимости, например при необходимости, когда требуется утверждение человека перед развертыванием. Эта эталонная архитектура имеет две минимальные защиты подключения к службе:

   • Администраторы должны настроить права доступа к конвейеру, чтобы управлять тем, какие конвейеры могут получить доступ к учетным данным.
   • Администраторы также должны настроить проверку контроля ветви, чтобы только конвейеры, выполняемые в контексте production ветви, могли использовать prod-connection.

7. Репозитории Git

   Так как подключения к службам привязаны к ветвям с помощью элементов управления филиалами, важно настроить разрешения для репозиториев Git и применить политики ветви. Помимо необходимости успешного прохождения сборок CI, мы также требуем, чтобы пул-реквесты имели не менее двух утверждающих.

Components

• Azure DevOps
• Идентификатор Microsoft Entra
• Диспетчер ресурсов Azure
• Azure Repos
• Azure Pipelines

Alternatives

Концепция комплексного управления не зависит от поставщика. Хотя эта статья посвящена Azure DevOps, Azure DevOps Server можно использовать в качестве локальной замены. Кроме того, можно использовать набор технологий для конвейера разработки CI/CD с открытым исходным кодом, используя такие варианты, как Jenkins и GitLab.

Azure Repos и GitHub — это платформы, созданные для использования системы управления версиями Git с открытым исходным кодом. Хотя их наборы функций несколько отличаются, оба могут быть интегрированы в глобальные модели управления для CI/CD. GitLab — это другая платформа на основе Git, которая обеспечивает надежные возможности CI/CD.

Этот сценарий использует Terraform в качестве инфраструктуры в качестве средства кода (IaC). К альтернативам относятся Дженкинс, Энсибл и Шеф-повар.

Соображения

Чтобы обеспечить комплексное управление в Azure, важно понимать профиль безопасности и разрешений пути от компьютера разработчика к рабочей среде. На следующей схеме показан базовый рабочий процесс CI/CD с помощью Azure DevOps. Значок красной блокировки указывает разрешения безопасности, которые должны быть настроены пользователем. Если не настроить или неправильно настроить разрешения, ваши рабочие процессы станут уязвимыми.

Скачайте SVG этого рабочего процесса.

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

Этапы развертывания	Ответственность	Description
Запросы на внесение изменений	User	Инженеры должны проанализировать свою работу, включая сам код конвейера.
Защита ветви	общих	Настройте Azure DevOps для отклонения изменений, которые не соответствуют определенным стандартам, таким как проверки CI и экспертные рецензии (через pull-запросы).
Конвейер в виде кода	User	Сервер сборки удаляет всю рабочую среду, если код конвейера указывает на это. Чтобы предотвратить это, можно использовать сочетание запросов на включение изменений и правил защиты веток, таких как ручное подтверждение.
Сетевые подключения	общих	Настройте Azure DevOps, чтобы ограничить доступ к этим учетным данным.
Ресурсы Azure	общих	Настройка RBAC в Resource Manager.

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

1. Обеспечьте защиту своих сред с помощью политик веток

Так как исходный код определяет и активирует развертывания, ваша первая строка защиты заключается в защите репозитория управления исходным кодом (SCM). На практике это достигается с помощью Pull Request в сочетании с правилами для веток, которые определяют проверки и требования до принятия кода.

При планировании комплексной модели управления привилегированные пользователи (veggies-admins) будут отвечать за настройку защиты ветви. Распространенные проверки защиты ветвей, используемые для обеспечения безопасности развертываний, включают:

• Требовать успешного выполнения сборки CI. Полезно для установления базового качества кода, таких как линтинг кода, модульные тесты и даже проверки безопасности, включая сканирование на вирусы и проверку учетных данных.

• Требовать проверку коллег Попросите другого человека убедиться, что код работает как задумано. Будьте осторожны при внесении изменений в код конвейера. Объединяйте сборки CI, чтобы сделать взаимные проверки менее утомительными.

Что произойдет, если разработчик пытается отправить непосредственно в продакшен?

Помните, что Git — это распределенная система SCM. Разработчик может выполнять коммит непосредственно в свою локальную production ветку. Но при правильной настройке Git такая отправка будет автоматически отклонена сервером Git. Рассмотрим пример.

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Обратите внимание, что рабочий процесс в примере не зависит от поставщика. Функции запросов на извлечение и защиты веток доступны у нескольких поставщиков SCM, включая Azure Repos, GitHub и GitLab.

После принятия кода в защищенную ветвь следующий уровень элементов управления доступом будет применен сервером сборки (например , Azure Pipelines).

2. Какой доступ требуется субъектам безопасности?

В Azure субъект безопасности может быть субъектом-пользователем или субъектом без интерфейса, например, субъектом-службой или управляемым удостоверением. Во всех средах субъекты безопасности должны следовать принципу наименьших привилегий. Хотя субъекты безопасности могут иметь расширенный доступ в предварительно рабочих средах, рабочие среды Azure должны свести к минимуму постоянные разрешения, пользуясь JIT-доступом и условным доступом Microsoft Entra. Создайте назначения ролей Azure RBAC для субъектов-пользователей в соответствии с этими принципами наименьших привилегий.

Также важно моделировать Azure RBAC отдельно от Azure DevOps RBAC. Цель конвейера — свести к минимуму прямой доступ к Azure. За исключением особых случаев, таких как инновации, обучение и решение проблем, большинство взаимодействий с Azure должны осуществляться с помощью специально созданных и закрытых конвейеров.

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

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

Это распространенная ошибка — назначать агентам сборки CI/CD роль и разрешения владельца. Разрешения участника недостаточно, если конвейер также должен выполнять назначения ролей удостоверений или другие привилегированные операции, такие как управление политикой Key Vault.

Но агент сборки CI/CD может удалить всю производственную среду, если ему дать такую команду. Чтобы избежать необратимых разрушительных изменений, мы создадим пользовательскую роль, которая:

• Удаляет политики доступа Key Vault
• Удаляет блокировки управления , которые по проектированию должны предотвратить удаление ресурсов (общее требование в регулируемых отраслях)

Для этого мы создадим настраиваемую роль и удалим Microsoft.Authorization/*/Delete действия.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Если это удаляет слишком много разрешений для ваших целей, обратитесь к полному списку в официальной документации по операциям поставщика ресурсов Azure и настройте определение роли по мере необходимости.

Развертывание этого сценария

Этот сценарий выходит за рамки Resource Manager. Поэтому мы используем Terraform, который позволяет также создавать главные компоненты в Microsoft Entra ID и запускать Azure DevOps, используя единый инструмент для инфраструктуры как кода.

Для получения исходного кода и подробных инструкций посетите репозиторий на GitHub Governance on Azure Demo - from DevOps to ARM.

Pricing

Затраты Azure DevOps зависят от количества пользователей в организации, которым требуется доступ, а также других факторов, таких как количество одновременных сборок и выпусков, необходимых и количество пользователей. Azure Repos и Azure Pipelines — это функции службы Azure DevOps. Дополнительные сведения см. в цен на Azure DevOps.

В идентификаторе Microsoft Entra тип управления групповым доступом, необходимым для этого сценария, предоставляется в выпусках Premium P1 и Premium P2. Цены на эти уровни рассчитываются за каждого пользователя. Дополнительные сведения см. в ценах на Microsoft Entra.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основной автор:

• Джули Нг | Старший инженер службы

Дальнейшие шаги

• Посетите репозиторий кода для этого сценария Governance на Azure Demo - от DevOps до ARM.
• Ознакомьтесь с руководствами по управлению облачными решениями Cloud Adoption Framework.
• Что такое управление доступом на основе ролей Azure (Azure RBAC)?
• Cloud Adoption Framework: управление доступом к ресурсам в Azure
• Роли Azure Resource Manager
  • Владелец (встроенный)
  • Участник (встроенный)
  • Средство чтения (встроенное)
  • Настраиваемая роль
• Группы безопасности Azure DevOps
  • Администраторы проектов
  • Contributor
  • Reader