Когда инфраструктура меняется вне вашего пайплайна: обнаружение дрейфа для соблюдения политик

Вы написали политики. Вы автоматизировали проверки в CI/CD-пайплайне. Каждый деплой проходит валидацию до того, как что-то попадает в продакшен. Команда уверена, что инфраструктура соответствует правилам.

Затем кому-то из команды нужно отладить проблему на продакшене в 22:00. Они заходят в облачную консоль, открывают порт в security group для своего домашнего IP, исправляют проблему и ложатся спать. Они забывают откатить изменение. На следующее утро этот security group всё ещё открыт. Ваш пайплайн об этом не знал. Ваши политики это не отловили.

Этот сценарий не редкость. Он случается, когда инженеры ищут shortcuts во время инцидентов, когда другая команда создаёт ресурсы вручную, потому что ваш пайплайн кажется слишком медленным, или когда автоскейлинг запускает новые инстансы с конфигурациями по умолчанию, нарушающими ваши политики. Все эти изменения происходят вне вашего CI/CD-пайплайна, поэтому проверки политик, которые вы тщательно встроили в этапы plan и apply, их никогда не видят.

Что на самом деле означает обнаружение дрейфа

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

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

Как обнаружение дрейфа работает на практике

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

Вот простой bash-скрипт, который запускает terraform plan и отправляет оповещение при обнаружении дрейфа:

#!/bin/bash
# Scheduled drift detection script (run via cron every hour)
cd /path/to/terraform/project
terraform init -input=false > /dev/null 2>&1
terraform plan -detailed-exitcode -input=false -no-color > plan_output.txt 2>&1
EXIT_CODE=$?
if [ $EXIT_CODE -eq 2 ]; then
  echo "Drift detected at $(date)" >> drift_alerts.log
  # Send notification (e.g., Slack webhook)
  curl -s -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"Drift detected in production infrastructure. Check plan_output.txt for details.\"}" \
    https://hooks.slack.com/services/YOUR/WEBHOOK/URL
elif [ $EXIT_CODE -eq 1 ]; then
  echo "Terraform plan failed at $(date)" >> drift_alerts.log
fi

Например, ваша политика гласит, что ни один security group не должен иметь порт 22, открытый для 0.0.0.0/0. Обнаружение дрейфа сканирует каждый security group и помечает любое нарушение. Или ваша политика требует тег owner на каждом ресурсе. Обнаружение дрейфа инвентаризирует все ресурсы и отмечает те, у которых нет тега.

Результаты должны попадать туда, где ваша команда их действительно увидит. Дашборд — подходит. Уведомления в Slack или по электронной почте — подходят. Автоматический тикет в вашей системе отслеживания — подходит. Что не работает — это генерация отчёта, который никто не читает. Кто-то должен отвечать за дальнейшие действия, иначе обнаружение дрейфа превращается в шум.

Инструменты, которые помогают обнаруживать дрейф

Некоторые инструменты уже включают возможности обнаружения дрейфа. У Terraform есть terraform plan, который может показать различия между вашим state-файлом и реальной инфраструктурой. Но это помогает только для ресурсов, управляемых через Terraform. Ресурсы, созданные вне Terraform, требуют другого подхода.

Нативные облачные инструменты могут сканировать в широком масштабе. AWS Config, Azure Policy и Google Cloud Asset Inventory проверяют ресурсы с помощью собственных API облачных провайдеров. Они глубоко понимают модель ресурсов облачного провайдера и могут проверять соответствие политикам во всём вашем аккаунте.

Существуют и open source-решения. Open Policy Agent (OPA) может работать как engine политик, который вы запускаете периодически для проверки вашей инфраструктуры. Вы пишете политики на Rego, а OPA оценивает их на основе данных о ресурсах, которые вы передаёте.

Сложная часть: что делать, когда вы нашли дрейф

Обнаружить дрейф — только половина работы. Более сложный вопрос — что делать дальше.

Хорошие отчёты о дрейфе содержат достаточно информации для устранения проблемы. Они сообщают, какой ресурс нарушил какую политику и, в идеале, как это исправить. Некоторые команды идут дальше и внедряют автоматическое исправление — когда дрейф обнаружен, система автоматически возвращает ресурс в соответствующее политике состояние.

Автоматическое исправление звучит отлично, пока не ударит вас. Если инженер временно открыл порт для отладки инцидента на продакшене, автоматическое исправление может закрыть этот порт, пока он ещё работает. Инструмент будет исправлять нарушение политики, одновременно нарушая активное расследование. Вам нужно различать дрейф, который произошёл случайно, и дрейф, который был сделан намеренно по краткосрочной причине.

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

Три уровня защиты

Обнаружение дрейфа завершает ваш цикл обеспечения соблюдения политик. Думайте об этом как о трёх уровнях, которые покрывают слепые зоны друг друга:

Диаграмма ниже иллюстрирует, как эти три уровня взаимодействуют:

1. Проверка политик на этапе plan — предотвращает нарушения до того, как они попадут в продакшен
2. Проверка политик на этапе apply — ловит то, что проскочило через планирование
3. Периодическое обнаружение дрейфа — находит изменения, произошедшие вне пайплайна

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

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

• Выберите периодичность сканирования дрейфа в зависимости от того, как быстро меняется ваша инфраструктура
• Выберите инструменты, которые покрывают как управляемые, так и неуправляемые ресурсы в вашем окружении
• Отправляйте отчёты о дрейфе в канал, который ваша команда действительно мониторит
• Назначьте ответственного за обработку результатов обнаружения дрейфа
• Начните с ручного исправления, прежде чем рассматривать автоматизацию
• Документируйте временные исключения, чтобы ваша команда знала, какие дрейфы являются намеренными

Что это значит для вашей команды

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