how/cicd

Policy gate: блокируем нарушения между plan и apply

Между шагами plan и apply встаёт engine - Checkov, OPA или Sentinel. Он читает plan.json и решает, можно ли применять. Бакет без шифрования просто не пройдёт.

terraform plan уже сказал тебе что изменится. Ревьюер из [[tf-plan-as-artifact|PR-комментария]] уже посмотрел и подтвердил изменения. terraform apply пойдёт под [[tf-oidc-aws|узкими временными creds]]. Что может пойти не так?

Человек может не заметить, что новый S3-бакет создаётся без шифрования. Или что security-group открыта в 0.0.0.0/0 на 22-й порт. Или что IAM-policy даёт Action: "*". Это всё видно в plan'е - но в plain text плане 200 строк, и глаз замыливается.

Policy gate решает эту задачу автоматически: между plan и apply стоит engine, который читает plan.json и проверяет изменения против формальных правил. Нарушение → apply заблокирован.

Жми ▶ - посмотрим, как это работает.

step 1/6·00 · без гейта - план → apply

§ шаги

Стандартный pipeline: terraform plan → ревьюер кивнул → terraform apply. Ничто формально не проверяет, что в плане нет нарушений комплаенса.

В небольшой команде с дисциплинированными инженерами это работает. В большой команде или под давлением сроков - рано или поздно проскочит S3-бакет с публичным доступом, RDS без шифрования, или security-group с открытым 0.0.0.0/0.

Эту проблему гейт решает автоматизацией.

итого

Что важно запомнить:

Gate работает с plan.json, не с HCL. plan.json содержит все вычисленные значения, включая то, что появляется только во время refresh'а. Проверка HCL глазами этого не даёт.
Три популярных engine'а:
Checkov - готовые правила «из коробки» (CKV_AWS_, CKV_AZURE_), встраивается за 10 минут. Для compliance baseline'а - самый быстрый старт.
OPA / conftest - пишешь правила сам на Rego, никаких предустановленных. Для специфики команды (например, «все бакеты должны быть в нашем KMS-ключе»).
Sentinel - нативно в Terraform Cloud / Enterprise. Не open-source. Если ты не на TFE - обычно OPA или Checkov.
Gate не заменяет ревьюера. Engine ловит формальные нарушения; human ловит «вообще не туда копаем». Оба нужны.
Правила пишутся постепенно. Начни с одной-двух критичных (S3 без encryption, security-group открытая в 0.0.0.0/0 на SSH), расширяй по мере появления инцидентов.
Можно сделать engine soft - он выводит предупреждение, но не блокирует apply. Хорошо для onboarding'а, плохо для prod'а. Дефолт - hard fail.

С этим стеком закрыта вся CI/CD-сторона: [[tf-plan-as-artifact|артефакт плана]] + [[tf-oidc-aws|OIDC-creds]] + policy gate = production-ready pipeline для Terraform.

§ копнуть в базу знаний

§ попробовать руками

§ шаги

Стандартный pipeline: terraform plan → ревьюер кивнул → terraform apply. Ничто формально не проверяет, что в плане нет нарушений комплаенса.

В небольшой команде с дисциплинированными инженерами это работает. В большой команде или под давлением сроков - рано или поздно проскочит S3-бакет с публичным доступом, RDS без шифрования, или security-group с открытым 0.0.0.0/0.

Эту проблему гейт решает автоматизацией.