Sentinel и OPA политики
Тема дорожной карты · Terraform
Политика как код с Terraform — это практика кодирования требований соответствия, безопасности и операционных ограничений в виде машинно-оцениваемых правил, автоматически выполняемых против вывода terraform plan — предотвращая попадание несоответствующей инфраструктуры в terraform apply и production-окружения AWS, Azure, GCP или Kubernetes. Основные фреймворки политик в виде кода для Terraform: HashiCorp Sentinel (доступный в Terraform Cloud и Enterprise), Open Policy Agent (OPA) с CLI conftest и Checkov, статически анализирующий HCL-файлы и JSON terraform plan на предмет некорректных конфигураций — открытые S3-бакеты, незашифрованные EBS-тома, отсутствующие теги ресурсов или чрезмерно разрешающие группы безопасности. Политика как код с Terraform интегрируется в GitHub Actions, GitLab CI и Atlantis как обязательные статусные проверки: шаг checkov -d . или conftest test plan.json выполняется перед terraform apply, и конвейер блокируется при любом результате FAIL, предоставляя инженерам конкретные рекомендации по устранению, а не молчаливый обход безопасности. Политики Sentinel в Terraform Cloud могут иметь уровни применения advisory (предупреждение), soft-mandatory (допускается переопределение с обоснованием) или hard-mandatory (без переопределения), соответствующие строгости политики чувствительности окружения — dev может допускать soft-mandatory, тогда как production применяет hard-mandatory правила. Сочетание политики как кода с Terraform на уровне Checkov для статического HCL-линтинга, OPA для применения бизнес-правил на уровне плана и Sentinel для корпоративного управления создаёт глубокоэшелонированную позицию, при которой безопасность инфраструктуры непрерывно валидируется, а не проверяется постфактум.
Как это работает
Sentinel и OPA политики покрывает операционную гигиену: remote state с локингом + versioning, per-environment разделение, секреты вне git, CI/CD с PR-plan + ручным гейтом для prod, drift-detection по расписанию, policy-as-code гейты, версионирование модулей + приватный module registry, observability terraform apply-операций (логи, аудит), DR (бекапы state, runbook отката). Относитесь к Terraform-изменениям с той же осторожностью, что и к релизам приложения.
Когда применять
Применяйте эти практики с первого дня — ретрофит потом болезненный. Политика "destroy табу": production-ресурсы имеют prevent_destroy = true; удаление prod требует снятия флага, ревью PR, одобрения apply. Drift-detection еженочно — ручные изменения ловятся. Тренируйте recovery state на staging до нужды на prod.
Типичные ошибки
Ловушки Sentinel и OPA политики: нет бекапа state, потом коррумпированный state = дни ручной сверки; нет prevent_destroy на БД; apply с ноута в production (нет аудита); пропуск staging-среды ("это же просто конфиг, заработает"). Production-дисциплина не вытекает из добрых намерений — нужны гейты.