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

Разработка Политики Azure как рабочих процессов кода

  • Статья

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

  • Инфраструктура как код. Практика рассмотрения как кода всего содержимого, определяющего вашу среду, от шаблонов Azure Resource Manager (шаблонов ARM) до определений Политики Azure и Azure Blueprints.
  • DevOps: объединение людей, процессов и продуктов для обеспечения непрерывной доставки ценности нашим конечным пользователям.

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

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

Определения и базовые сведения

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

Имена файлов соответствуют определенным частям определений политики или инициатив и другим ресурсам политики:

File format Содержимое файла
policy-v#.json Все определение политики для этой версии
policyset-v#.json Определение всей инициативы для этой версии
policy-v#.parameters.json Часть properties.parameters определения политики
policyset-v#.parameters.json Часть properties.parameters определения инициативы
policy-v#.rules.json Часть properties.policyRule определения политики
policyset-v#.definitions.json Часть properties.policyDefinitions определения инициативы
exemptionName.json Исключение политики, предназначенное для определенного ресурса или области

Обзор рабочих процессов

Рекомендуемый стандартный рабочий процесс "Политика Azure как код" представлен на следующей схеме.

Схема, демонстрирующая блоки применения рабочего процесса

Управление исходным кодом

Существующие определения политик и инициатив можно экспортировать различными способами, например с помощью запросов PowerShell, CLI или Azure Resource Graph (ARG ). Среда управления версиями для хранения этих определений может быть одним из многих вариантов, включая GitHub или Azure DevOps.

Создание и обновление определений политик

Определения политик создаются с помощью JSON и хранятся в системе управления версиями. Каждая политика имеет собственный набор файлов, таких как параметры, правила и параметры среды, которые должны храниться в той же папке. Следующая структура является рекомендуемым способом хранения определений политик в системе управления версиями.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

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

Создание и обновление определений инициатив

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

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

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

Примечание.

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

Тестирование и проверка измененного определения

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

Примечание.

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

Назначение должно использовать для режима enforcementMode значение Disabled (отключено), чтобы создание и изменение ресурсов не блокировалось, но все существующие ресурсы по-прежнему проверялись на соответствие обновленному определению политики. Даже при использовании enforcementMode рекомендуется, чтобы область назначения являлась специально выделенной для тестирования группой ресурсов или подпиской.

Примечание.

Хотя режим принудительного применения полезен, он не является заменой тщательного тестирования определения политики при различных условиях. Определение политики необходимо тестировать с помощью вызовов REST API PUT и PATCH, проверки соответствующих и несоответствующих ресурсов, а также проверяя граничные случаи, такие как свойство, отсутствующее в ресурсе.

После развертывания назначения используйте пакет SDK для Политика Azure, задачу оценки безопасности и соответствия требованиям Azure Pipelines или запросы Azure Resource Graph (см. примеры), чтобы получить данные о соответствии новому назначению. Среда, используемая для тестирования политик и назначений, должна иметь ресурсы с различными состояниями соответствия. Как и хороший модульный тест для кода, вы хотите проверить, что ресурсы оцениваются должным образом без ложных срабатываний или ложных отрицательных. При тестировании и проверке только ожидаемых результатов может возникнуть непредвиденное и неопознанное воздействие политики. Дополнительные сведения см. в статье Оценка влияния нового определения политики Azure.

Включение задач исправления

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

Первым шагом для исправления ресурсов является предоставление назначению политики назначения роли, определенного в определении политики. Это назначение ролей дает управляемому удостоверению назначения политики достаточно прав для внесения необходимых изменений для приведения ресурса в состояние соответствия.

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

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

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

Обновление до принудительных назначений

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

Обработка встроенных оценок

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

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

Отзыв

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

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