Где выполнять политики инфраструктуры: Plan, Apply и Post-Deploy

Вы написали политики инфраструктуры как код. Они проверяют нарушения безопасности, превышение бюджета и соглашения об именовании. Теперь возникает практический вопрос: где именно в вашем пайплайне эти политики должны выполняться?

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

Политика на этапе Plan: ловите проблемы до того, как они возникнут

Первое место для выполнения политик — фаза планирования. В таких инструментах, как Terraform, Pulumi или OpenTofu, фаза plan вычисляет, какие изменения будут внесены в инфраструктуру. Она показывает diff: ресурсы для создания, изменения или удаления. Но фактически еще ничего не изменилось.

Выполнение политик здесь работает как ранний фильтр. Движок политик проверяет запланированные изменения и решает, разрешены ли они. Если разработчик пытается открыть security group на 0.0.0.0/0, политика блокирует это на этапе plan. Если кто-то выбирает дорогой тип инстанса, превышающий бюджетный лимит, политика помечает это. Если имя ресурса не соответствует соглашению об именовании, политика отклоняет его.

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

Вот конкретный пример использования Open Policy Agent (OPA) для применения политики, блокирующей публичные security groups на этапе plan:

# Генерируем план Terraform и конвертируем его в JSON
export TF_VAR_region="us-east-1"
terraform plan -out=plan.tfplan
terraform show -json plan.tfplan > plan.json

# Оцениваем политику: запретить, если у любой security group есть входящий трафик с 0.0.0.0/0
# policy.rego содержит: deny[msg] { ... }
opa eval --data policy.rego --input plan.json "data.terraform.deny"

# Если вывод содержит сообщение deny, завершаем пайплайн с ошибкой
if opa eval --data policy.rego --input plan.json "data.terraform.deny" | grep -q '"result"'; then
  echo "НАРУШЕНИЕ ПОЛИТИКИ: Обнаружена публичная security group. Блокируем развертывание."
  exit 1
fi

Это самое эффективное место для применения политик. Оно экономит время, сокращает потери и поддерживает вашу инфраструктуру в чистоте с самого начала.

Политика на этапе Apply: последний рубеж обороны

Второе место для выполнения политик — фаза apply. Apply — это момент, когда изменения фактически применяются к вашей инфраструктуре. Ресурсы создаются, изменяются или уничтожаются по-настоящему.

Зачем запускать политики снова, если вы уже проверили на этапе plan? Потому что проверки на этапе plan имеют слепые зоны. Они видят только то, что есть в коде. Они не видят фактического состояния вашей инфраструктуры, которое могло измениться вне пайплайна. Кто-то мог вручную изменить ресурс через консоль. Предыдущее развертывание могло оставить ресурсы в неожиданном состоянии. План предполагает определенную отправную точку, но реальность может отличаться.

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

Еще один важный случай использования — шлюзы утверждения (approval gates). На этапе plan политика может обнаружить нарушение и пометить его. Но решение о продолжении или остановке часто принимается на этапе apply. Возможно, нарушение требует одобрения старшего инженера для исключения. Возможно, изменение связано с высоким риском и требует проверки вторым специалистом. Политики на этапе apply могут обеспечивать выполнение таких рабочих процессов.

Думайте о политиках на этапе plan как о профилактике, а о политиках на этапе apply — как о верификации. Нужны и те, и другие.

Политика после развертывания: обнаружение дрейфа и скрытых нарушений

Третье место для выполнения политик — после того, как ресурсы уже запущены. Это пост-деплойная проверка, и она служит другой цели.

Политики на этапах plan и apply ловят нарушения в момент изменения. Но инфраструктура не остается статичной. Кто-то с доступом к консоли может изменить правило security group после развертывания. Новые требования соответствия могут сделать ранее приемлемые ресурсы несоответствующими. Ресурсы, которые предполагались временными, могут все еще работать месяцы спустя, тратя деньги.

Пост-деплойные политики запускаются по расписанию. Каждый час, каждую ночь или каждую неделю они сканируют вашу живую инфраструктуру и сравнивают ее с правилами политик. Любой ресурс, нарушающий правило, попадает в отчет. Отчет отправляется в Slack, на почту или на дашборд. Команда затем исправляет нарушение или удаляет ресурс.

Так вы ловите дрейф конфигурации. Это также способ применять политики, которые невозможно проверить на этапах plan или apply. Например, политика «ни один ресурс не должен быть старше 90 дней без пересмотра» может быть реализована только путем периодического сканирования работающих ресурсов.

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

Как три точки работают вместе

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

Диаграмма ниже показывает, как три контрольные точки политик вписываются в типичный пайплайн инфраструктуры:

flowchart TD A[Коммит кода] --> B[Фаза Plan] B --> C{Проверка политик на этапе Plan} C -->|Успех| D[Фаза Apply] C -->|Ошибка| E[Блокировка и уведомление разработчика] E --> A D --> F{Проверка политик на этапе Apply} F -->|Успех| G[Ресурсы созданы/изменены] F -->|Ошибка| H[Блокировка и запрос утверждения] H --> D G --> I[Пост-деплойное сканирование политик] I -->|Соответствует| J[Непрерывный мониторинг] I -->|Обнаружен дрейф| K[Оповещение команды и исправление] K --> G

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

Все три необходимы для полноценной системы защитных барьеров.

Практический чек-лист

Вот краткая справка по настройке точек выполнения политик в вашем пайплайне:

  • Стадия Plan: Запускайте политики против запланированного diff. Блокируйте изменения, нарушающие правила безопасности, стоимости или именования. Останавливайте пайплайн на ранней стадии.
  • Стадия Apply: Запускайте политики снова перед выполнением изменений. Ловите дрейф и применяйте ручное утверждение для изменений с высоким риском.
  • Пост-деплой: Запланируйте периодическое сканирование политик работающей инфраструктуры. Сообщайте о нарушениях команде. Исправляйте или удаляйте несоответствующие ресурсы.

Вывод

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