Policy as Code: держим изменения инфраструктуры под контролем

У вас есть три среды: development, staging и production. Каждая управляется через инфраструктуру как код. Пайплайн работает, планы выглядят хорошо, изменения применяются. Но в один прекрасный день кто-то создаёт ресурс не в том регионе. В другой раз облачный ресурс появляется без обязательного тега cost-center. Никто не замечает, пока не приходит счёт.

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

Почему ручные правила не работают

У большинства команд правила где-то записаны. На странице в wiki сказано, что все ресурсы должны иметь тег environment. В Slack написано, что production-ресурсы размещаются только в ap-southeast-1. На совещании решили, что любые изменения правил файрвола требуют одобрения команды безопасности.

Эти правила существуют, но они полагаются на человеческую память и благие намерения. Люди забывают. Новички не знают о существовании wiki. Срочные изменения пропускают процесс ревью. А когда что-то идёт не так, у вас нет способа доказать, было ли правило соблюдено.

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

Policy as Code: правила, которые работают в пайплайне

Политика — это правило, которому должно следовать каждое изменение инфраструктуры. Управление (governance) — это то, как вы гарантируете, что эти правила действительно соблюдаются. Когда вы записываете и то, и другое в виде кода и запускаете в своём пайплайне, вы получаете то, что называется policy as code.

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

Вот пример простой политики на Sentinel, которая требует обязательного тега environment для каждого ресурса:

# Требовать, чтобы каждый ресурс имел тег "environment"
mandatory_tag = rule {
  all tfplan.resources as _, resource {
    resource.applied.tags contains "environment"
  }
}

main = rule {
  mandatory_tag
}

Это тот же принцип, что и в Infrastructure as Code. Вы относитесь к своим правилам так же, как к определениям инфраструктуры. Они живут в репозитории, проходят ревью, тестируются и применяются единообразно.

Распространённые политики, которые можно внедрить

Требования к тегированию — это самая распространённая отправная точка. Многие организации требуют, чтобы каждый облачный ресурс имел теги environment, owner или cost-center. Без принудительного применения вы получаете неконсистентные теги, отсутствующие теги или теги с опечатками. С policy as code пайплайн проверяет вывод плана и отклоняет любой ресурс, не соответствующий правилам тегирования.

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

Процессы согласования также могут быть встроены в политику. Не все изменения несут одинаковый риск. Изменение правила файрвола в staging может потребовать одного ревьюера. Изменение того же правила в production может потребовать одобрения команды безопасности. Пайплайн может проверить среду, тип ресурса и объём изменений, чтобы определить, какой путь согласования необходим.

Как это работает на практике

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

Вот визуальное представление этого потока:

flowchart TD A[Коммит кода] --> B[Генерация плана] B --> C{Проверка политик} C -- Успех --> D[Применить изменения] C -- Ошибка --> E[Блокировка пайплайна] E --> F[Показать ошибку: Правило, Ресурс, Ожидаемое значение] D --> G[Деплой завершён]

Вы можете использовать специализированные инструменты, такие как Open Policy Agent (OPA) или Sentinel, для сложных политик. Или вы можете написать простые скрипты, которые парсят план и проверяют конкретные условия. Инструмент не так важен, как принцип: проверка должна быть автоматической, консистентной и блокирующей.

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

Исключения — часть системы

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

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

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

Почему это ускоряет команды

Это звучит нелогично. Добавление автоматических проверок в пайплайн кажется, что должно замедлить работу. Но на самом деле всё наоборот.

Без policy as code каждое изменение, которое может затронуть чувствительную область, требует ручного ревью. Ревьюер должен проверить план, вспомнить правила и принять решение. Это занимает время, и ревьюер может что-то упустить.

С policy as code рутинные проверки выполняются автоматически. Пайплайн отклоняет явно недопустимые изменения за секунды. Ревьюеру нужно смотреть только на те изменения, которые действительно требуют человеческого суждения. Команда работает быстрее, потому что не ждёт ручных проверок того, что можно автоматизировать.

А когда что-то идёт не так, у вас есть чёткий аудиторский след. Вы знаете, что изменилось, кто это одобрил и какие политики были задействованы. Больше никаких догадок, никаких обвинений, никаких "я не знал, что такое правило существует".

Краткий чек-лист для начала

Если вы рассматриваете policy as code для своего инфраструктурного пайплайна, вот шаги для начала:

  • Выберите одну политику, которая причиняет больше всего боли сегодня. Обычно тегирование — хорошее начало.
  • Напишите политику в виде скрипта или используйте инструмент вроде OPA. Протестируйте её на известном нарушении.
  • Добавьте проверку политики в ваш пайплайн между шагами plan и apply.
  • Сначала запустите её в неблокирующем режиме. Логируйте нарушения, но позволяйте пайплайну продолжаться.
  • В течение недели анализируйте нарушения. Исправляйте ложные срабатывания и корректируйте правила.
  • Переключитесь в блокирующий режим. Заставьте пайплайн останавливаться при нарушениях.
  • Документируйте процесс исключений. Чётко опишите, как запросить обход правила.

Вывод

Policy as Code превращает ваши инфраструктурные правила из забытых документов в автоматизированных стражей. Он перехватывает нарушения до того, как они попадут в production, обеспечивает чёткие аудиторские следы и позволяет вашей команде работать быстрее за счёт автоматизации рутинных проверок. Правила живут в вашем репозитории, проходят ревью как код и выполняются при каждом запуске пайплайна. Это управление, которое действительно работает, а не управление, которое живёт на странице wiki, которую никто не читает.