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

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

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

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

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

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

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

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

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

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

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

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

Скачать SVG-файл с этой схемой.

Архитектура

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

Скачайте SVG-файл для этой архитектуры.

Workflow

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

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

   Мы интегрируем Azure DevOps с идентификатором Microsoft Entra, чтобы иметь один уровень для удостоверения. Это означает, что разработчик использует одну и ту же учетную запись 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)	Рабочая среда (Resource Manager)
   veggies-devs-group	Владелец	Читатель
   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.

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

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

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

6. Подключения служб

   В Azure DevOps подключение службы — это универсальная оболочка для учетных данных. Мы создаем подключение службы, содержащее идентификатор клиента субъекта-службы и секрет клиента. При необходимости средства Администратор istrator могут настроить доступ к защищенному ресурсу, например при необходимости, когда требуется утверждение человека перед развертыванием. В этой эталонной архитектуре есть два средства для минимальной защиты подключения службы.

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

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

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

Компоненты

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

Альтернативные варианты

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

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

В этом сценарии в качестве "инфраструктуры как код" (IaC) используется Terraform. Вместо этого решения можно использовать Jenkins, Ansible или Chef.

Рекомендации

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

Скачать SVG-файл с этим рабочим процессом.

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

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

1. Защитите среду с помощью политик ветвей

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

При планировании комплексной модели управления привилегированные пользователи (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. Создайте назначения ролей RBAC в Azure для субъектов-пользователей и согласуйте их с этими субъектами с минимальными правами.

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

Рассмотрите возможность использования для субъектов-служб Azure Pipelines настраиваемой роли, которая предотвращает снятие блокировок с ресурсов и выполнение других разрушительных действий там, где это не предусмотрено.

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 и начальной загрузке Azure DevOps с помощью одной инфраструктуры в качестве средства кода.

Исходный код и подробные инструкции см. на странице репозитория GitHub Демонстрация: управление в Azure — от DevOps до ARM.

Цены

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

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

Соавторы

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

Автор субъекта:

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

Следующие шаги

• Зайдите в репозиторий кода для этого сценария на странице Демонстрация: управление в Azure — от DevOps до ARM.
• Ознакомьтесь с руководствами по управлению облаком в разделе, посвященном Cloud Adoption Framework.
• Что такое управление доступом на основе ролей в Azure (RBAC)?
• Cloud Adoption Framework: управление доступом к ресурсам в Azure
• Роли Azure Resource Manager
  • Владелец (встроенная)
  • Участник (встроенная)
  • Читатель (встроенная)
  • Настраиваемая роль
• Группы безопасности Azure DevOps
  • Администратор истаторы проектов
  • Участник
  • Читатель

Связанные ресурсы

• Проектирование конвейера CI/CD с помощью Azure DevOps
• Цепочка обеспечения сохранности для компьютерной криминалистики в Azure
• Гибридное управление и развертывание Azure Arc для кластеров Kubernetes
• служба автоматизации Azure в гибридной среде
• Управление обновлениями в службе автоматизации Azure
• Обзор видов архитектуры Azure — CI/CD