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

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

  • Статья

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

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

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

Действия по безопасному развертыванию назначений Политика Azure с запретом или добавлением эффектов

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

Примечание.

Дополнительные сведения о эффектах политики Azure см. в статье "Общие сведения о работе эффектов".

Блок-схема с шагами 1–8, демонстрирующая развертывание безопасных методов развертывания нового определения Политика Azure.

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

  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. Повторите этот процесс для всех рабочих кругов.

Действия по безопасному развертыванию назначений Политика Azure с изменениями или развертыванием эффектовIfNotExists

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

Блок-схема, показывающая шаги 5–9 в рабочем процессе Политика Azure безопасного развертывания.

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

  1. Выбрав определение политики, назначьте политику на уровне высшего уровня, включаемую во все круги развертывания. Примените селекторы ресурсов, чтобы сузить применимость к наименее критическому кругу с помощью "kind": "resource location" свойства. Настройте режим принудительного применения назначения в DoNotEnforce. Пример селектора с расположением и применениемMode в 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 конвейер должен активировать задачу, которая изменяет политику enforcementMode на включение по умолчанию и сбрасывает селекторы ресурсов в расположение, связанное с кольцом 0. Пример селектора с одним регионом и набором эффектов, чтобы запретить:

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

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

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

  7. Повторите этот процесс для всех рабочих кругов.

Действия по безопасному обновлению встроенной версии определения в рамках назначения Политика Azure

  1. В рамках существующего назначения примените переопределения , чтобы обновить версию определения для наименьшего критического круга. Мы используем сочетание переопределения, чтобы изменить определениеVersion и селекторы в условии переопределения, чтобы сузить применимость по свойству"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.*",
}

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