Безопасное развертывание назначений политик Azure

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

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

Кольца развертывания можно упорядочить различными способами. В этом руководстве кольца разделены различными регионами Azure с кольцом 0, представляющими некритичные, низкие расположения трафика и кольцо 5, обозначающее наиболее критически важные, самые высокие расположения трафика.

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

Номера шагов блок-схемы:

1. Выбрав определение политики, назначьте политику на самом высоком уровне, включая все кольца развертывания. Примените селекторы ресурсов, чтобы сузить применимость к наименее критическому кругу с помощью "kind": "resource location" свойства. Настройте тип эффекта audit с помощью переопределений назначений. Пример селектора с расположением eastUS и эффектом как audit:

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ]
     }]
   }],
   "overrides":[{
     "kind": "policyEffect",
     "value": "Audit"
   }]
   

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

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

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

   Например, можно настроить проверку соответствия с помощью других средств в определенном конвейере непрерывной интеграции или непрерывного развертывания (CI/CD).

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

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

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS", "westUS"]
     }]
   }]
   

4. После успешного назначения политики всем кольцам в режиме audit, конвейер должен активировать задачу, которая изменяет эффект политики deny и сбрасывает селекторы ресурсов в расположение, связанное с кольцом 0. Пример селектора с одним регионом и набором эффектов для отмены:

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ]
     }]
   }],
   "overrides":[{
     "kind": "policyEffect",
     "value": "Deny"
   }]
   

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

6. Повторите, включив дополнительные кольца в конфигурацию селектора ресурсов.

7. Повторите этот процесс для всех производственных колец.

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

Номера шагов блок-схемы:

1. Выбрав определение политики, назначьте политику на высшем уровне, включая все этапы развертывания. Примените селекторы ресурсов, чтобы сузить применимость к наименее критическому кругу с помощью "kind": "resource location" свойства. Настройте режим принудительного применения назначения в DoNotEnforce. Пример селектора с eastUS и режимомПрименения в качестве DoNotEnforce:

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ]
     }]
   }],
   "enforcementMode": "DoNotEnforce"
   

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

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

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

   Проверку соответствия можно настроить с помощью других средств в конвейере непрерывной интеграции и непрерывного развертывания (CI/CD).

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

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

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

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS", "westUS"]
     }]
   }]
   

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

   "resourceSelectors": [{
     "name": "SDPRegions",
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ]
     }]
   }],
   "enforcementMode": "Default",
   

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

6. Повторите, включив дополнительные кольца в конфигурацию селектора ресурсов.

7. Повторите этот процесс для всех производственных этапов.

1. В рамках существующего назначения примените переопределения , чтобы обновить версию определения для наименьшего критического круга. Мы используем сочетание переопределений, чтобы изменить версию определения и селекторы в условии переопределений для того, чтобы сузить применимость на основе свойства"kind": "resource location". Все ресурсы, которые находятся за пределами указанных расположений, будут оцениваться по версии, указанной в свойстве верхнего уровня definitionVersion в назначении. Пример переопределения обновляет версию определения на 2.0.* и применяет её только к ресурсам в EastUs.

   "overrides":[{
     "kind": "definitionVersion",
     "value": "2.0.*",
     "selectors": [{
       "kind": "resourceLocation",
       "in": [ "eastus"]
     }]
   }]
   

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

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

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

   Например, можно настроить проверку соответствия с помощью других средств в определенном конвейере непрерывной интеграции или непрерывного развертывания (CI/CD).

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

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

    "overrides":[{
     "kind": "definitionVersion",
     "value": "2.0",
     "selectors": [{
       "kind": "resourceLocation",
       "in": [ "eastus", "westus"]
     }]
   }]
   

4. После добавления всех необходимых местоположений в _selectors можно удалить замещение и обновить свойство definitionVersion в задании.

"properties": {
        "displayName": "Enforce resource naming rules",
        "description": "Force resource names to begin with DeptA and end with -LC",
        "definitionVersion": "2.0.*",
}

• Узнайте, как программно создавать политики.
• Просмотрите Политика Azure как рабочие процессы кода.
• Изучите рекомендации Корпорации Майкрософт по вопросам безопасного развертывания.
• Просмотрите несоответствующие ресурсы с помощью Политика Azure.