Поделиться через

Подход к тестированию для целевых зон Azure

  • Статья

Примечание.

Эта статья относится только к Microsoft Azure и не применяется к другим предложениям Microsoft Cloud, таким как Microsoft 365 или Microsoft Dynamics 365.

Некоторые организации могут потребовать проверить развертывание платформы целевых зон Azure для Политика Azure определений и назначений, управления доступом на основе ролей (RBAC) настраиваемых ролей и назначений и т. д. Тесты можно выполнить с помощью автоматизации с помощью шаблонов Azure Resource Manager (шаблонов ARM), AzOps, Terraform, Bicep или вручную с помощью портал Azure. Это руководство предоставляет подход, который можно использовать для тестирования изменений и их влияния на развертывание платформы целевых зон Azure.

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

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

Примечание.

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

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

Определение платформы

Внимание

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

Это руководство предназначено только для тестирования на уровне платформы и изменений в контексте целевых зон Azure.

На корпоративном уровне можно разрабатывать и развертывать необходимые компоненты платформы Azure и, таким образом, создавать и эксплуатировать целевые зоны в широком масштабе.

Ресурсы платформы в контексте этой статьи и подхода к тестированию включают следующее:

Продукт или служба Поставщик и тип ресурса
Группы управления Microsoft.Management/managementGroups
Management groups subscription association Microsoft.Management/managementGroups/subscriptions
Определения политик Microsoft.Authorization/policyDefinitions
Определения инициатив или наборов политик Microsoft.Authorization/policySetDefinitions
Назначения политик Microsoft.Authorization/policyAssignments
Определения ролей RBAC Microsoft.Authorization/roleDefinitions
Назначения ролей RBAC Microsoft.Authorization/roleAssignments
Подписки Microsoft.Subscription/aliases

Примеры сценариев и результатов

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

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

Аналогичный сценарий может быть изменением назначений ролей Azure RBAC и членства в группах Microsoft Entra. Перед внесением изменений в рабочей среде может потребоваться форма тестирования.

Внимание

Этот подход к развертыванию или шаблон для большинства клиентов не подходит, Это не обязательно для развертываний целевых зон Azure.

Схема иерархии групп управления с помощью подхода к тестированию канарной среды.

Рисунок 1. Канареечная иерархия групп управления.

Как показано на схеме, вся иерархия групп управления рабочей средой в целевых зонах Azure дублируется под Tenant Root Group. К отображаемым названиям и идентификаторам групп управления добавляется слово canary (канареечная). Идентификаторы должны быть уникальными в одном клиенте Microsoft Entra.

Примечание.

Отображаемые названия групп управления канареечной средой могут совпадать с отображаемыми названиями групп управления рабочей средой. В результате пользователи могут запутаться. В связи с этим рекомендуем добавлять к отображаемым названиям и идентификаторам слово "canary" (канареечный).

Канареечная иерархия групп управления средой используется для упрощения тестирования следующих типов ресурсов:

  • Группы управления
    • Размещение подписки
  • RBAC
    • Роли (встроенные и пользовательские)
    • Назначения
  • Политика Azure
    • Определения (встроенные и пользовательские)
    • Инициативы (также называются определениями наборов)
    • Назначения

Что делать, если вы не хотите развертывать всю канареечную иерархию групп управления средой?

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

Схема подхода тестирования, использующего песочницы.

Рис. 2. Корпоративная иерархия групп управления с указанием песочниц.

Для тестирования Политики Azure и RBAC в этом сценарии необходима одна подписка Azure с ролью RBAC владельца, назначенной удостоверению, которое вы хотите использовать для тестирования, например учетной записи пользователя, субъекту-службе или удостоверению управляемой службы. Такая конфигурация позволит создавать, назначать и исправлять определения и назначения Политики Azure в пределах конкретной подписки песочницы.

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

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

Однако этот подход не позволяет выполнять тестирование, используя наследование политик RBAC и Azure из иерархии групп управления.

Использование одного клиента Microsoft Entra

Рекомендации, которые следует учитывать при использовании одного клиента Microsoft Entra:

  • Следуйте рекомендациям по проектированию корпоративного масштаба для клиентов Microsoft Entra.
    • В одном клиенте Microsoft Entra можно использовать разные группы Microsoft Entra как для рабочих сред, так и для локальных зон Azure с одинаковыми пользователями, назначенными соответствующей иерархии групп управления в одном клиенте Microsoft Entra.
  • Увеличение или дублирование расходов на лицензирование идентификатора Microsoft Entra из-за нескольких удостоверений в разных клиентах Microsoft Entra.
    • Эта точка особенно актуальна для клиентов, использующих функции Microsoft Entra ID P1 или P2.
  • Изменения RBAC будут более сложными как в канарских средах, так и в рабочих средах, так как, скорее всего, пользователи и группы не совпадают как в клиентах Microsoft Entra.
    • Кроме того, идентификаторы пользователей и групп не будут одинаковыми в клиентах Microsoft Entra из-за того, что они глобально уникальны.
  • Снижает сложность и затраты на управление, вызванные управлением несколькими клиентами Microsoft Entra.
    • Привилегированные пользователи, которым нужно сохранять доступ и входить в разные клиенты для выполнения тестирования, могут случайно вносить изменения в рабочую, а не в канареечную среду или наоборот.
  • Уменьшается вероятность отклонения конфигурации и сбоев при развертывании.
  • Не требуется создание дополнительных процессов для обеспечения или аварийного доступа.
  • Снижает трение и время, необходимое для реализации изменений в развертывании целевых зон Azure.

Методические указания по внедрению

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

Предупреждение

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

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

  1. Используйте отдельные субъекты-службы Microsoft Entra (SPN) или управляемые удостоверения службы (MSIs), которые предоставляются разрешения на соответствующую рабочую среду или иерархию групп управления канарной средой.
    • Это руководство соответствует принципу наименьших привилегий (PoLP).
  2. Используйте отдельные папки в репозитории Git, ветви или репозитории для хранения инфраструктуры как кода для рабочей среды и развертывания целевых зон Azure.
    • Использование соответствующих субъектов-служб (SPN) или управляемых удостоверений служб (MSIs) в рамках конвейеров CI/CD в зависимости от того, какая иерархия развертывается.
  3. Реализуйте для канареечной среды такие же политики ветви и средства обеспечения безопасности Git, как для рабочей среды.
    • По возможности можно сократить количество утверждающих и проверок для канареечной среды, чтобы обеспечить устранение ошибок на раннем этапе.
  4. Используйте конвейеры Azure или действия GitHub, которые используют переменные среды для изменений в развертываемой иерархии. Другой вариант — это клонировать конвейеры и корректировать прописанные в коде параметры для определения развертываемой иерархии.
  5. Подготовьте набор канареечных подписок в отдельном отделе и учетной записи EA — при необходимости вы сможете перемещать их по канареечной иерархии групп управления.
    • Не лишним будет набор ресурсов, всегда развернутых в подписках канареечной среды.
    • Также может пригодиться наличие шаблонов инфраструктуры как кода, таких как шаблоны ARM, Bicep или Terraform, создающих набор ресурсов для проверки изменений в канареечной среде.
  6. Отправьте все журналы действий Azure для всех подписок Azure, включая любые подписки на канарную среду, в рабочую среду Azure Log Analytics в соответствии с рекомендациями по проектированию целевых зон Azure.

Совет

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

Это позволяет обеспечить синхронизацию канарной среды с рабочей средой с самого начала. Это легко достигается при использовании средства infrastructure-as-Code вместе с репозиторием git.

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

Узнайте, как реализовать среды песочницы целевой зоны.

Реализация сред песочницы целевой зоны